Connexion de 2 VPN à la suite

Le
Doug713705
Bonjour à toutes, tous,

Mes différentes machines sont systématiquement connectées à mon propre
VPN (vpn1: 10.10.10.0/24) mais également ponctuellement à un autre VPN
(vpn2: 10.0.0.0/24).

Je gère intégralement le vpn1, tant au niveau du système qui l'héberge
que sa configuration alors que je ne suis qu'un client lambda du vpn2.

Tout fonctionne très bien mais lorsque je me connecte au deuxième vpn
(vpn2) il faut que je modifie manuellement la table de routage pour que
le trafic destiné au vpn2 ne s'en aille pas vers le vpn1 qui est la
route par défaut (vpn1 fait de l'ipv4 forwarding et l'intégralité de mon
trafic vers et depuis Internet passe par lui).

En clair, avant connexion au vpn2, la table de routage typique d'une de
mes machines ressemble à ça:

default via 10.10.10.5 dev tun0 proto static metric 50
default via 192.168.20.1 dev wlan0 proto static metric 600
10.10.10.5 dev tun0 proto kernel scope link src 10.10.10.6 metric 50
127.0.0.0/8 dev lo scope link
163.172.215.184 via 192.168.20.1 dev wlan0 proto static metric 600
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric 302
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric 600

et une fois connecté à vpn2 elle ressemble à ça:

default via 10.10.10.5 dev tun0 proto static metric 50
default via 10.0.8.5 dev tun1 proto static metric 51
default via 192.168.20.1 dev wlan0 proto static metric 600
10.0.0.0/24 via 10.0.8.5 dev tun1 proto static metric 50
10.0.8.0/24 via 10.0.8.5 dev tun1 proto static metric 50
10.0.8.5 dev tun1 proto kernel scope link src 10.0.8.6 metric 50
10.10.10.5 dev tun0 proto kernel scope link src 10.10.10.6 metric 50
91.224.149.192 via 192.168.20.1 dev wlan0 proto static metric 600
127.0.0.0/8 dev lo scope link
163.172.215.184 via 192.168.20.1 dev wlan0 proto static metric 600
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric 302
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric 600

Pour corriger ce défaut de routage, je supprime donc la route qui ne
me plait pas et ajoute une route plus restrictive:

ip route del 10.0.0.0/24 via 10.0.8.5 dev tun1 proto static metric 50
ip route add 10.20.0.0/19 via 10.0.8.5 dev tun1 proto static metric 10

C'est fastidieux, d'autant plus que c'est difficlement scriptable
puique la passerelle peut avoir une adresse ip différente (10.0.8.0/24).

Du coup m'est venue l'idée saugrenue (ou pas) de connecter la machine
qui me sert de serveur pour vpn1 au vpn2 pour arriver au schema suivant:

Ma machine -- vpn1 - 10.10.10.0/24 | mon serveur | 10.0.8.0/24 - vpn2 - Intranet (10.20.0.0/19)
|
|
`- Internet

Ainsi tout mon trafic passerait par mon serveur, une partie étant redirigé vers
Internet, l'autre vers le réseau /intranet/.

- Qu'en pensez-vous ?
- Voyez-vous d'autres solutions plus simples/n'impliquant pas une
connexion de mon serveur sur vpn2 ?
- Idéalement existe t-il une solution permettant la reconnexion
automatique du client vpn2 en cas de coupure (NetworkManager) ?
- Quelles complications réseau sont à envisager dans un tel modèle ?

Merci pour vos conseils.

--
En ce temps-là, nos fleurs vendaient leur viande aux chiens
Et nous habitions tous de sordides tripots
Avec des aiguillages pour nos petits matins,
Quand le beau macadam nous traitait de salauds.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Doug713705
Le #26413469
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(
Bonjour à toutes, tous,
Mes différentes machines sont systématiquement connectées à mon propre
VPN (vpn1: 10.10.10.0/24) mais également ponctuellement à un autre VPN
(vpn2: 10.0.0.0/24).

[SNIP le blah blah]
Ma machine ----- vpn1 ---- 10.10.10.0/24 | mon serveur | 10.0.8.0/24 ---- vpn2 ---- Intranet (10.20.0.0/19)
|
|
`---- Internet

