Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

[OpenVPN] Relier plusieurs réseaux (LAN-to-LAN et bridge)

Bonjour, Pour le contexte : j'essaie de relier entre eux plusieurs LAN de ma famille pour qu'ils n'en forment qu'un. Tout le monde est dans la plage 192.168.10.0/24. (Plus de détails : [url]http://www.frameip.com/forum/2249-vpn-et-sous-reseaux.htm[/url]). Sur le LAN 1, j'ai un poste sous Ubuntu Server 9.10 qui lance plusieurs instances d'OpenVPN, ce qui me permet de dédier une interface tapX à chaque LAN que je veux raccorder (cela servira plus tard pour la configuration du firewall). Toute les interfaces tapX sont rassemblées dans un pont br0 avec l'interface eth0 du LAN. Une des instances d'OpenVPN est dédiée aux clients nomades. Pour eux, tout fonctionne très bien : ils accèdent à tout le LAN, et tous les postes du LAN accèdent aux clients nomades. Phase suivante : j'ai raccordé un des postes du LAN 2 (disons PC 2, sous Kubuntu 9.10) au serveur OpenVPN. Là encore, son interface tap0 est bridgée avec son interface reliée au LAN 2 (wlan0). C'est alors que ça se complique : - PC 2 accède à tout LAN 1 -> OK ; - PC 2 accède même aux clients nomades (hors LAN 1 donc) -> OK ; - aucun autre poste de LAN 2 n'accède à LAN 1, pas même au serveur OpenVPN ; - le serveur OpenVPN (sur LAN 1) accède uniquement à PC 2, mais pas au reste de LAN 2 ; - aucun autre poste de LAN 1 n'accède à LAN 2, en-dehors de PC 2. En résumé donc, PC 2, alors qu'il devrait servir de passerelle entre les deux LAN via le serveur OpenVPN, se comporte simplement comme n'importe quel autre client nomade. Il n'y a pas de firewall dans tout cela pour le moment. Est-ce que j'oublie quelque chose ? Le fait que le bridge sur PC 2 comporte une interface sans fil peut-il être à l'origine du problème ? Quelqu'un a-t-il une idée ? Blue Duck

Regarde du coté de l'activation du routage et de la propagation des broadcasts. A mon avis il va falloir sortir le sniffer pour y regarder de plus près.

Petite erreur dans mon premier post (corrigée) : les postes de LAN 1 accèdent à PC 2 (réponse au ping OK) mais pas aux autres postes de LAN 2. Comment est-ce que je « regarde du côté de l'activation du routage et de la propagation des broadcasts » ? Pour les tables de routage, chaque poste a la même quel que soit le LAN : [code:1:f930a432be]Adresse/masque : 192.168.10.0/24 - Passerelle : * Adresse/masque : default - Passerelle : (IP du routeur)[/code:1:f930a432be] Est-ce pour la propagation des broadcasts qu'il faut un sniffer ? Lequel me recommandes-tu, que je cherche comment il fonctionne ? J'ai l'impression que c'est le pont côté client qui ne fait pas son boulot... Blue Duck

Sous unix, le routage s'active dans le fichier /proc/sys/net/ipv4/ip_forward A 1 il route, à 0 il route pas. Comme sniffer tu as wireshark si tu as l'environnement graphique, ou tcpdump en ligne de commande. Sachant que les flux récupérés avec tcpdump peuvent ensuite être exportés sous wireshark sur une autre machine graphique, si tu n'es pas à l'aise en ligne de commande.

Concernant /proc/sys/net/ipv4/ip_forward, il vaut 0, aussi bien sur le client (PC 2) que sur le serveur... je veux bien le passer à 1 (comment ? avec vim ?), mais avant je voudrais être sûr de comprendre. S'il est à 0 y compris sur le serveur, c'est que le serveur ne route pas. Pourtant, PC 2 accède quand même aux postes derrière le serveur... Pour tcpdump, je vais de ce pas l'installer et tâcher de comprendre comment on s'en sert. Sympa tcpdump, mais ça pique les yeux... Je ne suis pas sûr de ce que je cherche. Test 1 : je lance tcpdump -i br0 sur le client (PC 2), et je fais un ping dessus depuis le serveur. L'ICMP Echo Request entre, et tout de suite derrière sort un ICMP Echo Reply. Test 2 : tcpdump est toujours lancé sur le client, je tente un ping depuis un autre poste de LAN 1. Même résultat, ping OK. Test 3 : tcpdump toujours lancé sur le client, je fais un ping depuis le serveur vers un poste du LAN 2 (donc derrière le client). Là ça change un peu : je vois bien arriver un Echo Request vers le poste derrière PC 2, mais pas d'Echo Reply dans l'autre sens ; un 'who-has' sur la destination cirrcule, mais n'obtient pas de réponse. Le ping retourne un Destination Host Unreachable. je ne sais pas si ç'a une importance, mais la destination du ping n'apparaît pas sous forme numérique comme la source, mais sous la forme NETBIOSNAME.lan... Test 4 : tcpdump encore lancé sur le client, tentative de ping depuis un autre poste de LAN 1. L'Echo Request n'arrive même pas au client, Destination Host Unreachable pour le ping. Test 4 bis : tcpdump lancé sur le serveur, cette fois. Re-tentative de ping depuis le poste du LAN 1. L'Echo Request arrive bien au serveur, mais il ne la relaie pas : sa requête ARP 'who-has' pour trouver la route vers le poste de LAN 2 n'obtient pas de réponse. Je ne suis pas sûr de comprendre ce qui se passe. Je serais tenté de dire que le serveur OpenVPN ne sait pas faire passer une route par le client PC 2, mais si c'est ça je ne sais pas pourquoi. Pourquoi les 'who-has' n'obtiennent pas de réponse ? Merci de ton temps, Blue Duck

En le mettant à 0, la machine n'est pas censée relayer des paquets qui ne sont pas pour elle. A 1, elle le fait. Je ne connais pas bien le mode bridge sous linux, mais sous OpenBSD cela est nécessaire.

Rapport de mes tentatives tcpdump dans le post précédent... Je vais essayer d'activer le routage, on va bien voir.

"Test 3 : tcpdump toujours lancé sur le client, je fais un ping depuis le serveur vers un poste du LAN 2 (donc derrière le client). Là ça change un peu : je vois bien arriver un Echo Request vers le poste derrière PC 2, mais pas d'Echo Reply dans l'autre sens ; un 'who-has' sur la destination cirrcule, mais n'obtient pas de réponse. Le ping retourne un Destination Host Unreachable. " Voilà la source du problème. La requête ping arrive bien à destination. En réponse, la machine fait d'abord une requête ARP pour avoir l'adresse MAC de la machine qui a envoyé le ping, mais cette requête ARP ne trouve pas de réponse et donc destination unreachable. Il faut donc maintenant suivre la requête ARP et voir pourquoi elle n'est pas reçue par l'emetteur. 1- Il faut peut-etre que le PC2 fasse proxy ARP 2- Sinon il faut qu'il relaye les broadcasts ARP.

Je ne vois pas de requête ARP sur l'adresse MAC de l'émetteur : le 'who-has' est lancé sur la destination du ping (le poste de LAN 2), et je ne vois pas d'ARP Reply. Suis-je censé en voir un, d'abord ? Ça me paraît surprenant que le PC 2 lance un 'who-has' pour un poste de son propre réseau physique, et que le poste concerné ne réponde pas, non ? Comment suivre la requête ARP ? Comment peut-on forcer le PC 2 à faire proxy ARP ou à relayer les broadcasts ARP ?

Oui, mais si le echo request arrive bien sur la machine destinatrice, c'est que le PC2 a su trouver son adresse mac. Tu pourras voir sur chacune des machines si elle a l'adresse mac des autres en affichant leur table arp: arp -an

Bonsoir ! J'ai toujours le même problème, mais je n'ai pas eu le temps de m'en occuper dernièrement ; j'enchaîne. Question 1 : mon serveur a bien dans sa table ARP l'adresse MAC d'un client du LAN2, mais il n'arrive pas à le pinguer. Qu'est-ce que cela signifie ? Question 2 : en cherchant un petit peu de documentation sur le proxy ARP dont tu parlais, je suis tombé sur une ligne qui m'interpelle. Je cite : Normalement, pour réaliser l'interconnexion, on pourrait : * utiliser le logiciel IP-Bridge (voir le Bridge mini-HOWTO) pour réaliser un pont entre les deux interfaces réseau. Malheureusement, la carte Ethernet sans-fil ne peut pas être mise en mode ``promiscuous'' (autrement dit elle ne peut pas voir tous les paquets circulant sur le réseau 1). C'est principalement à cause de la faible bande passante de la carte Ethernet sans-fil (2 Mbits/sec), ce qui implique que nous ne voulons pas supporter le trafic qui n'est pas destiné à une autre machine sans-fil - dans notre cas la machine A -, ou les diffusions générales (broadcasts). De plus, un pont charge assez lourdement le processeur. [i:0aff5fbb58](...) Mon bridge wlan0/tap0 commence à sentir le roussi, non ? Je vais continuer à chercher pour savoir si aucune carte wifi n'est capable de basculer en mode promiscuous, ou s'il y a une manip' particulière à faire avec la mienne. Mais si tu as de l'expérience avec ça... Blue Duck