Discussion :

[lapartoch]

Bonjour,

J'ai aujourd'hui un problème de routage. En effet, j'ai un petit serveur possède deux interfaces.
- tun0 pour le tunnel VPN
- eth0 l'interface physique connectée à la box.

Ce serveur me donne accès à quelques pages html et à l'interface d'administration. Je souhaite y accéder depuis Internet. Or, lorsque le VPN fonctionne, impossible de voir les pages HTML depuis Internet (cela fonctionne depuis le réseau local).

Avec un coup de tcpdump, j'ai pu remarquer que les requêtes arrivaient bien sur eth0 MAIS repartaient sur tun0 car il est en default gw.

Comment stipuler à mon serveur que ce qui arrive par eth0 doit repartir par eth0 ?

Merci de vos lumières.

[Invité]

Salut,

il faudrait le résultat de 'route -n' avec et sans le VPN (en masquant toute adresse publique).

Steph

[lapartoch]

J'envoie ça ce soir.

Merci.

[lapartoch]

Voici la table de routage lorsque le VPN est branché

Code :

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

1
2
3
4
5
6
7
8
9
10
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.99.0.1       10.99.0.149     255.255.255.255 UGH   0      0        0 tun0
10.99.0.149     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
208.67.222.222  192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
178.73.212.230  192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         10.99.0.149     128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.99.0.149     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Et la voici VPN débranché

Code :

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

1
2
3
4
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

[Invité]

Code :

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

0.0.0.0         10.99.0.149     128.0.0.0       UG    0      0        0 tun0

Effectivement, c'est la default route utilisée pour le traffic retour.

Je suppose que ton serveur est ... client OpenVPN
Et que le serveur OpenVPN possède la directive

Code :

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

push "redirect-gateway def1"

dans son fichier de conf...

Est-ce que tu as du contrôle sur la config du serveur OpenVPN ?

Parce qu'une idée consisterait à ne pas faire de 'push' de default route sur ton serveur (ce qui signifie qu'il garderait sa default route 0/0 originelle pointant sur eth0, pas d'override en somme).
En revanche, tout dépend de l'utilisation qui est faite de ce VPN. S'il est utilisé pour accéder à 1, 2 voire 3 réseaux IP, dans ce cas le serveur OpenVPN peut également faire un 'push' de ces réseaux particuliers pour les injecter dans la table de routage de ton serveur, enfin de ton client OpenVPN

Il y a peut-être aussi une solution à base de bricolage d'iptables... Mais déjà, regardes ce qui est faisable côté serveur, nous verrons alors.

Steph

[lapartoch]

Merci Steph pour ta réponse.

Je n'ai pas la main sur le serveur VPN, qui appartient à un opérateur privée.

Mon serveur est effectivement un client VPN. Par défaut lorsqu'il travaille, il doit utiliser tun0. Par contre je veux pouvoir accéder à son contenu via le WAN et l'ip de la box. C'est a ce moment là que ca coince car ma requete arrive bien au serveur, mais repart par la gw par defaut : tun0.

[Invité]

Je pense avoir trouvé une piste pour résoudre ton problème (ma foi très intéressant puisqu'on n'a aucun contrôle sur le serveur).

1) Il est possible de monter le VPN en refusant les deux routes

Code :

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

1
2
0.0.0.0         10.99.0.149     128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.99.0.149     128.0.0.0       UG    0      0        0 tun0

qui proviennent du push du serveur.

Il suffit pour ça de lancer le client VPN avec l'option --route-nopull

2) Ensuite, il faudra ajouter des routes statiques dans la table de routage qui permettront de couvrir tout l'espace d'adressage privé, à savoir les CIDR 10/8, 172.16/12 et 192.168/16. Il faudra faire pointer toutes ces routes vers le VPN. Sur une plateforme Ubuntu, ça donnerait quelque chose comme ça :

Code :

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

route add -net 10.0.0.0/8 gw 10.99.0.149

Code :

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

route add -net 172.16.0.0/12 gw 10.99.0.149

Code :

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

route add -net 192.168.0.0/16 gw 10.99.0.149

Remarques importantes :

* Question cruciale : lorsque le VPN est monté, est-ce que ton serveur est sensé accéder à des hosts sur Internet (au travers du VPN bien sûr) ?
Si c'est non, ça devrait être OK
Si c'est oui, et ben, il va falloir réfléchir à un autre plan d'actions

* A noter que la route statique 192.168.0.0/16 pointant vers le VPN n'aura pas d'effet de bord si tu veux te connecter à ton serveur depuis ton réseau local 192.168.1.0/24 puisque ce dernier est directement connecté au serveur.