J'ai finalement réussi en refusant les routes qui étaient poussées par
le serveur /vpn2/ et en récupérant les infos réseau liées au VPN par
l'intermédiaire des variables d'environnement que génère l'option
route-up.
Typiquement les options à utiliser dans le fichier de conf du client sont :
- route-noexec
- script-security 2
- Route-up <script qui ajoutera les routes qui vont bien>
Le script qui ajoutera les routes une fois le vpn monté ressemble à ça:
#!/bin/bash
LOG=/var/log/openvpn/openvpn.log
echo "Local ip: ${ifconfig_local}">> $LOG
echo "Remote ip:${ifconfig_remote}" >> $LOG
echo "Route VPN gw: ${route_vpn_gateway}" >> $LOG
echo "Adding route to ${ifconfig_remote} via tun1 src ${ifconfig_local}" >> $LOG
ip route add ${ifconfig_remote} dev tun1 proto kernel scope link src ${ifconfig_local}
echo "Adding route to 10.20.0.0/19 via tun1 src ${route_vpn_gateway}" >> $LOG
ip route add 10.20.0.0/19 via ${route_vpn_gateway} dev tun1 proto static metric 50
Ne reste plus qu'ensuite à ajouter les règles iptables qui vont bien
pour que le trafic venant de /vpn1/ *et* à destination de 10.20.0.0/19 soit
redirigé vers /vpn2/.
Et voilà :)
--
Demain, nous reviendrons avec des revolvers au bout De nos yeux morts...
-- H.F. Thiéfaine, Autorisation de délirer
Doug713705
Le #26413468
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(
Bonjour à toutes, tous,
Mes différentes machines sont systématiquement connectées à mon propre
VPN (vpn1: 10.10.10.0/24) mais également ponctuellement à un autre VPN
(vpn2: 10.0.0.0/24).

[SNIP le blah blah]
Ma machine ----- vpn1 ---- 10.10.10.0/24 | mon serveur | 10.0.8.0/24 ---- vpn2 ---- Intranet (10.20.0.0/19)
|
|
`---- Internet

J'ai finalement réussi en refusant les routes qui étaient poussées par
le serveur /vpn2/ et en récupérant les infos réseau liées au VPN par
l'intermédiaire des variables d'environnement que génèrent l'option
route-up.
Typiquement les options à utiliser dans le fichier de conf du client sont :
- route-noexec
- script-security 2
- Route-up <script qui ajoutera les routes qui vont bien>
Le script qui ajoutera les routes une fois le vpn monté ressemble à ça:
#!/bin/bash
LOG=/var/log/openvpn/openvpn.log
echo "Local ip: ${ifconfig_local}">> $LOG
echo "Remote ip:${ifconfig_remote}" >> $LOG
echo "Route VPN gw: ${route_vpn_gateway}" >> $LOG
echo "Adding route to ${ifconfig_remote} via tun1 src ${ifconfig_local}" >> $LOG
ip route add ${ifconfig_remote} dev tun1 proto kernel scope link src ${ifconfig_local}
echo "Adding route to 10.20.0.0/19 via tun1 src ${route_vpn_gateway}" >> $LOG
ip route add 10.20.0.0/19 via ${route_vpn_gateway} dev tun1 proto static metric 50
Ne reste plus qu'ensuite à ajouter les règles iptables qui vont bien
pour que le trafic venant de /vpn1/ *et* à destination de 10.20.0.0/19 soit
redirigé vers /vpn2/.
Et voilà :)
--
Demain, nous reviendrons avec des revolvers au bout De nos yeux morts...
-- H.F. Thiéfaine, Autorisation de délirer
Doug713705
Le #26413467
(double supersedes !)
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(
Bonjour à toutes, tous,
Mes différentes machines sont systématiquement connectées à mon propre
VPN (vpn1: 10.10.10.0/24) mais également ponctuellement à un autre VPN
(vpn2: 10.0.0.0/24).

[SNIP le blah blah]
Ma machine ----- vpn1 ---- 10.10.10.0/24 | mon serveur | 10.0.8.0/24 ---- vpn2 ---- Intranet (10.20.0.0/19)
|
|
`---- Internet

J'ai finalement réussi en refusant les routes qui étaient poussées par
le serveur /vpn2/ et en récupérant les infos réseau liées au VPN par
l'intermédiaire des variables d'environnement générées par l'option
route-up.
Typiquement les options à utiliser dans le fichier de conf du client sont :
- route-noexec
- script-security 2
- Route-up <script qui ajoutera les routes qui vont bien>
Le script qui ajoutera les routes une fois le vpn monté ressemble à ça:
#!/bin/bash
LOG=/var/log/openvpn/openvpn.log
echo "Local ip: ${ifconfig_local}">> $LOG
echo "Remote ip:${ifconfig_remote}" >> $LOG
echo "Route VPN gw: ${route_vpn_gateway}" >> $LOG
echo "Adding route to ${ifconfig_remote} via tun1 src ${ifconfig_local}" >> $LOG
ip route add ${ifconfig_remote} dev tun1 proto kernel scope link src ${ifconfig_local}
echo "Adding route to 10.20.0.0/19 via tun1 src ${route_vpn_gateway}" >> $LOG
ip route add 10.20.0.0/19 via ${route_vpn_gateway} dev tun1 proto static metric 50
Ne reste plus qu'ensuite à ajouter les règles iptables qui vont bien
pour que le trafic venant de /vpn1/ *et* à destination de 10.20.0.0/19 soit
redirigé vers /vpn2/.
Et voilà :)
--
Demain, nous reviendrons avec des revolvers au bout De nos yeux morts...
-- H.F. Thiéfaine, Autorisation de délirer
ghous Hors ligne
Le #26425455
Le mercredi 19 Octobre 2016 à 10:04 par Doug713705 :
Bonjour à toutes, tous,

