Problème de routeur Debian Squeeze

Support Debian
#1

Tout d’abord, bonjour à tous.

Je viens de m’inscrire sur le forum car j’ai besoin d’aide mais je ne sais pas si
c’est bien ici que je dois poster ma question. Bon je me lance.

Je tente, depuis un mois, d’installer un routeur sur la base d’un mini-PC sur lequel
est installé une Debian Squeeze 6.0.5, un demon dchp (isc-dhcp-server), un dns
(bind9) qui font correctement leur travail sur le réseau local.

Un rapide descriptif :
mini-PC :
SmartTeck Nano PC AMD APU E350
CPU AMD E350 Dual Core 2x1,6 GHz
(pour ceux que sa intéresse réf : SMT-FOX-NTA3500-BL).

Quelques messages du noyeau :

[code]Il dispose d’une carte réseau interne 10/100/1000 Mbits (connecté à un commutateur sur le réseau local) :
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: Foxconn International, Inc. Device 0e29
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.091570] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.091604] r8169 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.091662] r8169 0000:02:00.0: setting latency timer to 64
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.091672] r8169 0000:02:00.0: (unregistered net_device): unknown MAC, using family default
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.091756] r8169 0000:02:00.0: irq 27 for MSI/MSI-X
Aug 1 15:37:14 debian-apu-e350 kernel: [ 2.092667] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xf7db8000, d0:27:88:79:a7:ff, XID 0c900800 IRQ 27

Il dispose aussi d’une carte réseau interne Wifi b/g/n :
03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Foxconn International, Inc. Device e025
Aug 2 05:05:01 debian-apu-e350 kernel: [ 8.643813] phy0: Atheros AR9285 MAC/BB Rev:2 AR5133 RF Rev:e0: mem=0xf8440000, irq=17
Aug 2 05:08:20 debian-apu-e350 kernel: [ 7.643130] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Aug 2 05:08:20 debian-apu-e350 kernel: [ 7.643147] ath9k 0000:03:00.0: setting latency timer to 64
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.366879] phy0: Selected rate control algorithm 'ath9k_rate_control’
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.367892] Registered led device: ath9k-phy0::radio
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.367918] Registered led device: ath9k-phy0::assoc
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.367947] Registered led device: ath9k-phy0::tx
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.367971] Registered led device: ath9k-phy0::rx
Aug 2 05:08:20 debian-apu-e350 kernel: [ 8.367991] phy0: Atheros AR9285 MAC/BB Rev:2 AR5133 RF Rev:e0: mem=0xf82c0000, irq=17

Afin de faire le pont avec Internet, j’ai branché un adaptateur USB -> ethernet sur un des ports USB arrière (connecté au modem LiveBox) :
Aug 1 15:36:17 debian-apu-e350 kernel: [ 7.471773] eth1: register ‘MOSCHIP usb-ethernet driver’ at usb-0000:00:12.2-4, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:00:05:ed
Aug 1 15:36:17 debian-apu-e350 kernel: [ 7.471816] usbcore: registered new interface driver MOSCHIP usb-ethernet driver[/code]

Or, malgré avoir modifié le fichier /etc/sysctl.conf comme suit :

[code]net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0[/code]

et obtenu du noyeau les messages suivants :

Aug 1 15:37:17 debian-apu-e350 kernel: [ 18.471016] Bridge firewalling registered Aug 2 05:05:08 debian-apu-e350 kernel: [ 25.010713] ip_tables: (C) 2000-2006 Netfilter Core Team Aug 2 05:05:08 debian-apu-e350 kernel: [ 25.067280] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Aug 2 05:05:08 debian-apu-e350 kernel: [ 25.067802] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use Aug 2 05:05:08 debian-apu-e350 kernel: [ 25.067809] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or Aug 2 05:05:08 debian-apu-e350 kernel: [ 25.067816] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. Aug 2 05:08:20 debian-apu-e350 kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=1567d930-0364-4d56-b665-4ddd33a851f8 ro ipv6.disable=0 quiet

avoir créé dans un fichier rc.firewall les directives iptables suivantes :

[code]#!/bin/sh

Installation du pare-feu :

Efface les anciennes affectations :

iptables --flush
iptables --table nat --flush
iptables --table filter --flush
iptables --table mangle --flush

Efface toutes les chaines qui ne sont pas par défaut dans les filtres :