* D'autre part, comme tu as écrit que tu pouvais te connecter en local lorsque le VPN était monté, je suppose que 192.168.1.0/24 est le seul réseau à partir duquel tu fais ça en local. S'il y en avait un autre, par exemple 192.168.2.0/24, il suffirait d'entrer une nouvelle route statique et là encore, il n'y aurait pas d'effet de bord avec la route 192.168.0.0/16 puisque l'entrée 192.168.2.0/24 est plus spécifique ("longest match").

Voilà, tiens-nous au courant

Steph

[lapartoch]

* Question cruciale : lorsque le VPN est monté, est-ce que ton serveur est sensé accéder à des hosts sur Internet (au travers du VPN bien sûr) ?
Si c'est non, ça devrait être OK
Si c'est oui, et ben, il va falloir réfléchir à un autre plan d'actions

Steph

Bonjour Steph,

le serveur doit pouvoir accéder à des hosts sur Internet à travers le VPN. Ce que j'aimerais lui dire c'est
=> ce qui arrive par eth0, ca repart par eth0
=> le reste traffic par tun0.

C'est complexe !!! en tout cas merci de t'intéresser à ce problème.

[Invité]

le serveur doit pouvoir accéder à des hosts sur Internet à travers le VPN

Ce que j'aimerais lui dire c'est
=> ce qui arrive par eth0, ca repart par eth0
=> le reste traffic par tun0.

Oui, nous sommes d'accord

Bien, il va falloir être créatif sur ce coup là

1) Le cas le plus simple, c'est si tu désires accéder à ton serveur depuis des "endroits privilégiés". Exemple : tu voudrais y accéder depuis ton réseau perso chez toi derrière une FreeBox.

Dans ce cas, ce sera possible mais à condition de créer une entrée spécifique dans la table de routage de ton serveur. Par exemple, supposes que ton FAI t'ait fourni l'adresse publique x.x.x.x qui sert à NATter ton réseau local perso, il faudra créer la host route suivante :

Code :

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

route add -host x.x.x.x gw 192.168.1.1

2) Si tu veux accéder à ton serveur depuis n'importe quelle adresse routée sur l'Internet, alors oui, il va falloir bricoler avec les iptables... A priori, ça doit être faisable en marquant les paquets qui arrivent sur eth0 et en créant une 2ème table de routage avec une default route pointant vers 192.168.1.1. Je n'ai pas trop d'expérience là-dessus, c'est donc l'occasion de regarder ça d'un peu plus près...

Steph

[Invité]

J'ai simulé ton environnement avec des interfaces tap dans un petit lab GNS3. J'ai utilisé les mêmes espaces d'adressage pour le tunnel OpenVPN, le NAT ainsi que ton réseau local (j'ai supposé que l'adresse IP locale était 192.168.1.10/24) :



Voici la table de routage de LapSteph :

Code :

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

1
2
3
4
5
root@steph-ThinkPad-T400:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 tap0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

J'ai également simulé un accès distant qui vient d'Internet puis qui est translaté par la FreeBox. J'ai "joué le jeu" dans le sens où LapSteph ne connait pas l'adresse IP du routeur "Accès distant", la default route pointant vers la FreeBox suffit. En fait, dans ce lab virtuel, j'ai caché un autre routeur derrière le nuage "Internet".

J'arrive donc bien à lancer des pings depuis "Accès distant" sur LapSteph :

Code :

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

1
2
3
4
5
6
Acces_Distant>ping 192.168.1.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/28 ms

Oui, évidemment, depuis un site distant au travers d'Internet, ça n'a pas de sens d'attaquer une adresse RFC1918. Mais l'important ici, c'était de modéliser ce qui se passe. J'ai même simulé la translation sur la FreeBox puisque j'ai maintenant une entreé dynamique NAT, le grand luxe en somme :

Code :

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

1
2
3
4
5
FreeBox#sh ip nat translations 
Pro Inside global         Inside local          Outside local         Outside global
icmp 208.67.222.222:6     192.168.1.10:6        1.1.1.2:6             1.1.1.2:6
tcp 208.67.222.222:37866  192.168.1.10:37866    1.1.1.2:23            1.1.1.2:23
tcp 208.67.222.222:38560  192.168.1.10:38560    1.1.1.1:23            1.1.1.1:23