Mes différentes machines sont systématiquement connectées
à mon propre
VPN (vpn1: 10.10.10.0/24) mais également ponctuellement à un
autre VPN
(vpn2: 10.0.0.0/24).

Je gère intégralement le vpn1, tant au niveau du système
qui l'héberge
que sa configuration alors que je ne suis qu'un client lambda du vpn2.

Tout fonctionne très bien mais lorsque je me connecte au deuxième
vpn
(vpn2) il faut que je modifie manuellement la table de routage pour que
le trafic destiné au vpn2 ne s'en aille pas vers le vpn1 qui est la
route par défaut (vpn1 fait de l'ipv4 forwarding et
l'intégralité de mon
trafic vers et depuis Internet passe par lui).

En clair, avant connexion au vpn2, la table de routage typique d'une de
mes machines ressemble à ça:

default via 10.10.10.5 dev tun0 proto static metric 50
default via 192.168.20.1 dev wlan0 proto static metric 600
10.10.10.5 dev tun0 proto kernel scope link src 10.10.10.6 metric 50
127.0.0.0/8 dev lo scope link
163.172.215.184 via 192.168.20.1 dev wlan0 proto static metric 600
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric
302
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric
600

et une fois connecté à vpn2 elle ressemble à ça:

default via 10.10.10.5 dev tun0 proto static metric 50
default via 10.0.8.5 dev tun1 proto static metric 51
default via 192.168.20.1 dev wlan0 proto static metric 600
10.0.0.0/24 via 10.0.8.5 dev tun1 proto static metric 50
10.0.8.0/24 via 10.0.8.5 dev tun1 proto static metric 50
10.0.8.5 dev tun1 proto kernel scope link src 10.0.8.6 metric 50
10.10.10.5 dev tun0 proto kernel scope link src 10.10.10.6 metric 50
91.224.149.192 via 192.168.20.1 dev wlan0 proto static metric 600
127.0.0.0/8 dev lo scope link
163.172.215.184 via 192.168.20.1 dev wlan0 proto static metric 600
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric
302
192.168.20.0/24 dev wlan0 proto kernel scope link src 192.168.20.17 metric
600

Pour corriger ce défaut de routage, je supprime donc la route qui ne
me plait pas et ajoute une route plus restrictive:

ip route del 10.0.0.0/24 via 10.0.8.5 dev tun1 proto static metric 50
ip route add 10.20.0.0/19 via 10.0.8.5 dev tun1 proto static metric 10

C'est fastidieux, d'autant plus que c'est difficlement scriptable
puique la passerelle peut avoir une adresse ip différente
(10.0.8.0/24).

Du coup m'est venue l'idée saugrenue (ou pas) de connecter la machine
qui me sert de serveur pour vpn1 au vpn2 pour arriver au schema suivant:

