Publié le 3 janvier 2020 - par

Partage d’une connexion 4G de smartphone avec un Raspberry Pi

C’est un lecteur du blog qui m’a posé cette question après avoir vainement tenté de la réaliser avec le tutoriel de Michael Franzl. Ce tutoriel date de février 2017 et c’est possible qu’avec les évolutions de Raspbian il y ait quelques soucis. Voici une réponse à cette demande…

Niveau d'accès pour ce tutoriel : Avancé

Cliquez pour plus d’information sur les niveaux

Avertissement

Ce tutoriel répond à un cahier des charges précis, proposé par le lecteur du blog : Je possède un téléphone portable dont je voudrais partager la connexion 4G en USB via le port Ethernet du Raspberry Pi.

Message à destination des sodomiseurs de diptères : Ce tutoriel est fait pour répondre à ce cahier des charges. Oui, on peut partager la connexion 4G autrement, en créant par exemple un AP WiFi, mais ce n’est pas la demande. Si vous pensez qu’on peut faire mieux, n’hésitez pas, écrivez un tutoriel et je le publie avec plaisir 🙂

Matériel Utilisé

  • Smartphone Samsung Galaxy S8
  • Raspberry Pi 4 – 4Go RAM
  • Raspbian Lite 26 sept 2019
  • Switch Ethernet 5 ports

Partager une connexion 4G d’un smartphone avec le Raspberry Pi

Installer l’OS Raspbian Lite

Installer version la version de Raspbian 2019-09-26-raspbian-buster-lite.img (ou la version la plus récente au moment ou vous réaliserez ce tuto).

Ajouter fichier vide ssh sur la partition boot (accessible depuis Windows) pour avoir un accès SSH, sinon, activer le ssh depuis raspi-config si vous souhaitez utiliser le Raspberry Pi à distance.

Configurer la localisation puis mettre à jour avec dist-upgrade.

Redémarrer le Raspberry Pi pour prendre en compte toutes les mises à jour.

Connexion du téléphone

Connecter le téléphone sur une prise USB du Raspberry Pi. Dans le menu Connexion, quand le téléphone est connecté en USB, vous pouvez activer le partage du modem USB (ci dessus). Ce mode s’appele en anglais TETHERING.

Attendez un moment que tout se mette en place et vérifiez que le téléphone a été détecté avec un lsusb.

pi@raspberrypi:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 001 Device 003: ID 09da:054f A4Tech Co., Ltd.
Bus 001 Device 039: ID 04e8:6863 Samsung Electronics Co., Ltd Galaxy series, misc. (tethering mode)
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On a ici le Samsung dans la liste des ports USB, avec l’information suivante :
Samsung Electronics Co., Ltd Galaxy series, misc. (tethering mode)

Cette ligne indique que le téléphone a bien été détecté en mode Tethering.

