Pas d'accès Internet avec OpenVPN

Version imprimable

Bonjour à tous,
Je tourne en rond depuis deux jours et je craque ...
J'ai un serveur VPN et un client sur un LAN 192.168.3.0 (client 1), j'ai un autre client sur un autre LAN en 192.168.0.0 (client2). Les adresses du VPN sont 10.7.0.0. Mon client2 se connecte au VPN, communique avec le serveur et le client1. Par contre, lorsque je suis connecté par le VPN, impossible de se connecter sur le monde extérieur :? Un simple ping une adresse quelconque ne donne aucun résultat. J'ai trouvé un tas de pages sur ce problème, mais malgré mes essais, je n'arrive à rien. Si vous avez des conseils, n'hésitez pas !
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 # server.conf # Serveur TCP/444 mode server proto tcp port 444 dev tun # Cles et certificats ca ca.crt cert server.crt key server.key dh dh1024.pem tls-auth ta.key 0 cipher AES-256-CBC # Reseau # La machine connectée sera dans le sous-réseau 10.7.0.0 # Les DNS utilisés seront ceux de google server 10.7.0.0 255.255.255.0 push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" keepalive 10 120 # Securite # Configuration de la sécurité du serveur # Le processus sera chrooté dans /etc/openvpn/jail user nobody group nogroup chroot /etc/openvpn/jail persist-key persist-tun comp-lzo # Log verb 3 mute 20 status /var/log/openvpn-status.log log-append /var/log/openvpn.log client-config-dir /etc/openvpn/staticclients
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # client.conf client dev tun proto tcp-client remote XXX.XXX.XXX.XXX 444 resolv-retry infinite cipher AES-256-CBC # Cles ca ca.crt cert jp.crt key jp.key tls-auth ta.key 1 # Securite nobind persist-key persist-tun comp-lzo verb 3
Code:

1 2 3 4 5 # Voici les routes de mon client2 sans le VPN Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
Code:

1 2 3 4 5 6 7 8 9 10 11 # Voici les routes du même client après avoir démarré le VPN Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface default 10.7.0.5 128.0.0.0 UG 0 0 0 tun0 default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0 10.7.0.1 10.7.0.5 255.255.255.255 UGH 0 0 0 tun0 10.7.0.5 * 255.255.255.255 UH 0 0 0 tun0 128.0.0.0 10.7.0.5 128.0.0.0 UG 0 0 0 tun0 XXX.XXX.XXX.XXX 192.168.0.254 255.255.255.255 UGH 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.3.0 10.7.0.5 255.255.255.0 UG 0 0 0 tun0
Premièrement, je ne comprends pas le pourquoi de la passerelle en 10.7.0.5, je n'ai aucune machine avec cette IP. Je pense que le problème vient des routes mais malgré quelques essais d'après les docs lues ici ou là, je n'y arrive pas. Help please :calim2:
Merci de m'avoir lu jusqu'au bout.

Jean-Pierre

07/12/2013, 10h23
patrice084

Citation:

Envoyé par Procyon

Je tourne en rond depuis deux jours et je craque ...

Je pense que c'est la table de routage qu'il faudrait vérifier car si votre client a bien une route vers le réseau créé par le VPN, le routeur lui n'a aucune connaissance de ce réseau. S'il existe une route par défaut pour sortir, il n'y a pas de chemin retour.
07/12/2013, 11h29
Tlams

Déjà pourquoi utiliser le protocole TCP? Tu obtiendras du TCPoverTCP, ce qui est pas vraiment terrible niveau performances...

Toujours au niveau des configurations, il faut indiquer l'adresse de l'interface externe(carte connecté au réseau "internet") à utiliser dans ton fichier conf du serveur OpenVPN

Citation:

mode server
local 172.0.0.1
proto tcp
port 444
dev tun

Au niveau de l'IPTABLES du serveur openvpn:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 172.10.1.1

Sans oublier l'ip forward dans: "/etc/sysctl.conf"
net.ipv4.ip_forward 1

Ou en mode temporaire:
echo 1 > /proc/sys/net/ipv4/ip_forward

A noter que si ton serveur openvpn possède directement une IP publique sur eth0, il faut la mettre à la place de la privé.
07/12/2013, 16h30
Procyon

