Connexion client à serveur openvpn > plus d'accès internet

Support Debian
#1

Bonjour,
J’ai un petit réseau local composé d’un Pc windows XP et d’un serveur Apache Debian sur lequel j’héberge un site internet.
Depuis le serveur Debian je cherche à me connecter en client sur un serveur vpn gratuit, et bien sur je veux conserver l’accès extérieur à mon site internet.

Actuellement il semblerait que je sois connecté au serveur vpn : le daemon openvpn est bien actif, le dev/tun0 aussi. Par contre je n’ai plus accès à internet.

Si je fais :
ping 10.8.1.205 >> négatif
ping 10.8.1.206 >> ok
ping 94.23.144.32 >> ok
ping google.fr >> négatif
Ne pouvant pas aller sur internet je ne peux pas vérifier mon ip vue de l’extérieur.

Mon fichier client.conf :
client
port 443
proto tcp
dev tun
remote vpn2.freedom-ip.com
resolv-retry infinite
ca /home/jrd/openvpn/ca.crt
tls-auth /home/jrd/openvpn/ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3
redirect-gateway
nobind
ns-cert-type server
auth-user-pass /home/jrd/openvpn/auth.cfg
auth-retry nointeract

root@debian:/home/jrd/openvpn# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.1.206 P-t-P:10.8.1.205 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:115 errors:0 dropped:0 overruns:0 frame:0
TX packets:209 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:10311 (10.0 KiB) TX bytes:17412 (17.0 KiB)

root@debian:/home/jrd/openvpn# ps -aef | grep -i openvpn
root 1777 1 3 17:55 ? 00:00:00 openvpn --cd /home/jrd/openvpn --daemon --log openvpn.log --config openvpn-jrd.conf

root@debian:/home/jrd/openvpn# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1
10.8.0.1 10.8.1.205 255.255.255.255 UGH 0 0 0 tun0
10.8.1.205 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
94.23.144.32 192.168.0.254 255.255.255.255 UGH 0 0 0 eth1
128.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Que faire pour retrouver mon accès internet et le fonctionnement de mon site. :013
Help !!!
Merci d’avance

#2

Il semble d’une part que tu n’es plus de DNS. D’autre part ta table de routage pose souci

Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1 10.8.0.1 10.8.1.205 255.255.255.255 UGH 0 0 0 tun0 10.8.1.205 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 94.23.144.32 192.168.0.254 255.255.255.255 UGH 0 0 0 eth1 128.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Tu as deux passerelles, fais un

route del default gw 192.168.0.254

ça ira mieux

#3

Tu as dû mettre dans la configuration du tunnel openvpn de créer une route par défaut sur le tunnel, et donc ta machine se retrouve avec deux routes par défaut : celle d’origine, via le routeur 192.168.0.254, et une via le tunnel openvpn (découpée en deux sous-routes 0/1 et 128/1, probablement pour avoir priorité sur toute autre route par défaut). Si c’est voulu, alors ta machine est dans la situation particulière d’avoir deux accès internet.

Actuellement, la situation par défaut est la suivante :

  • Les connexion sortantes prennent la route par défaut active, donc le tunnel.
  • Pour les connexions entrantes, les paquets retour prennent aussi la route par défaut active, même si les paquets aller arrivent par l’autre chemin. Souvent c’est un problème, qu’il faut résoudre en mettant en place du routage avancé. En résumé il faut envoyer les paquets via l’interface correspondant à leur adresse source.

ip route add default via 192.168.0.254 dev eth1 table 99 ip route add 192.168.0.0/24 dev eth1 table 99 ip rule add from 192.168.0.0/24 lookup 99
Si en plus tu veux que certaines connexions sortantes passent par le routeur, il faudra aussi modifier le configuration en fonction des caractérstiques des cconnexions (destination, protocole, port…)
Pour plus de détails voir le LARTC howto.

#4

Bonjour et merci de vous intéresser à mon sujet,
Je n’ai rien fait de particulier pour avoir 2 routes par defaut, voici mon fichier client.conf :

client
port 443
proto tcp
dev tun
remote vpn2.freedom-ip.com
resolv-retry infinite
ca /home/jrd/openvpn/ca.crt
tls-auth /home/jrd/openvpn/ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3
redirect-gateway
nobind
ns-cert-type server
auth-user-pass /home/jrd/openvpn/auth.cfg
auth-retry nointeract

Suite au conseil de fran.b j’ai supprimé la route par defaut vers mon routeur, mais le résultat est le même.
Ce que je cherche en fait c’est que lorsque mon vpn est actif tout passe par lui (y compris l’accès à mon site hébergé).
Et lorsqu’il n’est pas actif tout passe par mon routeur.
Merci d’avance; je vais essayer la proposition de PascalHambourg

#5

C’est l’option redirect-gateway qui crée une route par défaut via le tunnel.
L’autre route, c’est celle qui existe normalement pour sortir en l’absence du tunnel.

Quand tu parles de l’accès à ton site hébergé, il s’agit de l’accès entrant au serveur web sur la machine elle-même depuis l’extérieur ?