Dans ifconfig on a

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.42.109 netmask 255.255.255.0 broadcast 192.168.42.255
inet6 fe80::db0b:27fc:903f:458c prefixlen 64 scopeid 0x20<link>
ether 3a:89:f4:90:22:0e txqueuelen 1000 (Ethernet)
RX packets 91 bytes 4771 (4.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 42 bytes 7311 (7.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Ici on voit que le port usb0 a été créé et qu’il a l’adresse 192.168.42.109/24. Dans ce mode de fonctionnement, on retrouve toujours le téléphone dans le réseau 192.168.42.0.

Nous sommes prêts à partager la connexion entre le port usb0 et eth0, le port Ethernet du Raspberry Pi.

Mettre en route le forwarding des paquets

Pour que les paquets de données puissent transiter entre les deux réseaux, il faut activer le routage du noyau.

sudo nano /etc/sysctl.conf

et décommentez la ligne ci-dessous (enlevez le # qui se trouve en début de ligne)

net.ipv4.ip_forward=1

A chaque démarrage de Raspbian, le routage sera activé automatiquement.

Redémarrez le système pour prendre cette modification en compte et activer le routage

sudo reboot
Modem USB
Le partage de modem USB sur le téléphone est annulé lors du reboot du système, car la prise USB est momentanément désactivée. Pensez à revalider le partage de modem USB après chaque reboot !

A cette occasion vous verrez que le téléphone a changé d’adresse, ce qui sera le cas à chaque redémarrage du système.

Ce que nous allons mettre en place

Notre Raspberry Pi va devoir attribuer des adresses IP (en rouge) aux machines qui seront connectées sur son port Ethernet. Pour cela il va falloir installer un serveur DHCP. J’ai choisi d’installer le serveur DHCP isc-dhcp-server. J’ai choisi le réseau 10.0.0.0 pour les machines connectées au Raspberry Pi. Vous pouvez prendre le réseau privé que vous voulez.

Lorsque les machines connectées sur le port Ethernet voudront accéder à Internet, comme vous saisissez un nom de domaine il faut trouver l’adresse IP correspondante à ce domaine. C’est le rôle du serveur DNS. Ici j’ai choisi bind, le classique des classiques en serveur DNS. Il ira chercher sur les DNS extérieurs les domaines qu’il ne connait pas, mais peut garder dans un cache les adresses des domaines qu’il a déjà récupérées. Pour utiliser bind, il faudra que le port Ethernet du Raspberry Pi ait une adresse fixe, on pourra ainsi passer l’adresse du DNS dans les options de DHCP.

Remarque
J’ai choisi ces serveurs DNS et DHCP en toute conscience. Je sais qu’il en existe d’autres, plus légers et plus simples à mettre en œuvre (dnsmasq). Si vous trouvez que ce tuto serait mieux avec dnsmasq… à vous de jouer !

Configurer eth0 en adresse fixe 10.0.0.1

La modification de l’adresse du port Ethernet se fait dans le fichier dhcpcd.conf ouvrez-le

sudo nano /etc/dhcpcd.conf

et modifiez le en ajoutant à la fin du fichier

# Adresse fixe sur le port Ethernet eth0
interface eth0
static ip_address=10.0.0.1/24

Redémarrez (pensez à remettre le partage modem USB sur le smartphone 🙂 ) et vérifiez par ifconfig que eth0 a pris cette adresse (ça ne fonctionne que si un câble RJ45 relié à un switch ou un PC est connecté au port Ethernet du Raspberry Pi, et attendez un peu que tout ça se mette en place)

Si vous étiez connecté en SSH… pensez que le Raspberry Pi vient de prendre une autre adresse que celle qu’il avait précédemment 😀

Installer le serveur DHCP

On va pouvoir passer à l’installation du serveur DHCP.

sudo apt-get install isc-dhcp-server

Ne soyez pas étonné(e) d’avoir des signalements d’erreurs lors du démarrage car on n’a pas encore déclaré de réseaux. C’est ce que nous allons faire maintenant.

sudo nano /etc/dhcp/dhcpd.conf

ouvrez le fichier de configuration dans nano

# subnet 10.0.0.0
subnet 10.0.0.0 netmask 255.255.255.0 {
   range 10.0.0.10 10.0.0.100;
   option routers 10.0.0.1;
}

Ajoutez ces lignes en fin de fichier. Ceci va créer un réseau (subnet) 10.0.0.0 dans lequel le DHCP va attribuer des adresses comprises (range) entre 10.0.0.10 et 10.0.0.100. Ça devrait suffire pour les besoins courants.
La ligne options va transmettre aux machines connectées l’adresse de la passerelle qu’elles doivent utiliser, ici 10.0.0.1 soit l’adresse du port eth0 du Raspberry Pi.

Il faut encore indiquer au DHCP qu’il doit écouter les requêtes qui lui sont destinées sur eth0 à l’adresse IP 10.0.0.1
Pour que le serveur écoute sur certaines interfaces, il faut les spécifier dans /etc/default/isc-dhcp-server : ouvrez ce fichier avec nano

INTERFACESv4="eth0"

Modifiez la ligne INTERFACESv4 en ajoutant eth0 comme ci-dessus.

Redémarrez le service (vous pouvez aussi rebooter le Raspberry Pi si vous préférez)

sudo service isc-dhcp-server restart

Pour tester : un PC connecté sur eth0 prend bien l adresse 10.0.0.10 après son démarrage. Sinon faire ipconfig /renew.

Ici test avec un vieux portable en Windows 7. Adresse obtenue 10.0.0.10 et Gateway (Passerelle par défaut) 10.0.0.1. Si tout est bon, on peut continuer.

Si vous n’obtenez pas ce résultat, arrêtez vous là et essayez de comprendre ce qui n’a pas fonctionné. Si les machines connectées au port eth0 ne prennent pas les bonnes adresses IP, pas la peine d’insister, le reste ne fonctionnera jamais 🙂

Si cette partie fonctionne, on va pouvoir configurer le transfert des paquets avec iptables.

Configuration iptables

On va établir un NAT (translation d’adresse) vers usb0

sudo iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -j ACCEPT
sudo iptables -A FORWARD -o eth0 -j ACCEPT

A partir de là le ping 8.8.8.8 doit fonctionner sur le PC => on sort bien sur Internet mais ping google.fr ne fonctionne pas. Donc il n’y a pas de résolution de nom. c’est le DNS qui va apporter la solution.

Nota : La config iptables est ici réduite au strict minimum. tous les paquets sont autorisés, dans tous les sens… Si vous avez besoin d’un firewall, à charge pour vous de modifier ces lignes pour filtrer les paquets 😉

Au passage, si vous redémarrez le Raspberry Pi, vous perdez la configuration iptables car elle est juste en mémoire. On va sauver cette config. dans un fichier :

sudo iptables-save > iptables

Cette commande génère un fichier de sauvegarde d’iptables et la redirige (signe > ) vers un fichier que j’ai appelé… iptables ! Mais vous pouvez bien l’appeler comme vous voulez.

Vous pouvez lire le contenu du fichier pour vérifier : cat iptables

Maintenant il faut recharger ce fichier lors de chaque démarrage du Raspberry Pi. Une dess méthodes est d’ajouter un script dans /etc/rc.local.

Créez un script shell dans /home/pi pour recharger la config. iptables

nano reseau.sh

Dans le fichier tapez

#!/bin/bash
sudo iptables-restore < /home/pi/iptables

Lorsque ce script sera lancé, il rechargera votre config iptables à partir du fichier iptables que nous avons créé.

Ouvrez /etc/rc.local

/home/pi/reseau.sh

Ajoutez cette ligne AVANT le exit 0 final.

Pour tester si cet ajout fonctionne, redémarrez le Raspberry Pi et vérifiez avec un iptables -L et un iptables -t nat -L que vous avez bien rechargé les iptables.

Si tout va bien, votre PC se connecte maintenant à internet, ping 8.8.8.8 fonctionne, ce qui prouve que la configuration iptables a bien été remise en place.

Installation DNS

sudo apt-get install bind9 bind9-doc dnsutils

On commence par installer le serveur DNS

Configuration du DNS

ouvrir le fichier /etc/bind/named.conf

sudo nano /etc/bind/named.conf

Modifiez le fichier pour qu’il contienne :

include "/etc/bind/named.conf.default-zones";
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
options {
directory "/var/cache/bind";
auth-nxdomain no;
forwarders {
8.8.8.8;
9.9.9.9;
};
listen-on port 53 {
127.0.0.1;
10.0.0.1;
};
listen-on-v6 {
none;
};
allow-query {
internals;
};
allow-transfer {
none;
};
allow-recursion {
internals;
};
};

Une fois que tout est rentré et vérifié, exécutez la commande

sudo named-checkconf

qui va vérifier la syntaxe de votre fichier. En cas d’erreur (manque une accolade, un point virgule…) ne continuez pas, il faut trouver l’erreur !

Quand la commande passe sans renvoyer de message vous pouvez continuer 🙂

Et redémarrer le service DNS pour prendre vos modifications en compte.

sudo service bind9 restart

Ajout de l’option DNS au DHCP

Il reste à indiquer aux postes que vous allez connecter sur le switch que le DNS est à l’adresse 10.0.0.1 (l’adresse IP du port eth0 du Raspberry Pi). On retourne dans la config du DHCP pour ajouter l’option DNS :

sudo nano /etc/dhcp/dhcpd.conf

puis modifier le subnet pour ajouter l’option domain-name-servers.

# Reseau 10.0.0.0 sur eth0
subnet 10.0.0.0 netmask 255.255.255.0 {
     range 10.0.0.10 10.0.0.100;
     option routers 10.0.0.1;
     option domain-name-servers 10.0.0.1, 8.8.8.8;
}

J’ai ajouté en secours le DNS 8.8.8.8 de Google

On peut ensuite redémarrer le serveur DHCP

sudo service isc-dhcp-server restart

et rafraichir le(s) poste(s) connecté(s) au switch pour qu’il(s) prenne(nt) en compte le DNS.

Sur une machine Windows 7 voici le résultat obtenu. L’adresse est bien à 10.0.0.10, la passerelle par défaut et le serveur DNS ont été configurés à 10.0.0.1 via les options DHCP. Tout est OK

Test

Sur le ou les postes connectés au switch, vous pouvez maintenant

  • ping 8.8.8.8
  • ping google.fr
  • accéder à framboise314.fr (ou autre site web 🙂 )

Conclusion

Créé pour répondre à une demande de Julien, ce tutoriel pourra sans doute servir à d’autres. A nouveau, c’est MA réponse à ce cahier des charges. J’ai utilisé ces outils que je connais car ça m’aurait pris plus de temps si j’avais dû travailler avec d’autres logiciels que je ne connais pas ou moins. Donc si ça ne vous plait pas je le comprendrai, mais dans ce cas, faites une critique constructive et partagez avec les lecteurs du blog VOTRE solution… qui sera sans doute meilleure (?).

Question subsidiaire : à votre avis entre la découverte du cahier des charges, la POC, la première rédaction de l’article, la réalisation du projet en suivant (et en corrigeant le premier jet), la relecture… combien de temps passé ?

Sources

Share Button

À propos François MOCQ

Électronicien d'origine, devenu informaticien, et passionné de nouvelles technologies, formateur en maintenance informatique puis en Réseau et Télécommunications. Dès son arrivée sur le marché, le potentiel offert par Raspberry Pi m’a enthousiasmé j'ai rapidement créé un blog dédié à ce nano-ordinateur (www.framboise314.fr) pour partager cette passion. Auteur de plusieurs livres sur le Raspberry Pi publiés aux Editions ENI.

24 réflexions au sujet de « Partage d’une connexion 4G de smartphone avec un Raspberry Pi »

  1. Hydrog3n

    Hello,
    Je pense que ce que tu as utilisé c’est le plus simple et ce que l’on apprend dans l’on débute en réseau. Juste une étape que je n’aurais pas fait c’est l’installation de bind car juste l’ajout de 8.8.8.8 au dhcp devrait suffire (à vérifier) vu que tu ping 8.8.8.8 avant d’avoir fait bind.

    Répondre
    1. François MOCQ Auteur de l’article

      merci
      je ne sais pas si le choix est bon, l’idée c’était d’avoir un cache avec Bind pour économiser des data en évitant de renvoyer les demandes de DNS déjà résolues vers la 4G…
      à voir !

      Répondre
  2. el Pollo

    Bonjour à tous,

    Ce tutoriel explique comment configurer la framboise en routeur avec en WAN (les Internets) une connexion 4G d’un tel sur l’USB et en LAN (le rézo lôcal) l’interface eth0.

    Merci pour ce petit tuto car cela m’a rappelé des souvenirs.

    Sans vouloir joué les “sodomiseurs de diptères”, on peut se faire des confs vraiment funky comme monter l’interface wifi avec un bridge des familles ou même faire un second réseau en 10.0.1.0/24 par exemple sur l’interface wifi pour … identifier rapidement les adresses wifi des adresses physiques ou bien encore pour en faire un réseau invité.

    Mais le mieux du mieux, c’est qu’un routeur linux offre de nombreuse possibilitées.
    Premièrement on peut avec iptables filtrer sa connexion internet au poil du cul. Par exemple on peut n’autoriser qu’une adresse à se connecter en ssh comme l’interdire totalement,
    Et enfin deuxièmement, on peut sniffer tous les paquets qui entrent et sortent du réseau pour ensuite étudier le trafic sur wireshark.

    Si la sécu réseau vous intéresse, ce genre de délire est fait pour vous.

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour
      merci pour ce commentaire
      j’ai fait au plus simple (enfin, c’est juste mon avis) pour répondre à la demande de Julien
      Après c’est sûr qu’on peut s’amuser si besoin, mais là il fallait juste partager la 4G entre plusieurs machines via Ethernet 🙂

      Répondre
  3. Grv

    Salut,

    Je mettrais perso environ 1h30 pour maquetter, et 2h pour rédiger, mais je sais exactement où je vais.
    Si ce n’est pas ton cas, je pense quasi le double ?

    Juste un point je pense qu’il vaudrait mieux utiliser les commandes systemd plutôt qu’init.d, ca fait prendre de bonnes habitudes.

    Merci pour cet article !

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour
      en fait ça a été étalé sur presque 2 jours 🙂 comme c’est le premier article de l’année, je me suis amusé à regarder combien de temps je passais
      le maquettage et les tests avec dnsmasq puis isc/bind ont pris 2 bonnes heures (je repars à chaque fois d’une carte SD “neuve”)
      Install des choix arretés/tests en continu résolution des problèmes et rédaction simultanée avec les copies de textes 4 à 5h (en particulier le vieux portable Win7 qui n’avait pas été allumé depuis des mois en a profité pour faire des mises à jour dont l’une a bloqué les accès réseau fil et wifi 🙂 )
      Tout reprendre à zéro en suivant le tuto de façon naïve et en rectifiant à mesure 2 à 3h
      Préparer les images, copies d’écran avec l’appareil photo et réalisation des 2 infographies (recherche des images, détourage, réalisation de l’image finale) 1h
      Publication avec création des mots clés SEO, catégories et étiquettes (1h)
      Relecture finale de l’article après publication, correction de quelques fautes, tournures, éclaircissement de phrases … 1/2 heure
      Voilà au total on est assez près de 13 ou 14h, c’est souvent le cas pour les “gros” articles dont la fabrication s’étale sur plusieurs jours
      Si on ajoute le temps de réponse aux commentaires sur le blog, facebook et twitter…
      Ok pour l’utilisation de systemd, je le note pour une prochaine fois. J’ai trouvé que créer un service ça rallongeait encore la sauce pour un débutant qui a déjà pas mal d’occasions de se planter avec tout ce qu’il y a à faire.
      merci pour ce retour

      Répondre
  4. Thib

    Le téléphone ayant un serveur DHCP intégré en 192.168.42.X, est ce qu’il n’y aurait pas des conflits entre les 2 serveurs DHCP ? (Téléphone et Pi)

    Répondre
    1. Damien G

      Comme indiqué dans le tuto, il faut spécifier dans /etc/default/isc-dhcp-server les interfaces sur lesquelles le serveur DHCP répond, dans le cas présent : INTERFACESv4=”eth0″

      Le DHCP du téléphone étant sur l’interface USB0 il ne devrait donc pas y avoir de conflit avec le DHCP du RPI qui répond sur ETH0.

      Répondre
  5. Damien G

    Salut,
    Merci beaucoup pour cet article des plus intéressants !
    Petite question : est-il possible de créer un point d’accès WiFi sur le RPI pour permettre a des équipements sans fil de communiquer avec les équipements filaires sur le même réseau IP ? Je me doute que l’antenne Wifi ne vaut pas celle d’un AP mais ça pourrait dépanner.
    Je trouve extrêmement intéressant de pouvoir utiliser le RPI comme routeur filaire / wifi par exemple pour utiliser la 4G lorsque l’ADSL ou la Fibre est en panne par ex, ou en cas de déménagement le temps que la ligne soit livrée par un opérateur.
    Merci d’avance.

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour Damien
      oui on peut installer un AP comme hostapd par exemple
      après il faut modifier les chemins du routeur pour activer l’accès à l’AP.
      si j’ai le temps je me pencherai dessus 🙂

      Répondre
  6. Jerome

    Bonjour,

    J’ai fait quelques recherches pour remédier à la perte du partage USB sur le téléphone.

    La bonne nouvelle c’est qu’il existe des applis qui vont partager automatiquement via USB.
    Les mots clés sont “auto USB tether” pour chercher sur le store

    La mauvaise nouvelle c’est qu’il faut un téléphone ROOTé sinon cela ne fait qu’ouvrir l’écran des paramètres.

    Si cet aspect vous intéresse et que vous voulez être sûr de ce que vous exécutez, voici un de mes projets qui fait la même chose https://github.com/wadael/OpenConnectionDialog

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour Jérôme
      merci pour le retour et pour le lien
      que voulez vous dire avec : ” la perte du partage USB sur le téléphone”?
      je n’ai pas vu ce problème (test avec 2 samsung)

      Répondre
  7. bartounet

    Merci pour ce tuto
    J’ai un autre challenge à relever
    Partager la connexion wifi d’un hôtel avec un rpi
    La problématique est que le wifi de l’hôtel passe par un portail captif

    J’ai jamais réussi… Pour l’instant

    Répondre
    1. François MOCQ Auteur de l’article

      bonjour
      regardez du côté de l’IDE Selenium ?
      https://selenium.dev/selenium-ide/
      j’avais automatisé l’accès à une page web pour un ami
      ça tourne sur du Pi sans problème
      Il fallait ouvrir sa page régulièrement sur un site de vente d’art en ligne pour qu’il apparaisse dans les premières réponses 🙂
      j’ai fait un script avec Selenium, lancement toutes les 10 minutes, remplissage auto du login.pwd
      ouverture d’une page, déconnexion… toutes les 10 minutes !

      après si l’hôtel demande des infos, l’IDE peut les remplir en automatique
      en général ils demandent une adresse mail valide… je réponds moi@ici.com et ça fonctionne la plupart du temps 🙂
      il y a un peu d’apprentissage de l’IDE mais ce n’est pas très compliqué.
      Vous me direz ce que vous en pensez
      cdt
      françois

      Répondre
  8. Bartounet

    Oui bonne idée
    Mais c’est pas trop le renseignement du portail captif le problème
    Car même le rentrer une fois a la main n’est pas un problème

    C’est plutôt que tout fonctionne côté réseau
    Connecté au wifi hôtel d’un côté via le portail
    Et de l’autre diffuser un autre wifi et que tout route et nat
    Mais je vais retenter
    Après je pense que la plupart plupart du temps l’adresse mac est vérifiée

    Répondre
  9. jerome

    Bonjour François,

    Vous avez indiqué que le partage était désactivé lors d’un reboot du pi.

    Ce qui peut être embêtant en déplacement.

    J’ai donc cherché à comment écrire un programme Android qui s’assurrerait que le partage était en route.

    Puis je me suis dit que qqun avait déjà dû l’écrire.

    Un smartphone ancien, rooté, dédié serait une solution.

    Répondre
  10. Ping : Partage d'une connexion 4G Ethernet + Wifi - Framboise 314, le Raspberry Pi à la sauce française....

  11. Artemus24

    Salut à tous.

    Votre téléphone Samsung ne sait-il pas gérer l’Ipv6 ?
    Si votre raspberry a une adresse IP, votre téléphone ne fait pas que modem mais aussi pont (bridge) ou routeur.
    Si vous désirez gérer un serveur DHCP et DNS, pourquoi ne pas utiliser dnsmasq ?
    Ne trouvez-vous pas que bind9 est un peu trop compliqué pour ce que vous désirez faire ?
    Alors que dnsmasq gère le fichier “/etc/hosts” qui est bien plus simple à mettre en oeuvre.
    La configuration du fichier “/etc/dhcpcd.conf” (client) est incomplète.
    Quel est l’adresse de votre routeur ? 10.0.0.1/24 peut-être ? Pourquoi ne pas l’indiquer ?
    La configuration du fichier “/etc/dhcp/dhcpd.conf” (serveur) n’est pas complète non plus.
    Vous devriez aussi créer des adresses IP fixes à partir des adresses MAC de vos ordinateurs.
    Les iptables forward nécessitent d’avoir les interfaces input et output. Pourquoi ne précisez-vous USB0 ?
    Il manque aussi toute la partie filtrage : loopback, dns, dhcp, ssh, established, icmp, ntp, http/https, samba, vnc, …
    Le déclenchement de l’iptable ne se fait pas dans “/etc/rc.local” mais plutôt dans “/etc/network/pre-up.d”, c’est-à-dire au démarrage de l’interface.
    Bind9 n’est pas nécssaire car vous n’avez rien déclaré comme nom d’hôte.
    Les serveurs DNS se déclarent dans “/etc/resolvconf/resolv.conf.d”. Aupréalable, il faut installer resolvconf.

    J’ai fait un routeur maison à partir de : hostapd (deux dongles wifi) + dnsmasq + Hurrican Electric (IPv6) + dhcpcd + resolvconf + hosts + firewall.
    Hormis le routeur, le but était d’avoir à nouveau l’ipv6.

    @+

    Répondre
    1. François MOCQ Auteur de l’article

      Bonjour Artemus
      bin c’est moi le responsable… Cet article en réponse à une demande toute simple de partager sa connexion 4G en Ethernet.
      Pas question ici de faire un routeur super sophistiqué, juste de partager les données…
      J’ai utilisé isc-server et bind que je connais, tout simplement et la config minimaliste de bind s’explique par le fait que le but n’est PAS de faire un DNS local mais je voulais juste un cache DNS (pour économiser de la BP en diminuant les requêtes sur la 4G)
      je ne voulais pas gérer les machines par leur nom d’hôte… encore une fois faire simple. On n’est pas en entreprise mais chez un particulier qui va connecter une ou deux machines. Pas besoin de sortir la grosse artillerie (enfin, c’est mon avis)
      Pour les iptables, le but est que ça passe… après comme indiqué dans l’article : Nota : La config iptables est ici réduite au strict minimum. tous les paquets sont autorisés, dans tous les sens… Si vous avez besoin d’un firewall, à charge pour vous de modifier ces lignes pour filtrer les paquets 😉
      je ne peux pas tout faire non plus 🙂
      Pour le lancement d’iptables, ça marche dans rc.local mais c’est vrai que c’est l’ancienne méthode (je ne suis plus tout jeune) et j’ai modifié le lancement dans l’article suivant suite à la remarque d’un lecteur

      et pour la conclusion j’ai mis : “A nouveau, c’est MA réponse à ce cahier des charges. J’ai utilisé ces outils que je connais car ça m’aurait pris plus de temps si j’avais dû travailler avec d’autres logiciels que je ne connais pas ou moins. Donc si ça ne vous plait pas je le comprendrai, mais dans ce cas, faites une critique constructive et partagez avec les lecteurs du blog VOTRE solution… qui sera sans doute meilleure (?).
      Donc merci pour la critique qui donne plein d’idées pour ceux qui se lanceront dans le projet. Et comme suggéré si vous avez une meilleure solution (
      ce qui est compréhensible car je ne suis pas spécialiste en DHCP et DNS, juste utilisateur), je vous invite à rédiger un article là dessus et je le publierai avec plaisir !
      cordialement
      François

      Répondre
  12. artemus24

    Salut François Mocq.

    Bon travail et merci pour votre retour d’expérience.
    Mon cas est différent car je voulais me faire un routeur avec de l’ipv6, mais pas en 4G.

    Je souligne que la 4G ne permet pas de gérer un serveur web à cause du fait qu’il n’existe pas de NAT dans ce mode de connexion.
    Voire même que l’attribution d’une adresse IP fixe est impossible à cause de la rareté des adresses IPv4.
    Bien que le projet soit fort intéressant, cela reste quand même limité à cause de la 4G.

    Le firewall peut se lancer dans par “/etc/rc.local” ou en créant un service.
    J’ai testé ces deux cas, mais je préfère de loin mettre le script dans le répertoire “/etc/network/pre-up.d”, disons c’est plus moderne comme approche.

    La solution que je propose est plus lourde que la votre car plus complète, mais pas forcément adaptée à des débutants.
    On peut faire plus simple en ne faisant pas un routeur mais un pont (bridge).
    Disons que le but n’est pas le même. J’envisage de faire un autre routeur en utilisant bind9 et dhcpd (serveur).

    J’envisage en effet d’écrire un sujet sur mon projet.

    Je tiens à vous remercier encore une fois, pour le travail que vous nous communiquez au travers de votre blog.

    Cordialement.
    Artemus24.
    @+

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Complétez ce captcha SVP * Time limit is exhausted. Please reload CAPTCHA.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.