Déjà, merci à vous deux pour vous être penché sur mon problème. Je pense effectivement que les tables de routage y sont pour quelque chose, mais je ne maîtrise pas ce sujet.

Citation:

Envoyé par Tlams

Déjà pourquoi utiliser le protocole TCP? Tu obtiendras du TCPoverTCP, ce qui est pas vraiment terrible niveau performances...

Oui, j'ai lu qu'il valait mieux utiliser l'UDP mais pour le moment, j'ai suivi un tuto et j'y suis resté collé pour ne pas faire de bêtises avant de comprendre la config d'OpenVPN.

Citation:

Envoyé par Tlams

Toujours au niveau des configurations, il faut indiquer l'adresse de l'interface externe(carte connecté au réseau "internet") à utiliser dans ton fichier conf du serveur OpenVPN

Le paramètre 'local' n'est effectivement pas dans le fichier de config du tuto. Pour être tout à fait clair, c'est l'adresse locale de la passerelle que je doit mettre ou l'adresse locale du serveur VPN ?

Citation:

Envoyé par Tlams

Au niveau de l'IPTABLES du serveur openvpn:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 172.10.1.1

Le tuto m'a fait entrer la commande suivante :

Code:

iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE

Je vais lire la doc de la commande iptable pour comprendre tout cela.

Citation:

Envoyé par Tlams

Sans oublier l'ip forward dans: "/etc/sysctl.conf"
net.ipv4.ip_forward 1

Ou en mode temporaire:
echo 1 > /proc/sys/net/ipv4/ip_forward

Tous cela a été fait.

Citation:

Envoyé par Tlams

A noter que si ton serveur openvpn possède directement une IP publique sur eth0, il faut la mettre à la place de la privé.

Cela n'est pas mon cas pour le moment.

Je ferais de nouveaux essais lundi car ce week-end est trop chargé :P
Je vous tiens au courant.

Cordialement,

Jean-Pierre
07/12/2013, 17h44
Tlams

L'adresse locale du serveur VPN.
Au niveau des tuto disponibles sur le net, fait gaffe... Il y a vraiment de tout.
Quant aux configurations, tout dépend aussi de ton architecture et ce que tu souhaites faire.
Il n'y a pas qu'une configuration valable...
07/12/2013, 21h02
Procyon

En fait, pour le moment, j'ai mis en place un serveur sur lequel deux clients se connectent, ceci simplement pour me faire la main. Le but ultime est de connecter trois sites disposant chacun d'un LAN et que chacune des machines sur les trois sites puissent dialoguer avec les autres. Une de mes interrogation est la suivante, la machine servant de 'passerelle' sur chaque site et faisant, soit office de serveur VPN, soit office de client, doit-elle posséder deux interfaces réseaux ou une seule suffit-elle ? Ensuite, quelle est la méthode pour que les adresses 'locales' des trois sites soient dirigées vers le VPN alors que les adresses extérieures aux sites du VPN ne transiteront pas par ce VPN. Je ne sais pas si je me suis bien fait comprendre, dans le cas contraire, n'hésitez pas à me demander des précisions.

Jean-Pierre.
08/12/2013, 08h52
patrice084

Citation:

Envoyé par Procyon

En fait, pour le moment, j'ai mis en place un serveur sur lequel deux clients se connectent, ceci simplement pour me faire la main. Le but ultime est de connecter trois sites disposant chacun d'un LAN et que chacune des machines sur les trois sites puissent dialoguer avec les autres. Une de mes interrogation est la suivante, la machine servant de 'passerelle' sur chaque site et faisant, soit office de serveur VPN, soit office de client, doit-elle posséder deux interfaces réseaux ou une seule suffit-elle ? Ensuite, quelle est la méthode pour que les adresses 'locales' des trois sites soient dirigées vers le VPN alors que les adresses extérieures aux sites du VPN ne transiteront pas par ce VPN. Je ne sais pas si je me suis bien fait comprendre, dans le cas contraire, n'hésitez pas à me demander des précisions.

J'ai l'impression, qu'il y a mauvaise interprétation et usage du VPN. Si je ne m'abuse, le VPN est fait pour qu'un utilisateur extérieur (le nomade) puisse se connecter au réseau interne et uniquement au réseau interne. S'il arrive à se connecter en VPN, c'est qu'il bénéficie d'une connexion internet et qu'il peut alors aller sur l’extérieur sans avoir besoin de se connecter au réseau interne de l'entreprise.

