[Résolu] Réseau : configuration passerelle routée => définition des routes ?

Bonjour,

je rencontre un problème dans la configuration du point d’accès wifi (“une passerelle”) vers mon réseau local.

1/ le but recherché :
Je souhaite que des machines se connectant au point d’accès wifi puissent avoir accès aux ressources(*) du réseau local.
Pour le moment je souhaite resté en “passerelle routée”.

(*) : pour le moment la seule et unique ressource mise à dispo est un serveur ssh (sur pc_B)

2/ la topologie

  switch
     |--- eth0 (192.168.0.77)  pc_A 
     |--- eth0 (192.168.0.118) pc_B
     |--- eth0 (192.168.0.180) pc_C (192.168.1.1) wlan0
                                           ^
                                           .
                                           .
                                           .
                       "client_wifi (192.168.1.200)"

en résumé :

  • trois machines sont branchées sur un switch par cable rj45.
  • pc_A et pc_B ne possèdent qu’une seule interface réseau.
  • pc_B possède un serveur ssh qui écoute sur le port 22.
  • pc_C possède deux interfaces : eth0 et wlan0
  • un client_wifi possède une interface réseau wifi
  • ce switch n’est relié à aucun autre réseau (en particulier, il n’est pas relié sur ma box)
  • toutes les adresses sont statiques (pas de DHCP sur le reseau) et définies dans le fichier “/etc/network/interfaces” de chaque machine (-> je n’utilise pas NetworkManager).
  • il n’y a pas de DNS sur ce réseau (les machines sont contactées directement par leur adresses ip)

3/ ce qui est testé :
mike@pc_A $ ping 192.168.0.118 -> ok mike@pc_A $ ssh mike@192.168.0.118 -> ok mike@pc_B $ ping 192.168.0.77 -> ok mike@pc_A $ ping 192.168.0.180 -> ok mike@pc_B $ ping 192.168.0.180 -> ok mike@pc_A $ ping 192.168.1.1 -> destination host unreachable mike@pc_B $ ping 192.168.1.1 -> destination host unreachable mike@pc_A $ ping 192.168.1.200 -> destination host unreachable mike@pc_B $ ping 192.168.1.200 -> destination host unreachable mike@pc_C $ ping 192.168.1.200 -> ok [edit suite à question de Almtesh] mike@client_wifi $ ssh mike@192.168.0.118 -> failed (no route to host), (voir plus bas)

4/ un mot sur pc_C :

  • ip_forward est bien positionné à “1” [edit : ip_forward en ipv4 /edit]
  • [edit : la carte wifi est basée sur un chipset : ralink RT5370 avec le paquet non-free firmware-ralink installé sur la machine /edit]
  • hostapd est configuré et est fonctionnel (le client_wifi s’authentifie bien sur pc_C)
  • les POLICY sont toutes à ACCEPT (en particulier la chaîne FORWARD).
  • aucune règle dans la table nat n’est définie pour le moment.

# route -n

Destination    Gateway          Genmask         Flags    Metric   Ref    USe     IFace
0.0.0.0        192.168.0.254    0.0.0.0         UG       0        0      0       eth0
192.168.0.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

5/ ce qui ne fonctionne pas :
a) quand le client wifi (un smartphone android équipé de “connectbot”, un client ssh) se connecte au réseau wifi diffusé par la passerelle pc_C, alors la tentative de connexion par le client ssh donne :

ssh mike@192.168.0.118
failed to connect to /192.168.0.118 (port 22) connect failed: EHOSTUNREACH (No route to host)

b) J’ai essayé d’ajouter 2 routes supplémentaires [edit: dans la table de routage de pc_C /edit] , mais cela n’a pas fonctionné (-> “la connexion du client_wifi au serveur ssh de pc_C n’est toujours pas possible”).
route add -net 192.168.1.0 gw 192.168.0.180
route add -net 192.168.0.0 gw 192.168.1.1

c) j’ai également essayé de mettre un règle dans la table nat, mais cela n’a pas résolu le problème (la connexion de client_wifi au serveur ssh sur pc_B n’est pas possible).

De plus, j’ai cru (mon niveau de compétences dans les route est nul) comprendre que l’ajout de règle dans la table NAT n’était pas une bonne solution (mais j’ai peut mal compris, ou sorti la citation de son contexte) :

(Configuration passerelle) :

Tu n’as pas besoin de NAT/masquerade sur un réseau privé.
Le NAT est parfois une solution, parfois la seule solution, mais toujours une mauvaise solution. La bonne solution, c’est le routage.
(extrait d’une réponse de Pascal Hambourg)

Si vous avez des pistes pour résoudre mon problème, un grand merci !
Si il manque des infos ou des résultats des commandes, n’hésitez pas à me demander.

mk

