Discussion :

[Procyon]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Merci de m'avoir lu jusqu'au bout.

Jean-Pierre

[patrice084]

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.

[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

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é.

[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.

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.

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 ?

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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.

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é
Je vous tiens au courant.

Cordialement,

Jean-Pierre

[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...

[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.

[patrice084]

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 ?

[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.

[patrice084]

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.

[Procyon]

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.

[Procyon]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 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