Votre VM utilise-t-elle le VPN de l'hôte ? Testez-le depuis l'invité

Vous vérifiez l'IP publique de l'hôte, elle affiche le VPN, et vous concluez que la VM est couverte. Cette conclusion n'est pas étayée par le test. Un invité a sa propre table de routage, son propre résolveur et ses propres interfaces, et l'adresse de sortie de l'hôte ne dit rien à leur sujet.

Le test doit être exécuté dans l'invité et doit nommer ce qu'il a mesuré.

Commencez dans l'invité, pas dans le navigateur de l'hôte

Notez d'abord le mode réseau de l'hyperviseur : NAT, bridged, host-only ou macvtap. En mode NAT, l'hôte route le trafic de l'invité, donc le tunnel de l'hôte peut s'appliquer ou non selon la façon dont le client installe les routes. En mode bridged, l'invité est un pair sur le LAN physique et le tunnel de l'hôte n'a aucune importance. Ces deux modes donnent des réponses opposées à partir de la même configuration de l'hôte.

Notez le mode avant de changer quoi que ce soit, car il détermine ce que le résultat peut signifier.

Faites une requête dont vous connaissez la destination

Utilisez une requête anodine vers un service qui indique l'adresse source qu'il a vue. Vérifiez ensuite la décision de routage de l'invité lui-même pour cette destination : ip route get 203.0.113.5 affiche l'interface et la passerelle que l'invité utilisera.

Si l'interface est la carte réseau normale de l'invité, le trafic ne passe pas par un tunnel dans l'invité.

Un second adaptateur, un réglage de proxy ou un client VPN côté invité peuvent changer la réponse pour une application et pas pour une autre. Testez l'application qui vous importe vraiment, pas une requête générique depuis un shell.

Vérifiez le résolveur séparément

Une adresse de sortie différente ne vous dit pas quel résolveur a traité le nom d'hôte. Interrogez le nom explicitement avec l'outil adapté à la plateforme et notez quel serveur a répondu. Un DNS séparé signifie que la question du résolveur et celle du routage ont des réponses différentes.

Ces deux-là peuvent diverger dans les deux sens, et la divergence est souvent le vrai bug.

Sur un hôte systemd, resolvectl query nomme l'interface et le serveur DNS derrière la réponse. Les installations plus anciennes montrent le serveur dans la sortie de dig — dans tous les cas, le but est de voir quel serveur a répondu, pas seulement si une réponse est arrivée.

Testez la politique de défaillance, pas seulement le succès

Si l'exigence est qu'aucun trafic ne sorte hors du tunnel, une requête réussie ne prouve rien. Utilisez le test de défaillance contrôlé pris en charge par le client : arrêtez le tunnel de la manière prise en charge et regardez si une nouvelle requête de l'invité est bloquée. Ne présumez pas que le kill switch du client de l'hôte couvre toutes les dispositions de transfert virtuel. Son périmètre documenté est la seule chose sur laquelle vous pouvez compter.

Un invité qui retombe sur la carte réseau physique quand le tunnel tombe fait exactement ce que le mode NAT autorise.

Notez le mode et le périmètre

Notez le mode de l'hyperviseur, l'interface et la route de l'invité, le résolveur et l'application que vous avez testée. Ajoutez la date, car une restauration de snapshot ou une mise à jour de l'hyperviseur peut changer les quatre.

Si IPv4 a suivi le tunnel, dites-le. N'étendez pas l'affirmation à IPv6, à un autre espace de noms ou à une autre VM sur un autre réseau.