Le serveur web disparaît dès que le client VPN se connecte

Un service qui disparaît à l’instant où un client VPN se connecte n’est généralement pas bloqué, il répond par la mauvaise interface. La requête arrive sur la carte réseau physique, le démon écrit une réponse, et la table de routage remet cette réponse au tunnel, puisque le tunnel a repris la route par défaut. Le client distant ne voit jamais de réponse à une connexion qu’il a ouverte, il attend donc puis signale un délai d’attente dépassé. Aucune règle de pare-feu n’intervient nulle part dans cette séquence.

Le symptôme : des requêtes entrantes, des réponses sortant par la mauvaise porte

L’indice est une connexion entrante qui échoue alors que tout le reste sur l’hôte fonctionne. Un autre indice est un hôte joignable depuis le LAN mais pas depuis internet, ou un hôte qui fonctionne jusqu’à ce que le tunnel se reconnecte et s’arrête ensuite. Dans chaque cas le sens aller se comportait bien et le sens retour non, ce qui pointe vers une asymétrie de routage plutôt que vers une politique.

Confirmez-le en observant où va la réponse, non en observant comment la requête arrive.

Capturez à la fois sur l’interface physique et sur le périphérique du tunnel. Si la requête apparaît sur l’interface physique et la réponse sur le tunnel, le diagnostic est terminé. Une réponse qui n’apparaît nulle part signifie que le service n’a jamais accepté la connexion, ce qui est une enquête distincte avec une cause distincte.

Deux routes par défaut et une seule décision de routage

Un client qui installe une route par défaut ajoute une seconde entrée dont la métrique est meilleure que celle de la passerelle du LAN. Certains clients installent plutôt deux routes de demi-plage, qui couvrent le même espace de façon plus précise et gagnent la recherche de la même manière. L’une ou l’autre technique laisse les paquets sortants ordinaires choisir l’interface du tunnel.

Ce choix se fait uniquement par destination. Le noyau ne demande pas d’où vient un paquet, sauf si une règle de politique le lui impose. La réponse à une adresse publique de client est donc remise au tunnel, dont l’extrémité distante reçoit un paquet dont l’adresse source ne lui appartient pas et le rejette ou le transmet quelque part d’inutile. Sous Linux, un filtrage strict du chemin inverse peut aussi supprimer la requête d’origine avant même que votre service ne la voie, ce qui de l’extérieur semble identique. Les deux symptômes viennent de la même association manquante entre un flux entrant et sa réponse.

Le tunnel se comporte correctement tout du long. On lui a demandé de porter la route par défaut et il fait exactement cela.

Réparez le chemin de retour sans casser le tunnel

Il existe trois formes durables de réparation, et le choix dépend de la part du trafic propre de l’hôte qui doit rester à l’intérieur du tunnel. Exclure la destination ou le port du service est le changement le plus petit. Le routage par politique selon la source ou la marque est le plus précis. La traduction de source est la plus grossière et la plus facile à expliquer deux ans plus tard.

Choisissez selon ce que l’hôte doit faire, non selon le fragment que vous avez trouvé en premier.

Exclure une destination convient à un service doté d’une adresse publique stable, et lier le démon à l’adresse physique plutôt qu’à toutes les adresses rend cette exclusion plus sûre. Une règle de politique qui choisit une table selon la source garde les connexions propres de l’hôte à l’intérieur du tunnel tout en renvoyant les réponses du service par la passerelle WAN. Le masquage des réponses vers l’interface WAN atteint le même chemin au prix de cacher l’adresse du client dans les journaux du service. Un changement ponctuel de la route par défaut est un diagnostic et non une configuration, car le client réécrit les routes à chaque reconnexion.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Quand l’hôte route aussi pour un LAN derrière lui

Un saut plus loin, la même asymétrie revient avec plus de pièces mobiles. Le trafic atteint le routeur depuis internet, est transmis à un appareil interne, et le seul chemin de retour de cet appareil est le tunnel, si bien que la réponse parvient au client d’origine depuis l’adresse du fournisseur lui-même. Le suivi de connexions rencontre alors une réponse pour un flux dont il n’a pas vu le début, et la rejette. Le client, pendant ce temps, ne voit absolument rien.

Deux changements y remédient : une traduction de destination pour que la connexion entrante atteigne l’appareil interne, et une traduction de source pour que la réponse de cet appareil semble venir du routeur lui-même.

Sur le firmware d’un routeur, l’expression habituelle est une règle de politique qui fixe la redirection de port du côté WAN tandis que le trafic propre du routeur passe par le tunnel. Sans traduction de source, cette réponse est adressée au client externe et l’appareil interne n’a tout simplement aucune route vers elle. Testez trois choses séparément, car elles échouent pour des raisons différentes : une connexion venant de l’extérieur, une que l’hôte initie lui-même et une résolution de nom.