Ma machine ----- vpn1 ---- 10.10.10.0/24 | mon serveur | 10.0.8.0/24 ---- vpn2
---- Intranet (10.20.0.0/19)
|
|
`---- Internet

Ainsi tout mon trafic passerait par mon serveur, une partie étant
redirigé vers
Internet, l'autre vers le réseau /intranet/.

- Qu'en pensez-vous ?
- Voyez-vous d'autres solutions plus simples/n'impliquant pas une
connexion de mon serveur sur vpn2 ?
- Idéalement existe t-il une solution permettant la reconnexion
automatique du client vpn2 en cas de coupure (NetworkManager) ?
- Quelles complications réseau sont à envisager dans un tel
modèle ?

Merci pour vos conseils.

--
En ce temps-là, nos fleurs vendaient leur viande aux chiens
Et nous habitions tous de sordides tripots
Avec des aiguillages pour nos petits matins,
Quand le beau macadam nous traitait de salauds.
-- H.F. Thiéfaine, Exil Sur planète
fantôme


Suivez la meme discussion dans une autre forum

http://www.tomshardware.fr/forum/id-1335399/plusieurs-connexions-vpn-temps.html
Doug713705
Le #26425485
Le 07-02-2017, ghous nous expliquait dans
fr.comp.reseaux.ip
(
Suivez la meme discussion dans une autre forum
http://www.tomshardware.fr/forum/id-1335399/plusieurs-connexions-vpn-temps.html

La problématique que j'exposais n'est pas du tout la même.
Il ne s'agit pas d'avoir 2 connexions VPN simultanées, ça c'est facile,
mais d'avoir 2 connexions VPN l'une derrière l'autre et etre capable
d'atteindre serveur2 à partir de PC:
PC <--> VPN1 <--> Serveur1 <--> VPN2 <--> Serveur2
Le problème a été résolu en corrigeant les routes poussées par la
configuration du VPN2.
Cependant un problème demeure lorsque j'essaie de faire du SIP à partir
de PC alors que le serveur (Asterisk) est installé sur Serveur2.
Visiblement un problème de DNAT/SNAT mais tout ça me dépasse un peu.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Pascal Hambourg
Le #26425675
Le 21/10/2016 à 12:29, Doug713705 a écrit :
echo "Adding route to 10.20.0.0/19 via tun1 src ${route_vpn_gateway}" >> $LOG
ip route add 10.20.0.0/19 via ${route_vpn_gateway} dev tun1 proto static metric 50

Inutile de spécifier d'adresse de nexthop dans une route attachée à une
interface routée point à point comme tun*.
Ne reste plus qu'ensuite à ajouter les règles iptables qui vont bien
pour que le trafic venant de /vpn1/ *et* à destination de 10.20.0.0/19 soit
redirigé vers /vpn2/.

Pourquoi faudrait-il des règles iptables pour rediriger du trafic
destiné à des adresses qui sont déjà routées par tun1 ?
Eric Stern
Le #26426046
Doug713705 wrote:
Visiblement un problème de DNAT/SNAT mais tout ça me dépasse un peu.

NAT et SIP ne parait un peu incompatible (si j'ai bien tout suivi).

--
Eric Stern
Pascal Hambourg
Le #26426053
Le 12/02/2017 à 20:37, Eric Stern a écrit :
NAT et SIP ne parait un peu incompatible (si j'ai bien tout suivi).

NAT est un peu (voire beaucoup) incompatible avec tous les protocoles
internet.
Eric Stern
Le #26426256
Pascal Hambourg wrote:
Le 12/02/2017 à 20:37, Eric Stern a écrit :
NAT et SIP ne parait un peu incompatible (si j'ai bien tout suivi).

NAT est un peu (voire beaucoup) incompatible avec tous les protocoles
internet.

uniquement avec ceux qui gérent des infos dans le payload.
smtp,telnet,ssh marchent bien en nat.
--
Eric Stern
Pascal Hambourg
Le #26426264
Le 14/02/2017 à 21:02, Eric Stern a écrit :
Pascal Hambourg wrote:
Le 12/02/2017 à 20:37, Eric Stern a écrit :
NAT et SIP ne parait un peu incompatible (si j'ai bien tout suivi).

NAT est un peu (voire beaucoup) incompatible avec tous les protocoles
internet.

uniquement avec ceux qui gérent des infos dans le payload.

Non, pas uniquement : GRE, IPSec sans NAT-T, IPIP, 6in4, multicast,
anycast... en gros tout ce qui n'utilise pas de port ou une
communication de type point à point.
smtp,telnet,ssh marchent bien en nat.

Il n'y a pas que TCP parmi les protocoles IP.
Publicité
Poster une réponse
Anonyme