#6

Pascal: Une table comme

Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0 10.8.0.1 10.8.1.205 255.255.255.255 UGH 0 0 0 tun0 10.8.1.205 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 94.23.144.32 192.168.0.254 255.255.255.255 UGH 0 0 0 eth1 128.0.0.0 10.8.1.205 128.0.0.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Devrait faire ce qu’il veut non (tout le traffic en dehors de10.8.0.1, 10.8.1.205 et de 94.23.144.32 qui doit être le serveur VPN passe par le réseau VPN (y compris les DNS d’ailleurs ce qui à mon avis peut expliquer l’absence d’un retour de google.com, un ping 82.66.248.156 devrait fonctionner sauf si les pings ne sont pas relayés). Sinon, une telle table devrait empêcher l’accès à son serveur.

Je me trompe?

#7

Bonjour,
J’ai fait une partie du chemin grâce à vos conseils. Maintenant j’ai accès à internet, j’ai gardé l’intégralité de la table de routage crée par redirect-gateway et j’ai simplement ajouté dans le resolv.conf les DNS indiqués par redirect-gateway.

Il me reste donc à rétablir l’accès à mon site hébergé, il s’agit de l’accès entrant au serveur web sur la machine elle-même depuis l’extérieur.

#8

Si tu veux que le serveur soit accessible de l’extérieur via le VPN, alors il n’y a rien à ajouter côté routage. Il faut juste faire pointer le nom de domaine du site vers l’adresse IP de l’interface tun. Si au contraire le serveur doit être accessible depuis la connexion internet normale, voir ma première réponse.

#9

Bonjour,
Je viens de faire deux essais :

  1. Dans Dyndns j’ai fais pointer mon nom de domaine vers l’adresse IP externe du VPN >>>> négatif
  2. Toujours dans Dyndns j’ai fais pointer mon nom de domaine vers l’adresse IP de l’interface tun >>>> négatif
    :013
#10

Flûte, je n’avais pas fait attention que le tunnel utilisait des adresses IP privées (10.x.y.z) qui ne sont pas routées sur l’internet public. Donc à moins que tu puisses configurer une redirection de port sur le serveur de tunnel, tu ne peux pas rendre ton serveur accessible de l’extérieur via le tunnel.

#11

Je n’ai pas accès au paramétrage du serveur vpn, puisque c’est un serveur externe gratuit : freedom-ip.com

#12

Donc le tunnel ne peut servir que pour des connexions sortantes. Ton serveur ne peut être accessible que via l’adresse IP publique de la connexion internet normale, avec redirection de port par la box/routeur. Et pour qu’il reste accessible lorsque le tunnel est monté, il faut du routage avancé comme décrit plus haut.

#13

Il faut donc que j’ajoute une route avec la fonction “ip route …” ?

#14

Il faut les trois commandes (ip route et ip rule) mentionnées dans mon premier message.
La commande ip rule dit que si l’adresse source d’un paquet est 192.168.0.x, ce qui est le cas des paquets de réponse du serveur, alors il doit être routé selon la table de routage 99. Dans cette table les deux commandes ip route créent une route pour le réseau local et une route par défaut via la box/routeur.

#15

L’l’adresse source d’un paquet du serveur n’est pas plutôt en 10.X.X.X

#16

Les connexions entrantes arrivent de la box/routeur sur l’adresse 192.168.0.x, alors le serveur répond avec la même adresse.

#17

OK un grand merci je vais essayer ça

#18

Bonjour,
Reprise des activités ce matin : Après avoir ajouté

Code: ip route add default via 192.168.0.254 dev eth1 table 99 ip route add 192.168.0.0/24 dev eth1 table 99 ip rule add from 192.168.0.0/24 lookup 99

J’ai bien vérifié que les nouvelles routes étaient actives avec :

ip route list table all ip rule list

Négatif, en fait le routage s’arrête à la page d’accueil du serveur vpn lorsque j’essaie de joindre mon nom de domaine de l’extérieur.
A priori j’ai l’impression qu’il n’est pas possible pour un client vpn de router une requête externe vers mon “tuyau vpn”.
J’ai aussi essayé en remplaçant 192.168.0.0/24 par 192.168.0.100 (IP locale de mon serveur Apache)

#19

Je ne comprends pas ce que tu veux dire. Peux-tu expliquer ?

Quel client VPN ? Si j’ai bien compris, il était question que le site sur le serveur web reste accessible par son adresse publique normale lorsqu’il est client VPN.
Que fais-tu exactement ?

#20

Cela veut dire que lorsque je tape l’url de mon site internet je vois la page d’accueil de freedom-ip.fr

donc pour moi le routage s’arrête à la page d’accueil de freedom-ip.fr et ne continue pas jusqu’aux adresses 10.X.X.X

A priori, j’ai l’impression qu’il n’est pas possible pour un client vpn (qui n’a pas accès au routage du serveur vpn) de router une requête externe vers mon adresse en 10.X.X.X