Tunnel complet ou route de point de terminaison : garder le serveur VPN joignable

Ajoutez une route par défaut via le tunnel, et les paquets du tunnel suivront celle-ci. La table contient alors une règle qui se contredit elle-même. La connexion chiffrée au serveur tente de passer à l'intérieur de la connexion qu'elle essaie d'établir.

Deux mécanismes empêchent cette boucle. L'un est visible dans la table de routage, l'autre vit à l'intérieur de l'application.

Le trafic interne et le trafic externe sont des décisions différentes

Un paquet d'application entre dans l'interface virtuelle et se fait encapsuler. Le résultat est un nouveau paquet adressé à l'adresse publique du serveur. Ce paquet a besoin d'une route sur le réseau physique, car rien de lui ne doit entrer dans le tunnel.

Les deux sont des décisions de routage, et seule la première appartient au tunnel. Lorsque le client installe une route par défaut qui couvre aussi le serveur, le paquet externe est capturé lui aussi.

Les symptômes sont immédiats et totaux. La poignée de main se termine puis plus rien ne circule, ou la connexion chute à l'instant où la route est installée. Dans les deux cas, le keepalive ne peut plus sortir.

Option un : une route d'hôte pour le point de terminaison

L'approche directe ajoute une route pour l'adresse du serveur via la passerelle d'origine. Elle tient en une ligne. Elle est visible par quiconque lit la table. Elle est aussi facile à expliquer dans un enregistrement de changement.

Sa faiblesse apparaît lorsque le chemin sous-jacent change. La route enregistrée nomme une passerelle et une interface de l'ancien réseau. Après un changement de Wi-Fi, cette passerelle peut ne pas exister, et la route reste derrière, paraît correcte et ne fait rien.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Un nom d'hôte rend cela plus difficile. Si le point de terminaison est un nom qui se résout en plusieurs adresses, l'exclusion doit couvrir l'adresse réellement utilisée. Une résolution ultérieure peut renvoyer quelque chose que la route n'a jamais couvert.

Option deux : protéger le socket

L'autre approche ne touche jamais à la table de routage. Le client marque ou protège le socket qui porte le tunnel, de sorte que le système d'exploitation envoie le trafic de ce socket hors du tunnel par politique. Android expose le mécanisme directement aux applications VPN. Les clients de bureau implémentent des équivalents avec des marques de pare-feu ou des appels de liaison au périphérique.

L'avantage est que l'exception suit la connexion plutôt qu'une passerelle enregistrée. Un changement de réseau réécrit le chemin sous-jacent, et le socket protégé se déplace avec lui parce qu'il n'a jamais été épinglé à une adresse. La table de routage reste propre.

Le coût est la visibilité. Rien dans la table de routage ne montre l'exception, donc un relecteur cherchant une route d'hôte ne trouve rien et peut conclure que la conception est dangereuse. La protection vit dans le code du client et dans les règles de politique que ce code installe.

Choisir entre les deux

Choisissez le mécanisme au niveau du socket lorsque le client le prend en charge, car il survit aux changements de réseau qui cassent une route épinglée. Choisissez la route d'hôte lorsque l'exception doit être visible pour d'autres outils, ou lorsque le client n'offre rien de mieux.

Aucun des deux mécanismes ne supprime la nécessité que l'adresse du serveur soit joignable tout court. Une passerelle privée a une adresse d'écoute publique, et c'est cette adresse qui doit rester hors du tunnel. Les réseaux internes derrière elle ne deviennent joignables qu'une fois le tunnel établi.

Quel que soit votre choix, gardez-le avec le composant qui possède le tunnel. Une route d'hôte sauvage ajoutée à la main fonctionne jusqu'au réseau suivant, puis elle devient la panne mystérieuse de demain.