iptables --delete-chain
iptables --table nat --delete-chain
iptables --table filter --delete-chain
iptables --table mangle --delete-chain

Création de nouvelles règles :

iptables --table filter -P INPUT ACCEPT
iptables --table filter -P FORWARD ACCEPT
iptables --table filter -P OUTPUT ACCEPT
iptables --table nat -P PREROUTING ACCEPT
iptables --table nat -P POSTROUTING ACCEPT
iptables --table nat -P OUTPUT ACCEPT

Règles pour une machine serveur faisant office de routeur NAT :

# Pas de filtrage sur la boucle locale :
iptables --table filter --append INPUT --in-interface lo -j ACCEPT
# Pas de filtrage sur les interfaces locales :
iptables --table filter --append INPUT --in-interface eth0 -j ACCEPT
iptables --table filter --append INPUT --in-interface wlan0 -j ACCEPT

Valide l’IP FORWARDing et MASQUERADing (NAT) :

# Accès à Internet à travers les interfaces eth0 (réseau local) - eth1 (réseau Internet) :

# Accepte le protocole IGMP (pour la multicéast) :
iptables --table filter --append INPUT -p igmp -j ACCEPT

# Accepte le protocole ICMP (notamment le ping) :
iptables --table filter --append INPUT -p icmp -j ACCEPT

# Active le NAT d'iptables.
iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE

# Accepte les paquets entrants relatifs à des connexions déjà établies.
iptables --table filter --append FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Autorisation des requêtes DNS venant d'un serveur local.
iptables --table filter --append INPUT --in-interface eth1 -p udp --sport 53 --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables --table filter --append INPUT --in-interface eth1 -p tcp --sport 53 --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables --table filter --append OUTPUT --out-interface eth0 -p udp --sport 1024: --dport 53 -m state ! --state INVALID -j ACCEPT
iptables --table filter --append OUTPUT --out-interface eth0 -p tcp --sport 1024: --dport 53 -m state ! --state INVALID -j ACCEPT

iptables --table filter --append OUTPUT --out-interface wlan0 -j ACCEPT
iptables --table filter --append OUTPUT --out-interface eth0 -j ACCEPT
iptables --table filter --append OUTPUT --out-interface lo -j ACCEPT

# Gestion du problème de MTU entre le serveur NAT relié au fournisseur et les machines derrière lui :
iptables --table mangle --append FORWARD --out-interface eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Chargement dans le noyeau :

iptables-save | iptables-restore

Sauvegarde de la table en cours :

iptables-save>/etc/rc.d/firewall-`date +%Y-%m-%d_%T`.txt

exit 0
[/code]

avoir créé dans un fichier rc.route, les directives suivantes :

[code]#!/bin/sh

Configuration de la table de routage :

echo -n " Ajout route défaut -> eth0"
route add -net default gw 192.168.1.254 dev eth0 #  eth0
echo "  -> [ Fait ]"

echo -n " Ajout route défaut -> eth1"

route add -net 0.0.0.0 gw 192.168.0.1 dev eth1 # eth1

echo " -> [ Fait ]"

echo -n " Ajout route défaut -> wlan0"
route add default gw 192.168.1.253 dev wlan0 # wlan0
echo " -> [ Fait ]"

Sauvegarde de la table de routage :

route>/etc/rc.d/routage-`date +%Y-%m-%d_%T`.txt

exit 0[/code]

et obtenu le message suivant :

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.253 0.0.0.0 UG 0 0 0 wlan0 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

En résumé :

  • eth0 : réseau local (192.168.1.0), adresse fixe par configuration static dans /etc/network/interface;
  • eth1 : réseau externe (192.168.0.0), adresse obtenue par le dhcp du modem LiveBox;
  • wlan0 : interface pour gérer un point d’acces WiFi pour connexion sans fil (utilisation ultérieure).

je parviens à :

  • pinger toutes les machines à partir du serveur sur le réseau local 192.168.1.0);
  • pinger le serveur (192.168.1.254) et d’autres machines à partir d’une quelconque machine du réseau local (192.168.1.0);
  • pinger le modem (192.168.0.1) à partir d’une quelconque machine du réseau local (192.168.1.0);
  • je parviens à me connecter au modem LiveBox (192.168.0.1) à partir du serveur ou d’une quelconque machine du réseau local (192.168.1.0).

