Per què falla la VPN convidada darrere del NAT de VirtualBox?

Un navegador dins de la màquina virtual funciona, i el client VPN al mateix convidat no pot transportar dades. El convidat té connectivitat, és clar, així que la fallada és en el que necessita el protocol exterior de la VPN i en el que deixarà passar el NAT virtual. Tres condicions decideixen el resultat: quin procés posseeix la VPN, com es veu l'intercanvi exterior al fil i si el mode de l'adaptador és el que us penseu. Anomenar la condició que podeu canviar és tota la decisió.

Localitzeu el procés de la VPN abans de culpar la xarxa

Decidiu primer si la VPN s'executa dins del convidat o a l'amfitrió, perquè els dos arranjaments fallen de manera diferent. Un client dins del convidat construeix la seva pròpia connexió exterior a través de l'adaptador del convidat i de qualsevol traducció que hi hagi darrere. Una VPN d'amfitrió captura el trànsit del convidat segons la política de l'amfitrió i de l'hipervisor, que és un punt de captura separat amb les seves pròpies regles. Poden funcionar alhora i confondre les proves, així que identifiqueu la que ha de transportar aquest trànsit abans de tocar-ne cap.

Anoteu el mode de l'adaptador del convidat ara, abans de canviar res. Aquest sol valor explica la major part del que ve i és la primera cosa que us preguntarà algú més endavant.

L'intercanvi exterior decideix la compatibilitat

La guia de xarxes de VirtualBox enumera limitacions del NAT que importen aquí: no deixarà passar protocols que no siguin TCP i UDP, GRE hi apareix com a no admès i PPTP es posa com a exemple afectat. PPTP fa servir un intercanvi de control TCP i GRE per a les dades, així que la connexió de control pot tenir èxit mentre el camí de dades no pot creuar la mateixa frontera. Són dues proves diferents i només una tracta del transport de trànsit. Permetre el port TCP 47 en una regla de tallafoc no és el mateix que permetre el protocol IP 47, i els dos es confonen constantment.

Manteniu la limitació lligada a aquest arranjament NAT i no a cada dispositiu que faci servir la paraula NAT. Un encaminador físic pot deixar passar GRE sense queixa mentre el NAT virtual el descarta, i un altre hipervisor pren la seva pròpia decisió sobre què reenvia. On l'organització ofereixi un transport aprovat dins de TCP o UDP, feu servir el seu client i perfil admesos per a aquest camí. La compatibilitat és un requisit entre diversos i no estableix ni la confiança del servidor ni el permís del compte ni rutes privades que funcionin.

Què canvia realment el pont

Un pont lliura l'adreça MAC del convidat al segment físic en lloc d'amagar-la darrere de la traducció. El convidat pren llavors una adreça de qualsevol servidor DHCP que serveixi aquell segment, respon ARP per a aquesta adreça i apareix davant del commutador superior com un port més. Això elimina el camí de traducció virtual, que és exactament per què una recepta antiga el recomana, i canvia tres coses més en el mateix moment. L'adreçament ara ve del segment local i no de l'hipervisor, l'exposició vol dir que el convidat és visible per a aquell segment, i l'admissió depèn del port del commutador i de la seva política. Cadascuna pot ser un motiu per refusar el canvi i cap tracta del protocol VPN.

El pont no instal·la un connector que falta, no proporciona un agent secret no disponible ni repara un rebuig d'autenticació. Tampoc no fa que un protocol obsolet sigui una bona elecció, i on l'operador té un reemplaçament mantingut, la decisió és aquest i no canviar l'hipervisor. El reenviament de ports és una tercera funció del tot: publica un servei d'entrada i no fa res pel protocol exterior d'un client de sortida.

Dos túnels, dos rastres de proves

Una VPN convidada necessita un camí utilitzable des de la interfície del convidat fins al seu parell abans que cap adreça interna ni ruta privada importi. On hi hagi una VPN d'amfitrió, pot retransmetre o bloquejar aquest intercanvi exterior segons la seva política, i el túnel intern del convidat només comença després que l'exterior tingui èxit. La cobertura de cap capa no es pot llegir d'una sola icona connectada ni de l'adreça pública del navegador de l'amfitrió.

Quedeu-vos amb el primer missatge d'error i no amb l'últim, perquè la fallada més primerenca nomena la capa. Canvieu un arranjament de xarxa admès alhora, amb el mateix perfil de convidat i les mateixes credencials, perquè la comparació signifiqui alguna cosa. Decidiu per la fallada quina etapa s'ha trencat: integració local, transport, autenticació o accés a recursos després que el túnel estigui aixecat. Cadascuna té un propietari diferent i només una és una qüestió d'hipervisor.

Quina condició us bloqueja de fet

A hores d'ara la decisió es redueix a tres preguntes amb respostes diferents. Si el protocol exterior queda fora de TCP i UDP, el mode NAT és la restricció, i el camí endavant és el pont o un transport TCP/UDP aprovat. Si l'intercanvi exterior es completa i el camí de dades no, la restricció és la mateixa que es veu a la segona prova. Si el túnel s'aixeca i els recursos no responen, el problema ja ha passat més enllà de l'hipervisor cap a l'encaminament o la política.

Anoteu la resposta amb el mode de l'adaptador al costat, o la persona següent repetirà la mateixa tarda. Proveu l'aplicació real i la resolució de noms dins del convidat després de qualsevol correcció, i torneu a connectar-vos i exerciteu la política de fallada. Una pàgina web que funciona a través del túnel només demostra que el camí web funciona, que és una afirmació més petita del que sembla en aquell moment.