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
Le 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(<nu79ef$q1c$1@golgoth99.redatomik.org>) :
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
Le 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(<nu79ef$q1c$1@golgoth99.redatomik.org>) :
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
Le 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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
(double supersedes !) Le 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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
(double supersedes !)
Le 19-10-2016, Doug713705 nous expliquait dans
fr.comp.reseaux.ip
(<nu79ef$q1c$1@golgoth99.redatomik.org>) :
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
(double supersedes !) Le 19-10-2016, Doug713705 nous expliquait dans fr.comp.reseaux.ip (<nu79ef$q1c$) :
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
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
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
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
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
Le 07-02-2017, ghous nous expliquait dans
fr.comp.reseaux.ip
(<Mamdnea5qtGk-ATFnZ2dnUU7983NnZ2d@giganews.com>) :
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
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 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 ?
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 ?
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
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
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).
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 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.
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.
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.