On peut considérer donc que le routeur fonctionne correctement.

Sauf que, si je tente de pinger par exemple google.fr, çà ne marche pas (unknown host). Le serveur ntpd ou le dns local ne parviennent pas non plus à se connecter à Internet.

En dehors du réseau local, rien ne marche sur Internet.

Toutefois, je pense à quelque chose qui pourrait faire que la connexion ne fonctionne pas : la déconnexion intempestive de l’adaptateur USB -> ethernet. S’il est possible, peut-on rendre ce branchement permanent ?

Si quelqu’un voit une erreur de configuration ou si il y a quelque chose de plus à rajouter, je suis preneur.

Je reste (comme on le dit habituellement) à votre disposition pour des précisions (excuses pour la mise en page pour la table de routage).

Merci d’avance pour vos réponses ou conseils.
Jean-Pierre.

#2

[quote]Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.1.253 0.0.0.0 UG 0 0 0 wlan0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1[/quote]
Cette table me semble incorrecte en deux points :

  • même réseau (192.168.1.0) sur deux interfaces (eth0 et wlan0) => une plage réseau par interface.
  • présence de trois passerelle dans la même table => une seule et unique passerelle pour tout l’équipement peu importe le nom d’interface.
#3

Bonjour,

merci pour la réponse.

Alors comment faire pour que tant les machines sur le réseau filaire que les machines sur le WiFi puissent se connecter au réseau local et passer par le routeur pour accéder à l’Internet ?

Je vais modifier le fichier rc.route pour ne mettre qu’une seule passerelle :

#!/bin/sh

# Configuration de la table de routage :

    echo -n " Ajout route défaut -> eth0"
    route add -net default gw 192.168.1.254 dev eth0 #  eth0
    echo "  -> [ Fait ]"

# Sauvegarde de la table de routage :
    route>/etc/rc.d/routage-`date +%Y-%m-%d_%T`.txt
exit 0

Toutefois, les routes se mettent en place toutes seules au démarrage du système.
Où puis-je faire en sorte que ces routes ne se mettent pas en place au démarrage ?

Jean-Pierre

#4

Bonjour,
Je fais un up mais en complètant un peu mes explications :

  • je peux pinger les machines du réseau interne sur eth0 (192.169.1.0);
  • je peux pinger les machines à partir du serveur sur eth0;
  • je peux pinger le modem sur 192.168.0.1 à partir du serveur ou d’une machine du réseau;

mais toutes les requêtes (dns, http, …) venant tant du serveur que d’une quelconque machine du réseau, ne traversent pas le pare-feu BIND9.

Ce qui est étonnant puisqu’une machine avec l’@ 192.168.1.4 peut pinger le modem adsl LiveBox qui lui porte l’@ 192.168.0.1, soit sur un autre réseau avec comme interface eth1.

Si quelqu’un peut me donner une solution elle sera attendue comme le messie.

Merci par avance.
Jean-Pierre

#5

  1. Vérifie ton fichier /etc/network/interfaces, tu dois avoir plusieurs passerelles déclarées.

  2. Tes règles iptables sont toutes à ACCEPT, il te suffit de laisser la politique par défaut à ACCEPT et de virer les autres (lignes -P ACCEPT) (Z: Lecture rapide de tes règles, j’ai peut être raté un truc).

  3. Si ton réseau est 192.168.1.0/24, ta passerelle WIFI 192.168.10.1 et ta passerelle 12.34.56.78 sur eth1, tu peux faire

route add -net 192.168.1.0/24 gw 192.168.10.1
route add default gw 12.34.56.78

#6

A quoi est censé servir ce tas d’inepties ?

Après le désormais célébrissime pare-feu OpenOffice, voilà le pare-feu BIND9…

François a raison, tu n’as pas montré le contenu de /etc/network/interfaces ni son résultat (avec ifconfig ou ip addr show).

#7

[quote=“PascalHambourg”]

Après le désormais célébrissime pare-feu OpenOffice, voilà le pare-feu BIND9…[/quote]

Damned on m’aurait menti :slightly_smiling:, la question est de savoir comment diable ce fran.b est apparu dans ton message, association d’idées surement :slightly_smiling:

Sinon je pense que tu fais plutôt référence à son rc.firewall que rc.route… Ça ressemble à un script tout fait avec des DROP ou REJECT remplacés par des ACCEPT parce rien ne passait.

