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
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.
C'est complètement vrai, c'est un métier le réseau ;) -- Eric Stern
Pascal Hambourg wrote:
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.
C'est complètement vrai, c'est un métier le réseau ;)
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.
C'est complètement vrai, c'est un métier le réseau ;) -- Eric Stern
Doug713705
Le 08-02-2017, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<o7g8af$28a9$) :
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on touche à des trucs un peu pointus je suis vite largué. Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ? Si oui, comment les petits paquets vont-ils trouver leur chemin si on ne leur indique pas au moins l'interface à utiliser ? /me est perdu dans le plat de spagghettis des règles iptables...
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas fonctionner sans. Il faudrait que je refasse des tests... -- 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 08-02-2017, Pascal Hambourg nous expliquait dans
fr.comp.reseaux.ip
(<o7g8af$28a9$1@saria.nerim.net>) :
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on
touche à des trucs un peu pointus je suis vite largué.
Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ?
Si oui, comment les petits paquets vont-ils trouver leur chemin si on ne
leur indique pas au moins l'interface à utiliser ?
/me est perdu dans le plat de spagghettis des règles iptables...
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas
fonctionner sans. Il faudrait que je refasse des tests...
--
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 08-02-2017, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<o7g8af$28a9$) :
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on touche à des trucs un peu pointus je suis vite largué. Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ? Si oui, comment les petits paquets vont-ils trouver leur chemin si on ne leur indique pas au moins l'interface à utiliser ? /me est perdu dans le plat de spagghettis des règles iptables...
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas fonctionner sans. Il faudrait que je refasse des tests... -- 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 18/02/2017 à 09:21, Doug713705 a écrit :
Le 08-02-2017, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on touche à des trucs un peu pointus je suis vite largué.
Pardon, "nexthop" désigne la cible du prochain saut, soit le routeur suivant, soit la destination finale.
Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ?
Non, juste de supprimer "via ${route_vpn_gateway}" qui ne sert à rien puisqu'il n'y a pas de résolution d'adresse (ARP) sur une interface tun. Du coup pas besoin de connaître la valeur dfe ${route_vpn_gateway}.
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas fonctionner sans. Il faudrait que je refasse des tests...
Je suppose que tu parles de règles de NAT (SNAT ou MASQUERADE), ce qui n'a rien à voir avec une redirection ? Si ça ne fonctionne pas sans NAT, c'est que les tables de routage sur certaines des machines de la chaîne sont incomplètes.
Le 18/02/2017 à 09:21, Doug713705 a écrit :
Le 08-02-2017, Pascal Hambourg nous expliquait dans
fr.comp.reseaux.ip
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on
touche à des trucs un peu pointus je suis vite largué.
Pardon, "nexthop" désigne la cible du prochain saut, soit le routeur
suivant, soit la destination finale.
Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ?
Non, juste de supprimer "via ${route_vpn_gateway}" qui ne sert à rien
puisqu'il n'y a pas de résolution d'adresse (ARP) sur une interface tun.
Du coup pas besoin de connaître la valeur dfe ${route_vpn_gateway}.
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas
fonctionner sans. Il faudrait que je refasse des tests...
Je suppose que tu parles de règles de NAT (SNAT ou MASQUERADE), ce qui
n'a rien à voir avec une redirection ?
Si ça ne fonctionne pas sans NAT, c'est que les tables de routage sur
certaines des machines de la chaîne sont incomplètes.
Le 08-02-2017, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip
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*.
Soyons clairs, j'ai des connaisances basiques en réseau mais dès qu'on touche à des trucs un peu pointus je suis vite largué.
Pardon, "nexthop" désigne la cible du prochain saut, soit le routeur suivant, soit la destination finale.
Dans le cas présent, que me proposes-tu ? De supprimer cette ligne ?
Non, juste de supprimer "via ${route_vpn_gateway}" qui ne sert à rien puisqu'il n'y a pas de résolution d'adresse (ARP) sur une interface tun. Du coup pas besoin de connaître la valeur dfe ${route_vpn_gateway}.
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 ?
Aucune idée, si j'ai ajouté ces règles c'est que ça ne devait pas fonctionner sans. Il faudrait que je refasse des tests...
Je suppose que tu parles de règles de NAT (SNAT ou MASQUERADE), ce qui n'a rien à voir avec une redirection ? Si ça ne fonctionne pas sans NAT, c'est que les tables de routage sur certaines des machines de la chaîne sont incomplètes.