Dans la situation décrite ci-dessus, la machine servant "de passerelle" est en fait une machine servant de routeur et qui devra aiguiller les paquets soit vers les lans soit vers le wan. Donc 3 lans et 1 wan = 4 cartes réseaux.

Une question : les lans peuvent-ils indépendamment se connecter au wan ?
08/12/2013, 11h29
Tlams

Un VPN peut servir à interconnecter des sites.
Cela permet aux clients de voir tous les postes des sites comme du LAN et de sécuriser le trafic entre les sites.
Pour ma part, j'en est jamais monté... Donc au point de vue configuration je ne peux pas plus aider.

Pour te faciliter la vie, il serait peu être intéressant d'utiliser pfsense.
08/12/2013, 11h55
patrice084

Citation:

Envoyé par Tlams

Un VPN peut servir à interconnecter des sites.
Cela permet aux clients de voir tous les postes des sites comme du LAN et de sécuriser le trafic entre les sites.

Oui, mais dans ce cas là, le tunnel VPN est, généralement, créé entre deux parefeux pour obtenir un tunnel permanent et sécurisé, et non pas avec des machines clientes qui relève du nomadisme.
08/12/2013, 12h57
Procyon

Citation:

Envoyé par patrice084

Oui, mais dans ce cas là, le tunnel VPN est, généralement, créé entre deux parefeux pour obtenir un tunnel permanent et sécurisé, et non pas avec des machines clientes qui relève du nomadisme.

Ce sont peut-être les termes que j'utilise qui ne sont pas corrects mais pour un créer un tunnel, il faut bien un serveur d'un côté et un client de l'autre, et ce client, je ne le voyais pas comme un poste client nomade mais comme la 'passerelle' pour le VPN et ce poste n'aurais eu d'ailleurs que cette fonction.
On m'a effectivement conseillé aussi pfSense mais pour le moment, ayant l'habitude de Debian, je voulais m'initier aux VPN sur cette distribution. Comme vous devez vous en douter, l'administration réseau n'est pas mon domaine d'activité, mais je suis un peu obligé de m'y pencher faute de volontaires dans mon entreprise !

Cordialement,

Jean-Pierre.

Bonjour à tous,
Bien, voici où j'en suis et cela me satisfait pour le moment, je vais pouvoir passer à l'étape suivante.
Tout d'abord Tlam, malgré l'ajout de la ligne 'local ...', aucun changement sur le fonctionnement. Je suis donc revenu à la compréhension des routes de mon client. Je recopie l'affichage ci-dessous :
Code:

1 2 3 4 5 6 7 8 9 Destination Passerelle Genmask Indic Metric Ref Use Iface default 10.7.0.5 128.0.0.0 UG 0 0 0 tun0 default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0 10.7.0.1 10.7.0.5 255.255.255.255 UGH 0 0 0 tun0 10.7.0.5 * 255.255.255.255 UH 0 0 0 tun0 128.0.0.0 10.7.0.5 128.0.0.0 UG 0 0 0 tun0 XXX.XXX.XXX.XXX 192.168.0.254 255.255.255.255 UGH 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.3.0 10.7.0.5 255.255.255.0 UG 0 0 0 tun0
A priori, le problème vient du fait que j'ai deux passerelles. L'une d'elle est créée par le fichier de config du serveur par push "redirect-gateway def1 bypass-dhcp". Qu'à cela ne tienne, je l'enlève de la config :mouarf: A ce moment, je peux alors dialoguer avec le serveur VPN et avec une adresse quelconque du web sans problème. Par contre, je ne plus dialoguer avec les autres clients. :( J'ajoute la ligne client-to-client dans server.conf, et youpi, j'ai le fonctionnement que j'attendais, à savoir :
1/ Communication entre le serveur VPN et les clients.
2/ Communication entre les clients VPN
3/ Communication avec les adresse extérieures au VPN.
Je peux donc maintenant, de mon client, me servir du VPN pour me connecter sur un autre client qui dispose d'un serveur SVN et de Redmine tout en continuant à pouvoir surfer sur le web. C'était l'urgence.

Cordialement,

Jean-Pierre