#8

J’aurai cliqué sur le mauvais bouton “citer”…

Non, je parle bien du rc.route aberrant avec ses multiples routes par défaut.

Quant aux règles iptables, ma position est simple : d’abord on teste le routage et la connectivité du routeur avec ses réseaux et internet sans règles iptables, puis on ajoute juste les règles de NAT (sans filtrage, donc) pour tester la connectivité des réseaux avec internet et enfin on ajoute le filtrage. Si ça coince à un moment, on sait d’où ça vient.

#9

+1 pour le fichier rc.route (jamais vu un truc pareil ?)

la route par defaut est précisé dans le fichier “interfaces”,
des routes complémentaires peuvent également être ajouté dans ce fichier tel que décrit par exemple ici (tout en bas) :
cyberciti.biz/tips/configuri … stems.html

Tu n’as pas montré ta config ip d’un client (+ table de routage)…

Je te conseille de suivre le conseille de PascalHambourg :

procède étape par étape : rien ne sert de mettre en place le firewall tant que le routage n’est pas OK.
et comme l’a fait remarquer fran.b, ton fichier rc.firewall me semble également “absurde”.

sinon, perso, j’utilise fwbuilder pour gérer les règles iptable …

#10

[quote=“PascalHambourg”]
Non, je parle bien du rc.route aberrant avec ses multiples routes par défaut.[/quote]
Ah, je suis plus indulgent que toi, c’est juste qu’il n’a pas compris les principes du routage, c’est moins grave à mles yeux (de prof) que recopier sans comprendre, déformation sans doute…

Tu as testé ce genre d’outil https://github.com/zeha/iptables-simulate (simulteur permettant de tester des règles iptables, du moins je pense)? je suis étonné que ça n’existe pas, ce serait plus utile à mon avis que des GUI ou autres surcouches à iptables.

#11

Bonjour à tous,

d’abord merci de toutes vos réponses.

En ce qui concerne le fichier rc.route, je l’ai mis en place pour tester le routage en interne sur le local (LAN), qui lui fonctionne très bien. Je n’ai toutefois laissé que la première ligne soit :

la table se remplissant d’elle-même.

Quant aux règles minimales du pare-feu, elles ont été testées et elles fonctionnent correctement (sauf la navigation Internet sur le serveur, ce qui est secondaire).

Il faut que je vous précise quelque chose : lors du lancement des interfaces eth0 (sur la carte mère du serveur) et eth1 sur le port USB, le routage ne se fait pas correctement. En effet, en retapant la commande dhclient eth1 en mode console, le routage se fait correctement. Celà m’a amené à vider tous les fichiers de configuration, de pare-feu et routage et de ne laisser que le strict minimum utile.

Je voudrais répondre à certains d’entre vous qui n’avaient jamais vu autant de bêtises dans un fichier de routage, il faut dire qu’après avoir passé prêt d’un mois à tenter de faire fonctionner :
1°) un serveur DHCP, qui a fonctionné en deux jours;
2°) un serveur BIND9, qu’il m’a fallu modifier un peu à cause d’un bug (voir http://www.jordimir.com/2012/05/05/securite-bind-dns-query-denied/), fesait n’importe quoi (sûrement à cause du fait qu’il ne pouvait se connecter aux serveurs primaires pour parfaire son cache) et qui finalement fonctionne à merveille (deux semaines non consécutives par étapes);
3°) un routeur sur deux réseaux :

  • connexion Internet sur le réseau 192.168.0.0 avec mise à jour par le dhcp de la LiveBox (quelle grosse m…);
  • connexion locale sur le réseau 192.168.1.0, qui après tout çà fonctionne correctement du premier coup (serveur de fichiers sur nas Synology, imprimantes LaserJet 4 et Brother MFC-820CW, disque dur multimédia et d’autres joyeusetés que je branche sur l’ethernet à l’envie).

Il a fallu que je remarque que le nom de la LiveBox n’apparaissait pas lors d’un route avec résolution de noms.
Par pure mégarde, j’ai tapé [quote]dhclient eth1[/quote] afin que ce nom vienne et que le routage se fasse correctement, que le serveur de résolution de noms se mette à jour de lui-même, que la résolution inverse fonctionne, que la mise à l’heure des serveurs et postes clients soit enfin effective, que le dépot Debian mirroir se mette à jour, …