Maintenant je configure l'interface tap1 supplémentaire, j'ajoute les routes statique puis j'arrive à la table de routage suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
root@steph-ThinkPad-T400:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.99.0.149     128.0.0.0       UG    0      0        0 tap1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 tap0
10.99.0.0       0.0.0.0         255.255.255.0   U     0      0        0 tap1
10.99.0.1       10.99.0.149     255.255.255.255 UGH   0      0        0 tap1
128.0.0.0       10.99.0.149     128.0.0.0       UG    0      0        0 tap1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
208.67.222.222  192.168.1.1     255.255.255.255 UGH   0      0        0 tap0

J'ai bien les 2 routes problématiques 0/1 et 128.0.0.0/1 qui m'empêchent maintenant de joindre LapSteph depuis "Accès distant" :

Code :

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

1
2
3
4
5
6
Acces_Distant>ping 192.168.1.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Je suis dans le même cas de figure que toi. Un coup de Wireshark sur l'interface tap0 de LapSteph montre que je reçois bien des ICMP Echo request...

Par contre, impossible de rediriger les flux depuis sur tap0 (eth0 pour ton serveur) vers 192.168.1.1 au lieu du VPN...

J'ai essayé pas mal de choses à base d'iptables, en marquant le flux entrant sur tap0 notamment mais rien à faire Je pense que le fait d'utiliser des interfaces tap au lieu d'une eth0+tun impacte ce que je suis en train de faire. Peut-être que ce qui ne fonctionne pas sur ma petite maquette fonctionnerait sur ton serveur mais j'aime pas jouer à l'apprenti-sorcier

En attendant, j'ai cette question : quand tu essaies d'accéder à ton serveur depuis l'Internet, tu l'attaques sur l'adresse 208.67.222.222 ?

Steph

[lapartoch]

Salut Steph, je viens de prendre connaissance de tes messages. Long weekend oblige. Je regarde ça en détail tout à l'heure !

[lapartoch]

Bonjour, lorsque j'attaque le serveur depuis internet, je le fais depuis l'IP de la box 208.67.222.222.

J'ai trouvé ce lien : http://www.ibiblio.org/pub/linux/doc...MULTIPLE-LINKS et dans la section Routage avec plusieurs accès Internet/fournisseurs d'accès. Par contre je n'arrive pas vraiment a le mettre en oeuvre !

Qu'en penses-tu ?

[Invité]

Oui, je connais ce document.

Pour résoudre ton problème, il faudrait :
- marquer les paquets entrant dans la chaîne INPUT (puisque c'est le client qu'on veut atteindre, ça n'est pas de l'IP Forwarding) de la table mangle,
- définir une 2ème table de routage spécifique au marquage,
- installer des règles interdisant ce traffic de repartir vers l'interface TUN.

Pour le dernier critère, j'ai trouvé une option très intéressante : 'ip route add throw x.x.x.x/xx' qui permet de retirer des routes de la main routing table. Donc il suffirait de retirer les routes 0.0.0.0/1 et 128.0.0.0/1 pour que les paquets partant de la chaîne OUTPUT utilisent la default gateway 192.168.1.1.

En attendant, la seule alternative que je vois c'est de configurer une route statique dans le cas où tu connais à l'avance les adresses IP publiques que tu utiliserais pour te connecter sur le client OpenVPN. Si tu prévois de te connecter lorsque tu es chez toi par exemple, avec l'adresse publique x.x.x.x tu configures la route statique suivante :

Code :

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

route add -host x.x.x.x gw 192.168.1.1

Je vais refaire des tests en essayant de configurer des options de logging ce qui me permettrait de suivre les paquets pas à pas lorsqu'ils arrivent sur ma machine Unix. Je loupe peut-être quelque chose. Je donnerai plus de détails sans mon prochain message...

Voilà...

Je te tiens informé

Steph

[lapartoch]

Bonjour, lorsque j'attaque le serveur depuis internet, je le fais depuis l'IP de la box 208.67.222.222.

J'ai trouvé ce lien : http://www.ibiblio.org/pub/linux/doc...MULTIPLE-LINKS et dans la section Routage avec plusieurs accès Internet/fournisseurs d'accès. Par contre je n'arrive pas vraiment a le mettre en oeuvre !

Qu'en penses-tu ?

Petite erreur le 208.67.222.222 est l'adresse des serveurs DNS de opendns ...

[Invité]

Petite erreur le 208.67.222.222 est l'adresse des serveurs DNS de opendns ...

OK... Ca ne change pas grand chose. Je suppose que sans le VPN tu accèdes à ton serveur Unix par ssh sur l'adresse publique de la FreeBox (qui fait ensuite du port forwarding sur ton serveur).

Steph