Client OpenVPN et inaccessibilité des services

Support Debian
#1

Bonjour à tous,

Je viens vers vous pour vous demander de l’aide. J’ai monté, il y a quelques jours un NAS ; “Tout” fonctionne bien, que ce soit en LAN ou au niveau des services WAN. Toutefois, je rencontre un problème avec l’accessibilité aux services installés, notamment Subsonic, pour l’exemple, dès lors que le client OpenVPN est actif sur mon NAS.

En effet, sur ce dernier, j’ai un client OpenVPN qui se connecte à un serveur distant. Jusque-là, il n’y a aucun problème, la connexion se fait correctement. C’est dès lors que je veux accéder à un service tel que Webmin, Subsonic et autres, que ça pose problème. Les services sont inaccessibles dès lors que le client OpenVPN tourne. J’ai conscience que c’est un problème de routage mais rien n’y fait, j’ai tout essayé mais je n’y parviens pas… Est-ce réalisable ?

Ci-dessous la table de routage :

Destination Passerelle Genmask Indic Metric Ref Use Iface SERVEURVPN livebox.home 255.255.255.255 UGH 0 0 0 eth0 10.8.0.1 10.8.0.9 255.255.255.255 UGH 0 0 0 tun0 10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 10.9.8.0 10.8.0.9 255.255.252.0 UG 0 0 0 tun0 default 10.8.0.9 128.0.0.0 UG 0 0 0 tun0 128.0.0.0 10.8.0.9 128.0.0.0 UG 0 0 0 tun0 default livebox.home 0.0.0.0 UG 0 0 0 eth0

Il suffit que j’arrête le client OpenVPN pour que tout refonctionne. Une idée ?

#2

regarde ton fichier .conf d’openvpn, tu passe par un client-vpner ?

#3

J’ai pas très bien compris ta question. J’utilise le client/serveur classique, ayant utilisé cette entrée du wiki.debian. Ma configuration est celle du wiki, si ça peut aider.

Serait-ce lié au mode “Bridged” ou “Routed” ? Il faudrait que mon serveur soit en “Bridged” et non “Routed” ?

#4

okay , as tu un firewall qui bloquerais le port ?

#5

A quoi ce VPN sert-il ?

Inaccessibles depuis quelle(s) adresse(s) ? Le réseau local, internet ? Via quelle adresse ? L’adresse privée du NAS, l’adresse publique de la box, l’adresse publique du VPN ?

La différence que j’observe, c’est que la route par défaut (utilisée pour communiquer avec l’extérieur) change : elle passe par le VPN et non plus la box.

#6

Le seul firewall qui bloquerait serait celui de la box. Toutefois, la liaison entre le client et le serveur se fait sans embûche. En ce qui concerne l’iptables du NAS, elle accepte tout a priori. D’ailleurs, sans le client OpenVPN d’activé, j’accède bien à mon serveur Subsonic ou encore à Webmin à partir du web, sans soucis. C’est vraiment dès que le client est actif que je n’accède plus à rien.

Ce VPN sert à se connecter à un serveur de fichier distant, entre autre.

Le serveur est accessible en local en 192.168.x.x. Si je tente de passer par l’adresse publique de la box, ça ne passe plus.

#7

Donc la route par défaut via 10.8.0.9 sur tun1 créée par openvpn n’a rien à faire là. Supprime l’option responsable de cette création dans la configuration du client.

Ce qui s’explique parfaitement par une route par défaut incorrecte.

#8

client dev tun proto udp remote xx.xx.xx.xx 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key comp-lzo

Ma configuration client est celle-ci. Pourrais-tu m’éclairer plus précisément Pascal s’il te plaît ?

#9

L’option “client” implique l’option “pull”, donc la route a dû être “poussée” par le serveur. Il faut voir dans la configuration de ce dernier.

#10

[quote]Il faut voir dans la configuration de ce dernier.

[/quote]

c’est ce que je voulais, l’y mener…

#11

Donc ceci :

[code]# On définit le serveur VPN comme passerelle par défaut pour les clients.
push "redirect-gateway def1"
push “route 10.9.8.0 255.255.252.0”

On définit le serveur VPN comme DNS par défaut

push “dhcp-option DNS 10.8.0.1”[/code]

Je ne définis plus le serveur VPN comme passerelle par défaut dans ce cas, est-ce juste ? et je recommente les lignes comme suit :

[code]# On définit le serveur VPN comme passerelle par défaut pour les clients.
#push “redirect-gateway def1”
#push “route 10.9.8.0 255.255.252.0”

On définit le serveur VPN comme DNS par défaut

#push “dhcp-option DNS 10.8.0.1”[/code]

On obtient cette nouvelle table de routage :

10.8.0.1 10.8.0.9 255.255.255.255 UGH 0 0 0 tun0 10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 default livebox.home 0.0.0.0 UG 0 0 0 eth0
Et ça fonctionne donc ! Merci à vous deux.

C’est ma première semaine sur Linux, je débute. J’ai écumé déjà plein de documentations en quelques jours, c’est éminemment riche et instructif. Je vois bien ici, qu’il fallait garder ma passerelle comme route par défaut, c’est logique. Cela dit, j’ai un peu de mal à me représenter ces interfaces et leur fonctionnement. Schématiquement, ça passe. Plus en détails, je me noue le cerveau…

Je vous remercie pour votre temps et pour dispenser de votre savoir.

#12

A noter que seule la première option “push” concernait la route par défaut. La seconde ajoutait une route pour le sous-réseau du VPN, pouvant servir à communiquer avec d’autres clients connectés au même serveur. La dernière parle d’elle-même.

#13

D’accord, merci pour cette précision Pascal.

#14

Salut,
j’ai édité le titre pour enlever [Résolu] au profit de la coche verte.