Pourquoi une route de tunnel complet coupe le serveur qui la transporte

Activez un tunnel complet et chaque destination appartient désormais à l’interface VPN, y compris la machine qui le termine. Les paquets extérieurs qui portent le tunnel sont adressés à cette machine, donc la route finit par consommer le transport dont elle dépend. Une route spécifique supplémentaire règle cela, et la raison mérite d’être comprise. Sans cette raison, la prochaine reconstruction réintroduit le défaut.

Une route qui mange son propre transport

L’encapsulation enveloppe chaque paquet dans un second en-tête. L’extérieur est adressé de l’adresse physique locale vers l’adresse publique du serveur, et il doit traverser la liaison physique avant qu’un tunnel puisse exister.

Laissez maintenant la recherche de cette adresse publique choisir le tunnel. Pour envoyer le paquet, la machine doit l’encapsuler, ce qui exige une route vers la même adresse, qui renvoie le tunnel. Les clients gèrent cela de deux façons. Un client prudent refuse d’installer la route par défaut et signale une erreur, tandis qu’un client moins prudent signale un succès puis ne déplace rien. L’échec silencieux est celui qui coûte un après-midi.

La correspondance du préfixe le plus long décide de la recherche avant toute métrique, donc une route vers une seule adresse prime sur toutes les routes par défaut de la machine. C’est tout le mécanisme derrière la réparation.

Installez l’exception avant la route par défaut

Créez une route vers une seule adresse pour le serveur, avec la passerelle physique comme saut suivant, avant que la route par défaut ne bouge. L’ordre compte : l’installer ensuite revient à vivre avec un tunnel cassé pendant que vous tapez.

La plupart des clients le font sans qu’on le leur demande. OpenVPN recherche l’adresse distante et l’épingle avant de réécrire la passerelle par défaut, et son option route-delay existe pour les plateformes où cette séquence fait la course. wg-quick prend un chemin entièrement différent, en marquant les paquets et en consultant une règle de politique au lieu d’ajouter une exception. Mécanismes différents, même exigence : le paquet extérieur doit s’échapper du tunnel qu’il crée.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

La sortie de la recherche est le test d’acceptation. Elle doit nommer le périphérique physique et le saut suivant physique. Un périphérique de tunnel dans cette réponse signifie que l’exception manque, ou qu’elle a été placée après quelque chose qui la supplante.

L’image miroir sur le serveur

Le même piège attend de l’autre côté, inversé. Donnez au serveur une route par défaut par un autre tunnel, ou poussez-lui une route qui couvre les adresses publiques des clients, et ses réponses prendront l’habitude d’aller dans la mauvaise direction.

Imaginez un client qui se connecte et envoie une requête. La réponse est adressée à l’adresse publique de ce client, qui correspond maintenant à une route de tunnel, donc elle part d’une autre interface en portant une source que le client n’a jamais composée. Le client peut recevoir ce paquet et quand même le rejeter, car rien ne le lie à la requête qu’il a envoyée. Partez de la décision de routage du serveur plutôt que du délai d’attente du client, car une seule des deux montre le choix réel.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Il existe trois réparations et elles ne se valent pas. Épingler le service à l’adresse physique, ou traduire la source, toutes deux cachent la décision de routage au lieu de la corriger. Envoyer le trafic de réponse du pool de tunnel par une table dédiée corrige la cause, et les deux autres ne sont acceptables que tant que la conception du routage est figée.

Des exceptions que le tunnel ne cesse de voler

Une poignée de tâches ont besoin de l’internet ouvert même quand le tunnel possède la route par défaut, et chacune a besoin de sa propre exception. Le programme de mise à jour du DNS dynamique est généralement le premier à casser.

Il résout le fournisseur, ouvre une connexion et découvre que ses propres paquets passent par un tunnel dont l’adresse a changé il y a quelques secondes, donc la mise à jour échoue ou publie la mauvaise adresse. Trois issues : épingler le fournisseur avec une route d’hôte via la passerelle physique, exécuter la mise à jour avant que le tunnel monte, ou donner au programme une table de politique que le tunnel ne touche jamais. La synchronisation horaire présente la même exposition sur un appareil qui démarre sans résolveur, et les points de validation de certificats figurent sur la liste pour la même raison.

Une exception que personne n’a écrite est une exception que la prochaine reconstruction laissera tomber en silence.

Prouvez-le après une reconnexion, pas avant

Testez trois destinations, pas une : le point de sortie, une adresse privée derrière le tunnel et une adresse publique au-delà. Une seule recherche réussie ne dit presque rien des deux autres.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Ensuite, relancez la connexion, car un client qui reconstruit sa table à la reconnexion écartera une route que vous avez tapée à la main. Avec un kill switch en jeu, vérifiez que le point de sortie est autorisé, sinon le tunnel ne peut pas revenir après un changement de réseau et le symptôme ressemble à une panne. Stockez l’exception dans le profil ou le fichier unit plutôt que dans l’historique du shell, pour que la reconnexion la recrée au lieu de l’effacer.