Essaie de joindre le client wifi avec le pc_C, c’est probablement parce que la route pour aller vers le réseau wifi n’est pas connue de pc_A et pc_B et/ou que le client wifi ne connait pas le réseau des pc_A et pc_B.

hello,

merci pour la réponse.
voila le résultat de la commande :

mike@pc_C $ ping 192.168.1.200 -> ok (4 packets emitted, 4 packets received)

(j’ai édité mon 1er post pour compléter avec cette commande).

Ce n’est pas pratique.
Tu peux me donner aussi les tables de routages des pc_A, pc_B et client wifi ?

pc_A :
# route -n

Destination    Gateway          Genmask         Flags    Metric   Ref    USe     IFace
0.0.0.0        192.168.0.254    0.0.0.0         UG       0        0      0       eth0
192.168.0.0    0.0.0.0          255.255.255.0   U        0        0      0       eth0

pc_B :
# route -n

Destination    Gateway          Genmask         Flags    Metric   Ref    USe     IFace
0.0.0.0        192.168.0.254    0.0.0.0         UG       0        0      0       eth0
169.254.0.0    0.0.0.0          255.255.0.0     U        202      0      0       eth0
192.168.0.0    0.0.0.0          255.255.255.0   U        0        0      0       eth0

note : la machine pc_B est un raspberry sur lequel est installé raspbian.
mis à part la config du parefeu et la definition de la l’adresse ip en statique, je n’ai touché à rien (en particulier, je n’ai pas touché à la table de routage qui semble étrange, non ?)

pour client_wifi, je ne l’ai pas… (c’est un smartphone non rooté…)
(je vais essayé de mettre un pc en wifi et faire le test… il faut que je trouve une clé wifi …)

merci

Ah, d’accord, la route pour le réseau 192.168.1.xx n’est pas bonne, elle passe par 192.168.0.254 (route par défaut) au lieu de 192.168.0.180.
Sur pc_A et pc_B, tu dois ajouter une route vers 192.168.1.0/24 via 192.168.0.180, ou faire l’opération sur 192.168.0.254.

ha OK, merci !
je vais faire les modif (des tables de routage de pc_A et pc_B) et tester ça.

question :
quand tu dis : "ou faire l’opération sur 192.168.0.254"
qu’entends tu exactement ?
-> en effet pour le moment, cette machine (…254) n’existe pas sur mon réseau.
elle existera, mais plus tard (quand je raccorderai ce réseau à ma box)
et elle sera bien gateway par défaut (mais c’est une autre histoire).

remarque :
je comprends que la table de routage de CHAQUE client doit être adaptée à la topologie du réseau ???
je pensais qu’au contraire, c’était la table de routage des routeurs qui devait être adaptée.

remarque2 :
un client se connectant en wifi mais pour lequel je n’ai pas accès à la table de routage (android non rooté par exemple) ne pourra pas se connecter à mon réseau dans cette configuration, c’est bien ça ?
(il faudrait que je passe donc en “passerelle pontée”).

merci

Oh là, plein de choses :

Pour pc_A et pc_B, le truc qui se trouve (ou se trouvera) à l’adresse 192.168.0.254 sera la passerelle par défaut. Du coup, si cette passerelle sait comment aller sur le réseau wifi, pc_A et pc_B n’ont pas besoin de le savoir. pour aller de pc_[AB] au client wifi, ils envoient à 192.168.0.254, qui renvoie à pc_C, et le client wifi, pour répondre, envoie au pc_C, qui sait directement le passer au pc_[AB].

Dommage, du coup…

enfin, du moins, tant que 192.168.0.254 n’existe pas sur le réseau.

Oui, aussi, en fait, il faut suivre le cheminement des paquets en suivant les tables de routage. Si tout le monde doit joindre tout le monde, tout le monde doit savoir par où passer, et si le chemin n’est pas direct, tout le monde doit envoyer vers la machine qui saura faire avancer les paquets dans la bonne direction.

Non, car ton client Android est dans une position qui permet de ne pas jongler avec les tables de routage.
Étant donné qu’il se trouve dans un cul-de-sac de réseau, il ne doit connaître que le routeur qui permet de sortir, et là, il n’y a que pc_C.

J’espère que je suis clair.

hello,

un grand merci pour toutes ces explications !!
je commence à comprendre le fonctionnement des routes et du routage.

et oui, tu as été parfaitement clair.

bon weekend

Hello,

entre les 2 configurations proposées (1/ configuration de routes sur chaque clients OU 2/ ajout d’une passerelle sur le réseau),
j’ai choisi d’ajouter la “passerelle”.

j’ai ensuite, sur cette passerelle, fait :
# route add -net 192.168.1.0/24 gw 192.168.0.180

Cela a corrigé les problèmes de :

  • destination host unreachable
    et de
  • failed (no route to host),

un grand merci !!!

Voilà, rien ne vaut une passerelle par défaut pour gérer toutes les routes.