Depuis, le ping google.fr ainsi que toutes les autres requêtes répondent correctement.

La partie ci-dessus n’est qu’une explication à tout ce “bordel”, à cause de mon modem adsl, et non polémique.

En tout cas, merci de vos réponses.

J’aurais toutefois une dernière question : qu’elle est la règle à mettre dans iptables pour que le serveur puisse se connecter à l’interface du modem et puisse naviguer sur le net ? Les serveurs internes sont eux accessibles à partir du routeur.

Merci pour vos réponses.

#12

[quote=“joseph75014”]Par pure mégarde, j’ai tapé [quote]dhclient eth1[/quote] afin que ce nom vienne et que le routage se fasse correctement, que le serveur de résolution de noms se mette à jour de lui-même, que la résolution inverse fonctionne, que la mise à l’heure des serveurs et postes clients soit enfin effective, que le dépot Debian mirroir se mette à jour, …

Depuis, le ping google.fr ainsi que toutes les autres requêtes répondent correctement.
[/quote]dhclient a fait une table de routage correcte.[quote]
La partie ci-dessus n’est qu’une explication à tout ce “bordel”, à cause de mon modem adsl, et non polémique.

En tout cas, merci de vos réponses.

J’aurais toutefois une dernière question : qu’elle est la règle à mettre dans iptables pour que le serveur puisse se connecter à l’interface du modem et puisse naviguer sur le net ? Les serveurs internes sont eux accessibles à partir du routeur.

Merci pour vos réponses.[/quote]

Tu confonds iptables qui établit les règles d’«accès» de la machine (ports ouverts en entrée et /ou sortie, etc) et le routage proprement dit. Il te faut définir une route par defaut (route add default gw x.y.z.t) ou x.y.z.t est la passerelle par défaut, sans doute l’adresse IP de ton modem si celui ci est en mode routeur (je parie 192.168.1.1). Le problème est qu’il faut une seule route par défaut. De là viennent tous tes problèmes. Imagine un carrefour avec deux panneaux «Toutes directions», tu fais quoi en voiture si tu ne vas pas dans les autres directions indiquées (genre gare SNCF et centre ville?? Là c’est pareil.

#13

Bonjour

et merci pour ta réponse fran.b.

Non, je ne confonds pas le routage et le bloquage par pare-feu. Mais, il se trouve qu’en tapant dhclient eth1en mode console, le routage fonctionne correctement et tous les systèmes se mettent à jour automatiquement.

Pour ce qui est de la configuration, j’ai éliminé au fur et à mesure toutes les lignes inutiles.
Je pense mettre en ligne mes fichiers de configuration sous peu avant de mettre ce fil en résolu.

A bientôt.
Jean-Pierre

#14

Bonjour à tous,

je mets ce fil de discussion en résolu car après de longues recherches, erreurs et tests
mon serveur local fonctionne correctement :

  • le DHCP assigne bien les adresses IP en fonction des adresses physiques MAC sur les deux réseaux internes;
  • le DHCP assigne bien les adresses IP aléatoires pour les machines itinérantes sur les deux réseaux internes;
  • le DNS résout bien les noms tant en direct qu’en inverse sur les deux réseaux internes;
  • le routage se fait correctement et les machines sur les deux réseaux internes
    (192.168.1.0/24 et 192.168.2.0/24) se connectent bien à Internet sur la LiveBox;
  • le site miroir-Debian sur le serveur local fait bien sa mise à jour une fois par
    semaine.

Je serais totalement heureux si je parvenais à résoudre les noms d’un réseau interne
sur l’autre. En effet, lorsque je tente de résoudre le nom d’une machine située sur
le réseau 192.168.1.0/24 à partir d’une machine située sur le réseau 192.168.2.0/24 et vice-versa,
la réponse est immanquablement ping: unknown host XXXX.
Le serveur DNS interne ne fait pas le pont entre les deux réseaux internes. Pour l’instant, je n’ai pas trouvé de
solution, toutefois je continue mes recherches.

Si je n’y parviens pas, je vais sans doute ouvrir un autre fil pour vous demander des
conseils. Dans ce nouveau fil, je mettrai mes fichiers de configuration comme promis
dans une de mes réponses précédentes.

Merci encore pour les réponses précédentes.
Jean-Pierre