VPN activé, VM injoignable ? L'itinéraire n'était probablement jamais le problème

Connectez le VPN, et la VM de développement qui répondait il y a une minute se tait. L'histoire évidente s'écrit d'elle-même : le tunnel a pris la route, l'hôte envoie désormais le trafic de l'invité vers le réseau d'entreprise, et la correction consiste à ajouter une route statique ou à basculer l'adaptateur en mode pont. Cette histoire est parfois vraie. Mais ce n'est pas la cause habituelle, et agir dessus en premier casse généralement autre chose.

La mise en réseau host-only est un réseau logiciel détenu par l'hôte et partagé avec ses invités, distinct de tout raccordement physique. Rien dans l'interface propre au client VPN ne modifie ce réseau, donc avant d'y toucher, déterminez laquelle des quatre couches a réellement échoué.

La route reste généralement locale

Interrogez le noyau plutôt que la première page de la table de routage. Sous Linux, ip route get 192.168.56.10 indique la route, l'interface et l'adresse source exactes qui seraient utilisées, ce qui est une réponse différente de la lecture d'une route par défaut et d'une supposition. Si la sortie nomme l'interface host-only, le tunnel n'intervient pas du tout dans ce chemin.

Deux choses peuvent réellement la casser, et toutes deux sont des problèmes d'adresses, pas de VPN. Un sous-réseau distant qui chevauche le préfixe host-only fait gagner la route la plus spécifique, et un client VPN qui installe une route large avec une métrique plus basse peut retirer le préfixe. Les deux sont visibles dans la même commande : l'interface nommée dans la sortie sera le tunnel, et la correction revient à qui possède ce plan d'adressage.

Sélection de route et admission des paquets sont deux décisions différentes

C'est la partie que le modèle mental omet généralement. Même avec une route locale parfaite, un client VPN peut refuser le paquet. Beaucoup de clients appliquent une politique d'accès réseau local qui décide quelles destinations sont autorisées hors du tunnel, et un sous-réseau connecté ne met pas cette liste à jour automatiquement.

Ainsi, la panne paraît identique à un problème de routage du côté de l'application, et complètement différente du côté du client. Si ip route get nomme la bonne interface et que la connexion expire quand même, cessez de modifier des routes et lisez plutôt le comportement d'accès local documenté du client. Certains clients exposent une liste d'autorisations pour les sous-réseaux locaux, d'autres bloquent tout ce qui n'est pas le tunnel, et d'autres ne bloquent que lorsqu'un kill switch est activé.

Cette distinction compte parce que les corrections ne sont pas interchangeables. Ajouter une route ne satisfait pas un filtre, et désactiver un filtre pour atteindre un seul invité est une décision bien plus lourde que ne le suggère le symptôme.

L'invité a trois façons de dire non

Un invité qui peut naviguer sur internet n'a rien prouvé au sujet du service que vous voulez. Le service à l'écoute peut être lié à 127.0.0.1 à l'intérieur de l'invité, auquel cas aucune requête de l'hôte ne peut arriver, quelle que soit la qualité du chemin. Vérifiez avec ss -ltn dans l'invité et regardez la colonne de l'adresse locale, pas seulement le port.

Vient ensuite le pare-feu de l'invité lui-même. Une image de développement avec un réglage par défaut restrictif peut accepter les paquets de l'hôte et les rejeter à la frontière du service, ce qui produit un délai d'attente qui ressemble exactement à un trou noir de routage. Enfin, il y a la configuration du service lui-même : une application web liée à un nom d'hôte précis, ou une liste d'adresses client autorisées, refusera une requête venant du sous-réseau host-only même si chaque paquet arrive.

Passez ces trois points en revue avant d'envisager de changer le mode réseau de la VM. Chacun est un changement plus petit que de repenser le raccordement de l'invité, et chacun a un test clair.

Ce qu'est vraiment un pont, et ce qu'il coûte

Basculer l'adaptateur en mode pont n'est pas une réparation du chemin host-only. C'est la décision de placer l'invité sur un autre réseau, généralement le LAN physique, où il devient visible pour tout ce qui s'y trouve. C'est peut-être exactement ce que vous voulez. Mais ce n'est pas ce que faisait la configuration d'origine.

Utilisez-le lorsque l'invité doit vraiment être un pair sur ce LAN et que l'exposition est approuvée. Ne l'utilisez pas parce qu'un seul service a cessé de répondre, car le changement peut sortir l'invité de l'isolement qui rendait le développement sûr.

Après toute correction approuvée, testez dans un ordre fixe : une nouvelle requête de l'hôte vers l'invité, une ressource d'entreprise nécessaire à travers le tunnel, et le comportement de refus prévu avec le tunnel coupé. Si le dernier ne tient plus, la correction est allée au-delà du problème.

La section de VirtualBox sur la mise en réseau host-only décrit l'interface logicielle côté hôte et en quoi elle diffère d'un raccordement en pont, ce qui est la référence à lire avant de supposer que les deux modes sont interchangeables.