VPN dans l’invité et VPN sur l’hôte : quelle route gagne vraiment

Deux clients tournent en même temps, chacun convaincu de posséder la route par défaut, et le symptôme arrive comme quelque chose d’étrange : une application de l’invité fonctionne, une autre se résout au mauvais endroit. Un VPN dans un invité et un VPN sur l’hôte peuvent coexister, mais seulement lorsque le chemin extérieur et la politique intérieure s’accordent sur qui transporte quoi. Démarrer les deux ne crée pas une chaîne en soi. Notez d’abord le rattachement, puis changez une chose à la fois.

Notez d’abord le rattachement de l’invité

L’invité atteint son serveur VPN par le chemin que lui a donné l’hyperviseur : NAT derrière l’hôte, pont vers le segment physique ou réseau réservé à l’hôte avec du routage ajouté par-dessus. Chaque rattachement change ce que l’invité peut voir et ce que l’hôte peut faire de son trafic. Sous NAT, les paquets de l’invité semblent venir de l’hôte, si bien que le tunnel de l’hôte peut les transporter sans que l’invité en sache quoi que ce soit. Sous un pont, l’invité a sa propre présence sur le segment et sa propre passerelle par défaut.

Notez le rattachement avant de toucher à une quelconque configuration, en précisant quel client est censé transporter quelle application. Cette phrase résout la plupart de ces cas, parce que les deux clients reposent généralement sur des hypothèses différentes. Un invité censé utiliser le tunnel de l’hôte ne doit pas avoir en plus sa propre route par défaut concurrente.

Suivez le point de sortie de l’invité vers l’extérieur

Un VPN d’invité a besoin d’un chemin utilisable vers son propre serveur avant que quoi que ce soit d’autre ne fonctionne. Lorsque le tunnel de l’hôte est actif et que l’invité se trouve derrière NAT, la poignée de main de l’invité sort par le tunnel de l’hôte, ce qui est soit la conception, soit un accident que personne n’a documenté. Lorsque le tunnel de l’hôte tombe et que l’invité en dépendait, l’invité perd la connectivité sans un seul changement de son côté. Suivre le point de sortie vers l’extérieur vous dit lequel de ces deux cas vous avez réellement.

Une route large dans l’un ou l’autre contexte capture du trafic que l’autre client attendait. Une route 0.0.0.0/0 dans l’invité et un client hôte en tunnel complet revendiquent tous deux tout, et celui qui s’applique en dernier gagne. Les chevauchements entre les réseaux virtuels de l’invité, le LAN local et les réseaux distants produisent le même effet pour les préfixes privés, avec des pannes qui ressemblent à des problèmes d’authentification ; le comportement de traduction d’adresses est celui décrit pour le réseau des conteneurs.

Comparez un relevé avant et après

Prenez une référence avec le tunnel de l’hôte coupé, ou dans tout état contrôlé que votre politique autorise, et notez la route et le résolveur de l’invité. Appliquez ensuite la configuration combinée et comparez les deux relevés, en gardant intactes les exigences de confidentialité. Si une référence directe n’est pas appropriée, écrivez cette limite dans le relevé au lieu de sauter la comparaison.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

La requête de route nomme l’interface et l’adresse source qui porteraient une destination précise, et c’est la ligne la plus utile de cette enquête. La liste des règles indique si le routage par politique envoie certaines destinations par une seconde table. La sortie du résolveur indique si le DNS a suivi le tunnel de l’invité ou est resté sur le chemin de l’hôte. Lancez les mêmes trois commandes avant et après le changement, et le delta nomme le coupable.

Gardez la propriété claire entre les redémarrages

La restriction d’accès local d’un client hôte peut bloquer le trafic vers un NAT virtuel ou un pont, et cette restriction est régulièrement confondue avec un problème d’identifiants de l’invité. Lisez le comportement documenté du client plutôt que de désactiver la restriction pour faire passer un test. Après une correction prise en charge, retestez l’application de l’invité et la politique de défaillance que vous exigez. Un hôte qui se reconnecte avec succès ne prouve rien sur la route ou le résolveur de l’invité.

Décidez quel côté possède la route par défaut et écrivez-le dans le manuel d’exploitation. Un redémarrage de l’invité ou un changement de réseau sur l’hôte qui inverse silencieusement la propriété produit un rapport de bogue sur un VPN qui n’a jamais été en cause. L’arrangement devrait survivre à un redémarrage sans que personne se souvienne pourquoi il fonctionnait.