Je viens vous demander conseil à propos d'un VPN.
Dans le cadre de mon travail, je dois mettre en place un VPN pour rendre accessible un PDC Active Directory Windows 2003 (et pourquoi pas d'autres machines par la suite) qui se trouve sur un réseau distant, coupé par un réseau que je nommerai DNZ.
J'utilise alors OpenVPN sous linux et celui fonctionne assez bien. J'ai mis en place un tunnel VPN entre deux routeurs machines linux sur Internet, chez moi et chez un ami pour les test.
Depuis mon poste, je peut atteindre une adresse IP de son réseau comme cette machine étais sur mon réseau interne. Je viens d'ajouter deux nouvelles routes pour atteindres des macchines internes à son réseau et je peut également y accèder depuis le routeur.
Cependant, mon soucis est que depuis une machine tierce connectée sur ma machine routeur, je n'arrive pas à atteindre ses machines via le tunnel VPN, ni par un simple ping, ni par un tracert.
Le tracert m'indique que je passe effectivement par mon routeur / vpn, mais au bout du deuxième saut, rien ne se produit (et ainsi de suite).
Voici ma table de route sur mon routeur / vpn :
root@cerbere:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.254 * 255.255.255.255 UH 0 0 0 tun1
192.168.0.1 * 255.255.255.255 UH 0 0 0 tun1
10.4.0.2 * 255.255.255.255 UH 0 0 0 tun1
82.***.***.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth2
localnet * 255.255.255.0 U 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 82.***.***.254 0.0.0.0 UG 0 0 0 eth0
Voici la route du routeur / vpn de mon ami :
root@router:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.4.0.1 * 255.255.255.255 UH 0 0 0 tun1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth3
192.168.0.0 * 255.255.255.0 U 0 0 0 eth2
localnet * 255.255.255.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 81.***.***.254 0.0.0.0 UG 1 0 0 eth0
et voici enfin les deux commandes pour établir le tunnel VPN (si ca peut aider d'autres, avec compression de données et clefs symétriques en RSA 2048 bits) :
Chez moi :
openvpn --remote 81.***.***.*** --port 8000 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --comp-lzo --secret /root/vpn.key 1> /dev/null 2> /dev/null &
Chez lui :
openvpn --remote 82.***.***.*** --port 8000 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --comp-lzo --secret /root/vpn.key 1> /dev/null 2> /dev/null &
Bien sûr, les IP 10.4.0.2 et 10.4.0.1 sont simplement présente pour les tests et la mise en place du tunnel, ca changera surement ...
J'ai pu lire également qu'il y avais des 'client VPN', mais je n'arrive pas à saisir la différence si il en as une entre tunnel VPN et serveur VPN. Pour moi, quand un tunnel est mis en place, le routage fait la suite ... Mais là non. Tout fonctionne entre les deux routeurs, mais pas sur des machines clientes qui sont connectées sur les routeurs VPN.
Si une personne qui à déjà mis en place ce genre de principe et qu'il puisse me guider ...
Merci d'avance.
# Route des clients
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
[^] # Re: Route des clients
Posté par un compte supprimé . Évalué à 1.
[^] # Re: Route des clients
Posté par un compte supprimé . Évalué à 1.
L'avanatage de gérer les routes sur un routeur, c'est d'éviter les route sur chaque machine ... Mais peut être il y a t'il ecore cette histoire de table de routage machine et table de routage réseau ...
J'y pense .... une table de route machine doit être définie sur chaque machine ? Si oui, comment je dois faire avec chaques machines ?
Merci d'avance
[^] # Re: Route des clients
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
Dans ton cas, puisqu'il semble que de ton côté le routage est OK, es-tu sûr que de l'autre côté les machines clientes sont bien configurées ? Si par exemple une machine cliente distante n'a pas de route par défaut pour répondre aux pings provenant de chez toi, ça ne passera pas.
[^] # Re: Route des clients
Posté par un compte supprimé . Évalué à 1.
Par contre, les machines clientes distantes (sur le réseau de mon collègue) ont bien une paserelle pour se connecter sur Internet.
Par contre, on utilise à peu près les mêmes IP ... mais je ne pense pas que ca soit un conflit IP, comme on défini des route machine et non réseau, je fais bien attention de ne pas router une IP machine qui existerait déjà sur mon réseau vers le réseau distant
Chacun de nos réseaux a un routeur / VPN accessible en interne via 192.168.0.254/C, ainsi qu'une IP VPN bien différentes sur no deux réseau, 10.0.4.1 et 10.0.4.2.
Je ne vois donc pas ce qui peu clocher ...
[^] # Re: Route des clients
Posté par NeoX . Évalué à 2.
je resume cette phrase par un shema qui nous montrera de suite ce qui ne va pas
(reseau 1 : 192.168.0.0/24) -> 192.168.0.254 -> internet <- 192.168.0.254 <- (reseau 2 : 192.168.0.0/24)
avant meme que le vpn soit monter on voit bien que reseau 1 et reseau 2 sont identiques, du coup quand ils voudront communiqué on aura un probleme de route.
avec le VPN activé
(reseau 1 : 192.168.0.0/24) -> 10.0.4.1 -> internet <- 10.0.4.2 <- (reseau 2 : 192.168.0.0/24)
comment veux-tu dire à reseau 1 d'envoyer ces paquets à 10.0.4.2 pour joindre une machine de l'autre reseau ?
l'idée est bonne, mais ne serait fonctionnelle que si reseau1 != reseau2
ex : 192.168.0.0/24 pour reseau 1 et 192.168.1.0/24 pour reseau 2
la route serait alors sur gw1
192.168.1.0 -> par 10.0.4.2
sur gw2
192.168.0.0 -> par 10.0.4.1
et à ce moment là ta machine 192.168.0.1 qui veut communiquer avec la machine de ton pote 192.168.1.2 enverra ses paquets à la passerelle (car pas le meme reseau), la passerelle l'enverra au travers du VPN à l'autre passerelle...
[^] # Re: Route des clients
Posté par un compte supprimé . Évalué à 1.
J'arrive à comprend le soucis.
Je vais donc faire deux réseaux entièrement différents à mon boulot pour éviter ce genre de situation.
Par contre ainsi, avec deux réseaux différents, je pourrai mettre une route non plus host mais réseau cette fois ci pour atteindre depuis le réseau 1, le réseau 2 distant si je comprend bien ? Ce peut faciliter la jonction entre les deux réseau par un simple tunnel.
Par contre, je ne vois pas bien à ce que peut servir le port 8000 dans tout cas ... est ce pour permettre la connexion entre les deux postes ? Car le port 8000 n'est pas ouvert sur l'un ou l'autre réseau depuis Internet alors que le VPN fonctionne dessus.
Je sais bien que le VPN est là pour l'interne seulement ... Mais il doit bien y avoir un moment où il y a une communication Internet cette fois ci. Ou alors, le port 8000 n'est là seulement pour des reverses shell, l'un et l'autre se connecte sur le port 8000, même non ouverts, si les deux communiquent correctement, la liaison est établie ...
Merci en tout cas Neox. Mais il n'y a t'il pas moyen de contourner ceci sans changer entièrement de réseau, ce serai ce que modifier l'IP paserelle, est ce que ca fonctionnerai ? en sachant que le route vers un host précis devrai fonctionner ...
[^] # Re: Route des clients
Posté par NeoX . Évalué à 1.
je te rassure, je ne lis pas que la derniere phrase, neanmoins c'est celle qui amene la question.
cela peut fonctionner.
en fait cela devrait meme fonctionner comme avant, seulement je reflechissais route network et pas route host.
avec un route host tu dois pouvoir dire à PC1
pour l'hote 192.168.0.X, passes par passerelle2 (10.0.4.2)
à condition toutefois que l'ip 192.168.0.X n'existe pas sur reseau 1.
en meme temps faire du routage pour chaque hote c'est un peu la misere à gerer, alors qu'une gestion de route sur une "routeur" ca semble tout de suite plus logique.
et comme les passerelles sont en 192.168.0.254, je dirais
[^] # Re: Route des clients
Posté par NeoX . Évalué à 1.
je te rassure, je ne lis pas que la derniere phrase, neanmoins c'est celle qui amene la question.
cela peut fonctionner.
en fait cela devrait meme fonctionner comme avant, seulement je reflechissais route network et pas route host.
avec un route host tu dois pouvoir dire à PC1
pour l'hote 192.168.0.X, passes par passerelle2 (10.0.4.2)
à condition toutefois que l'ip 192.168.0.X n'existe pas sur reseau 1.
en meme temps faire du routage pour chaque hote c'est un peu la misere à gerer, alors qu'une gestion de route sur une "routeur" ca semble tout de suite plus logique.
et comme les passerelles sont en 192.168.0.254, mon instinct me dis que ce sont des freebox et il faut savoir que tu peux te faire ton reseau en 192.168.X.Y avec 1<X<254 en modifiant simplement le DHCP de la freebox.
[^] # Re: Route des clients
Posté par un compte supprimé . Évalué à 1.
Effectivement, sauf que dans mon cas, il n'y a qu'une machine qui doit être accessible sur les deux réseaux, d'où un VPN. Je pense que comme il n'y avais qu'une machine, un serveur VPN aurrai été judicieux, mais en mettant un tunnel VPN, celà me permet d'ajouter d'autres machines, mais il n'y en aurra que très peu.
Après, la qestion, c'est que cette machine vas être un Active Directory ...
Attaquer le PDC via son IP, c'est une chose, mais pour le simple ajout d'une machine au Domaine, il y a t'il comme avant le DNS? une référence au Netbios de la machine ? Comme il y a tout de même un semi routage et que le NETBIOS n'est pas routable (non, pitié, pas de WINS ^^); est ce que le DNS devrai suffire ?
Ces questions dépassent un peu le VPN et je pense découvrir celà par la suite. J'ai un apprenti qui vas revenir en janvier (et si il lis ceci), voici sans doute quelque chose qui l'attend ... héhé.
" comme les passerelles sont en 192.168.0.254, mon instinct me dis que ce sont des freebox "
Ce sont effectivement des Freebox, mais en mode modem (pas routeur). Donc ca aurrai pu être autre chose ;)
Voici finalement mon réseau personnel : http://www.franceserv.fr/images/fs_reseau.jpg
Après tous le mal que je me suis donné à xxx mes IP (haha).
Je met également mon étude en ligne ... Même avec le plan sous les yeux, quand tout sera mis en place, il sera impossible de passer outre les règles de filtrage iptables.
http://xander.franceserv.fr/plan_boulot.jpg
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.