Je vais ajouter une réponse ici car les commentaires n'ont pas abordé mon problème particulier. Je soupçonne que c'est parce que j'ai rencontré un vilain bug du noyau Linux. La configuration est :
internet <--> modem 1.1.1.1/30 <--> commutateur <---> LAN 10.1.1.0/24
^
+----------------------+ |
| /--eth0 o <----/
| | |
| 10.1.1.1/24 br0 | v (antenne)
| 1.1.1.2/30 | | |
| \-wlan0 o ----------/
+----------------------+
Malgré l'apparence complexe de l'image, le seul changement pertinent par rapport aux situations couvertes dans les autres commentaires est l'ajout du pont logiciel, br0. Il est là car la passerelle est aussi un point d'accès sans fil pour le LAN.
Notre passerelle continue d'effectuer des tâches de NAT pour les machines du LAN. Comme elle n'a qu'un port Ethernet, elle est obligée de faire du NAT capillaire. Je soupçonne que cela devrait fonctionner avec les règles iptables données dans les autres commentaires ici, mais au moins avec le noyau Linux 4.9, ce n'est pas le cas. Avec la version 4.9, notre passerelle peut accéder à Internet, mais les machines du LAN qui essaient d'y accéder via NAT ne le peuvent pas.
tcpdump montre des réponses aux paquets entrants frappant eth0, mais ils n'atteignent pas br0. En exécutant cette commande, cela résout le problème :
ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP
Avant l'exécution de cette commande, les paquets entrants sont traités selon le comportement par défaut du noyau, qui consiste à les remettre au pont puis à les transmettre aux modules de routage du noyau. La commande force les paquets qui ne viennent pas du LAN à contourner le pont et à aller directement vers le routage, ce qui signifie que le pont n'a pas l'occasion de les rejeter. Les adresses de diffusion et de multidiffusion doivent être bridgées, sinon des choses comme le DHCP et le mDNS ne fonctionneront pas. Si vous utilisez IPv6, vous devez ajouter des règles pour cela également.
Vous pourriez être tenté de résoudre le problème en utilisant ceci :
brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on
J'ai certainement été tenté - c'était ma première tentative. Dès que je l'ai fait, les machines du LAN ont accédé à Internet, donc cela fonctionne pendant un certain temps. Ensuite, les événements suivants se sont produits (et je n'ai pas eu envie de répéter l'expérience) :
- Les temps de ping à travers le LAN jusqu'à la passerelle ont doublé à intervalles d'environ 10 secondes, passant de 0,1 ms à 0,2 ms, 0,4 ms, 0,8 ms, 2 ms, et ainsi de suite jusqu'à ce que la passerelle devienne inaccessible depuis le LAN. Cela sentait la tempête de paquets, mais le STP était activé partout.
- Peu de temps après, tous les points d'accès sans fil sont tombés en panne.
- En essayant de diagnostiquer ce qui se passait avec le sans fil, tous les téléphones IP ont redémarré.
- Peu de temps après, les machines câblées ont perdu tout contact avec le LAN.
La seule solution était de redémarrer chaque machine dans le bâtiment. La seule exception était les commutateurs matériels, qui ne pouvaient pas être redémarrés. Ils ont dû être redémarrés manuellement.
1 votes
Si votre objectif est de tester l'accès depuis internet, il est inutile de manipuler les routes du routeur et/ou les paramètres DNS de toute façon, car au mieux, de l'intérieur, vous vérifieriez que la partie intérieure du routeur fonctionne. Je vous suggère d'utiliser un serveur proxy quelque part à l'extérieur.