Pourquoi votre VPN invité échoue-t-il derrière le NAT de VirtualBox ?

Un navigateur dans la machine virtuelle fonctionne, et le client VPN sur le même invité ne peut pas transporter de données. L'invité a manifestement de la connectivité, donc la panne se situe dans ce qu'exige le protocole externe du VPN et dans ce que le NAT virtuel laissera passer. Trois conditions décident du résultat : quel processus possède le VPN, à quoi ressemble l'échange externe sur le fil et si le mode de l'adaptateur est celui que vous croyez. Nommer la condition que vous pouvez changer, c'est toute la décision.

Localisez le processus VPN avant d'accuser le réseau

Décidez d'abord si le VPN s'exécute dans l'invité ou sur l'hôte, car les deux dispositions échouent différemment. Un client dans l'invité construit sa propre connexion externe via l'adaptateur de l'invité et toute traduction située derrière. Un VPN de l'hôte capture le trafic de l'invité selon la politique de l'hôte et de l'hyperviseur, ce qui est un point de capture distinct avec ses propres règles. Les deux peuvent tourner en même temps et brouiller les preuves, identifiez donc celui qui est censé transporter ce trafic avant de toucher à l'un ou l'autre.

Notez le mode de l'adaptateur de l'invité maintenant, avant de changer quoi que ce soit. Cette seule valeur explique l'essentiel de ce qui suit, et c'est la première chose que quiconque vous demandera plus tard.

L'échange externe décide de la compatibilité

Le guide réseau de VirtualBox énumère des limitations du NAT qui comptent ici : il ne laissera pas passer d'autres protocoles que TCP et UDP, GRE est cité comme non pris en charge et PPTP est donné comme exemple touché. PPTP utilise un échange de contrôle TCP et GRE pour les données, si bien que la connexion de contrôle peut réussir alors que le chemin de données ne peut pas franchir la même frontière. Ce sont deux preuves différentes, et une seule concerne le transport du trafic. Autoriser le port TCP 47 dans une règle de pare-feu n'est pas la même chose qu'autoriser le protocole IP 47, et les deux sont constamment confondus.

Gardez la limitation attachée à cette disposition NAT et non à chaque appareil qui emploie le mot NAT. Un routeur physique peut laisser passer GRE sans broncher alors que le NAT virtuel le rejette, et un autre hyperviseur fait son propre choix sur ce qu'il transmet. Là où l'organisation propose un transport approuvé dans TCP ou UDP, utilisez son client et son profil pris en charge pour ce chemin. La compatibilité est une exigence parmi plusieurs, et elle n'établit ni la confiance du serveur, ni l'autorisation du compte, ni des routes privées fonctionnelles.

Ce que le pont change réellement

Un pont transmet l'adresse MAC de l'invité au segment physique au lieu de la cacher derrière une traduction. L'invité prend alors une adresse auprès du serveur DHCP qui dessert ce segment, répond en ARP pour cette adresse et apparaît au commutateur amont comme un port de plus. Cela supprime le chemin de traduction virtuel, ce qui est exactement pourquoi une ancienne recette le recommande, et cela change trois autres choses au même moment. L'adressage vient désormais du segment local et non de l'hyperviseur, l'exposition signifie que l'invité est visible pour ce segment, et l'admission dépend du port du commutateur et de sa politique. Chacune peut être une raison de refuser le changement, et aucune ne concerne le protocole VPN.

Le pontage n'installe pas un greffon manquant, ne fournit pas un agent secret indisponible et ne répare pas un rejet d'authentification. Il ne fait pas non plus d'un protocole obsolète un bon choix, et là où l'exploitant dispose d'un remplacement maintenu, c'est celui-ci la décision, et non le changement d'hyperviseur. La redirection de port est une troisième fonction tout à fait distincte : elle publie un service entrant et ne fait rien pour le protocole externe d'un client sortant.

Deux tunnels, deux pistes de preuves

Un VPN invité a besoin d'un chemin utilisable de l'interface de l'invité vers son pair avant qu'une adresse interne ou une route privée n'ait d'importance. Là où un VPN de l'hôte est présent, il peut relayer ou bloquer cet échange externe selon sa propre politique, et le tunnel interne de l'invité ne commence qu'après la réussite de l'externe. La couverture d'aucune couche ne se lit sur une seule icône connectée ni sur l'adresse publique du navigateur de l'hôte.

Gardez le premier message d'erreur plutôt que le dernier, car l'échec le plus précoce nomme la couche. Changez une disposition réseau prise en charge à la fois, avec le même profil invité et les mêmes identifiants, pour que la comparaison signifie quelque chose. Décidez d'après l'échec quelle étape a cassé : intégration locale, transport, authentification ou accès aux ressources une fois le tunnel monté. Chacune a un propriétaire différent, et une seule est une question d'hyperviseur.

Quelle condition vous bloque réellement

Désormais la décision se réduit à trois questions aux réponses différentes. Si le protocole externe se situe hors de TCP et UDP, le mode NAT est la contrainte, et le pont ou un transport TCP/UDP approuvé est la voie à suivre. Si l'échange externe aboutit et que le chemin de données non, la contrainte est la même que celle vue à la deuxième preuve. Si le tunnel monte et que les ressources ne répondent pas, le problème a déjà dépassé l'hyperviseur vers le routage ou la politique.

Écrivez la réponse avec le mode de l'adaptateur à côté, sinon la personne suivante répétera le même après-midi. Testez l'application réelle et la résolution de noms dans l'invité après toute correction, puis reconnectez-vous et éprouvez la politique d'échec. Une page web qui fonctionne à travers le tunnel ne prouve que le chemin web fonctionne, ce qui est une affirmation plus petite qu'il n'y paraît sur le moment.