Discussion :

[sbaptistes]

Bonjour,

J'aurai besoin d'aide avec mon réseau à la maison...

J'ai un raspberry relié à ma Freebox.
J'ai configuré la redirection du port 22 (SSH) sur ma freebox, j'accède donc bien à mon raspberry en SSH depuis l'extérieur (depuis mon téléphone).
J'ai mis en place un client VPN sur mon raspberry, il se connecte maintenant en VPN à un serveur hébergé à l'étranger (Pays Bas il me semble).
Lorsque je suis connecté à mon réseau local sur mon téléphone (en Wifi à la Freebox), je peux accéder à mon raspberry sans problème via l'IP Privée (de même que mon raspberry communique parfaitement avec mon NAS et tout mon équipement de mon réseau privé). Par contre, lorsque j'essaie de me connecter depuis l'extérieur, ça passe plus.

Je ne suis pas expert réseaux, mais je suppose que lorsque mon raspberry se connecte au VPN, il créé une route par défaut pour tous les paquets (Sauf ceux de mon réseaux local), donc lorsque je fais une tentative de connexion en SSH, le raspberry reçoit bien la demande, mais renvoie les paquets non pas à mon expéditeur, mais à la route par défaut : Le VPN auquel le raspberry est connecté.

En supposant que c'est bien le cas, comment je pourrais forcer mon raspberry à renvoyer les paquets provenant d'un port particulier (22), vers la source de la demande à travers la freebox, et non pas via la route par défaut ?

Il me semble que c'est possible avec netfilter / iptable, mais je ne sais vraiment pas par où commencer dans la configuration...

Merci par avance pour votre aide !

[Invité]

Salut,

c'est le problème connu de "split tunneling".

C'est généralement un réglage à faire sur le serveur VPN, il ne doit pas envoyer de default route.

Steph

[sbaptistes]

Ok, donc si c'est côté VPN, c'est mort...

Voici le détail des routes et ips (privées) de mon serveur :

=> route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Ifacedefault 172.21.92.1 128.0.0.0 UG 0 0 0 tun0
default 192.168.1.254 0.0.0.0 UG 202 0 0 eth0
unknown.puregig 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 172.21.92.1 128.0.0.0 UG 0 0 0 tun0
172.21.92.0 * 255.255.254.0 U 0 0 0 tun0

=> ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:b5:0a:bd
inet adr:192.168.1.46 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:245666045 errors:0 dropped:27 overruns:0 frame:0
TX packets:204316860 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:4204988650 (3.9 GiB) TX bytes:2918406518 (2.7 GiB)


tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:172.21.92.2 P-t-P:172.21.92.2 Masque:255.255.254.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:25973630 errors:0 dropped:0 overruns:0 frame:0
TX packets:17946633 errors:0 dropped:82 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:3641859098 (3.3 GiB) TX bytes:4094959232 (3.8 GiB)

[Invité]

Salut,

ce sera plus parlant si tu peux fournir la table de routage avant et après avoir monté le VPN.

Steph

[sbaptistes]

Voici les routes sans le VPN

route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 192.168.1.254 0.0.0.0 UG 202 0 0 eth0
unknown.puregig 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 202 0 0 eth0

[Invité]

C'est ce que j'expliquais, le serveur VPN injecte une default route dès lors que tu montes le VPN.
Tu as alors 2 routes par défaut mais c'est celle de plus bas métric qui sera utilisée, donc celle qui est associée à ton interface tun0 (metric 0).

Un test à faire consisterait à modifier le metric de la default route associée à tun0 quand le VPN est monté. Il suffit de lui mettre un metric strictement supérieur à 202.

Sur ma machine Linux, ça donnerait un truc du genre :

Code :

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

1
2
sudo route del -net default gw 172.21.92.1 netmask 128.0.0.0
sudo route add -net default gw 172.21.92.1 netmask 128.0.0.0 dev tun0 metric 250

A toi d'adapter en fonction de ta distrib...

Steph

[sbaptistes]

Merci pour ton aide, je vais tester ça dans la journée.

Si ça fonctionne, est ce qu'après, je peux déterminer quelle route utiliser en fonction de l'ip qui se connecte ou en fonction du port ?

Car le VPN m'est utile pour certaines fonctionnalités, je souhaite le garder en parallèle de mon accès SSH depuis l'extérieur.

[breizhnos]

salut,
à priori non, ta session s'établie parceque tu renseignes un protocole (ssh) une adresse ip, et un port (22)
ca s'appelle un socket.
dans la table de routage tu n'as qu'un bout du socket (l'adresse ip) donc il n'y a que sur celle-ci que tu peux jouer,
Du coup, l'astuce donné par IP_Steph est l'une des seule, et encore, ca veut dire que ton 'logiciel' qui a besoin d'accéder au serveur VPN va d'abord interroger l'autre passerelle, qui va lui dire qu'elle ne connait pas l'itinéraire, avant d'interroger la bonne, donc tu perds en réactivité (suis pas complètement sûr, je n'ai jamais bossé avec multiple gateway, IP_Steph tu confirmes le fonctionnement ?)

Tu as peut-être plus simple, c'est d'avoir une seconde interface réseau sur ton RaspB, forcée en ip manuelle, avec la gateway qui te va bien..

Reste que je ne sais pas si le Daemon SSH peut écouter sur les deux en même temps ??

[Invité]

ca veut dire que ton 'logiciel' qui a besoin d'accéder au serveur VPN va d'abord interroger l'autre passerelle, qui va lui dire qu'elle ne connait pas l'itinéraire, avant d'interroger la bonne, donc tu perds en réactivité (suis pas complètement sûr, je n'ai jamais bossé avec multiple gateway, IP_Steph tu confirmes le fonctionnement ?)

A partir du moment qu'il n'y a pas d'entrée explicite pour une certaine destination IP, le paquet empruntera la default route.
S'il y a plusieurs default routes, c'est celle de metric le plus bas qui est utilisée.
S'il y a plusieurs default routes avec le même metric, les flux IP seront load-balancés entre ces multiples default routes.

Tu as peut-être plus simple, c'est d'avoir une seconde interface réseau sur ton RaspB, forcée en ip manuelle, avec la gateway qui te va bien..

Je crains que ça ne soit plus compliqué.
Ce genre de design impose de "binder" les services/applications sur les cartes réseau.
Et ça implique parfois d'utiliser 2 tables de routage.

Steph

[breizhnos]

A partir du moment qu'il n'y a pas d'entrée explicite pour une certaine destination IP, le paquet empruntera la default route.
S'il y a plusieurs default routes, c'est celle de metric le plus bas qui est utilisée.
S'il y a plusieurs default routes avec le même metric, les flux IP seront load-balancés entre ces multiples default routes.
Steph

oui, là où je m'interrogeais, c'est que si l'itinéraire n'est joignable que par la gateway qui a la metric élevée ... du coup le client interroge d'abord l'autre ... du coup Timeout ...? (je considère bien sûr que la première gateway ne connait pas l'itinéraire)


je dis une bêtise ?

[Invité]

oui, là où je m'interrogeais, c'est que si l'itinéraire n'est joignable que par la gateway qui a la metric élevée ... du coup le client interroge d'abord l'autre ... du coup Timeout ...? (je considère bien sûr que la première gateway ne connait pas l'itinéraire)


je dis une bêtise ?

You got it

Mon astuce s'appuie sur l'hypothèse que tout est joignable, quelle que soit l'interface de sortie utilisée...

Steph

[breizhnos]

ok, tu commençais à me faire douter