Una màquina virtual Hyper-V utilitza la VPN de l'amfitrió? Depèn del commutador
La VPN de l'amfitrió no és un paràmetre de tota la màquina. El tipus de commutador decideix si el trànsit dels convidats es pontetja, s'encamina per l'amfitrió o s'aïlla, i això canvia la resposta.
Instal·leu un client VPN a l'amfitrió Hyper-V, obriu-hi un navegador i l'adreça de sortida canvia; obriu la mateixa pàgina dins de la màquina virtual i pot mostrar l'adreça antiga, o res de res. La conclusió habitual és que la màquina virtual està espatllada, o que cal activar l'encaminament dividit. Cap de les dues coses no se'n deriva. Un client VPN no és una propietat de la màquina; és un conjunt de rutes, un adaptador virtual i sovint un filtre lligat a interfícies concretes. Que el trànsit dels convidats arribi mai a aquesta maquinària depèn del commutador virtual que utilitza el convidat.
El mite, dit planerament
La creença és que una VPN instal·lada a l'amfitrió protegeix tota la màquina, màquines virtuals incloses, perquè una màquina virtual només és un procés que s'executa en aquesta màquina. És una creença còmoda, perquè l'antivirus i els tallafocs de l'amfitrió normalment es comporten així. Els camins de xarxa no.
El marc del convidat només el toca la pila VPN de l'amfitrió si l'amfitrió l'encamina o el filtra. Copieu aquesta frase en un pòstit, perquè cada cas de sota n'és una variació.
Tres tipus de commutador, tres camins
Un commutador extern enllaça un adaptador virtual a una targeta de xarxa física, i el convidat envia marcs per aquest enllaç amb la seva pròpia adreça MAC. El convidat esdevé un igual a la xarxa física, amb la seva pròpia concessió DHCP, la seva passarel·la i els seus servidors DNS. La ruta per defecte de la VPN de l'amfitrió viu a la pila de l'amfitrió i no mou aquests marcs, perquè es pontetgen en lloc d'encaminar-se per l'amfitrió. Per això mateix un commutador extern sobre un adaptador Wi-Fi és una mala idea: la majoria de controladors sense fil no porten marcs per a una segona adreça MAC.
Un commutador intern connecta els convidats a un adaptador virtual de l'amfitrió. Per si sol no ofereix cap sortida a internet; un objecte NAT a l'amfitrió fa la traducció, tal com es descriu a la guia NAT d'Hyper-V. Ara els paquets del convidat sí que entren a l'encaminament i al camí NAT de l'amfitrió, així que les rutes i els filtres del client VPN tornen a importar. Aquesta és la disposició en què la màquina virtual segueix de debò la VPN de l'amfitrió, i en què un kill switch pot tallar el convidat del tot.
Un commutador privat no té adaptador d'amfitrió ni enllaç ascendent. Els convidats parlen entre ells i amb res més, així que si una màquina virtual en un commutador privat no té internet, l'encaminador que falta n'és la causa i la VPN no hi té res a veure.
El commutador per defecte és una disposició a part
Windows inclou un commutador per defecte que combina un commutador intern amb NAT i un proxy DNS. La seva subxarxa la tria l'amfitrió, pot canviar després de reiniciar i no és el mateix objecte que una xarxa NAT que creeu vosaltres. Reconstruir-lo com si fos una xarxa de laboratori és com la gent acaba amb dues NAT i un convidat que encara no té ruta.
Si la màquina virtual és al commutador per defecte, llegiu l'adreça que ha rebut el convidat i compareu-la amb la taula NAT de l'amfitrió abans de tocar el client VPN. Una discrepància entre la passarel·la del convidat i el prefix NAT explica més fallades que qualsevol paràmetre del client.
Quatre fets que resolen la pregunta
Recolliu això abans de canviar res: el tipus de commutador i el seu enllaç ascendent, l'adaptador connectat a la màquina virtual, l'adreça, la passarel·la i el DNS del mateix convidat, i l'estat de NAT i de la ruta per defecte de l'amfitrió. Les ordres de només lectura són Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, i Get-NetRoute -DestinationPrefix 0.0.0.0/0; i dins del convidat, ipconfig /all dóna la resta.
Després decidiu què ha de fer el convidat. Si ha de quedar-se fora de la VPN, obteniu l'excepció suportada pel proveïdor per a aquest camí exacte, perquè excloure un executable de l'amfitrió no eximeix el trànsit reenviat de la màquina virtual. Si ha d'utilitzar la VPN, confirmeu com tracta el client, segons la documentació, el trànsit de màquines virtuals, en lloc de suposar que una prova al navegador de l'amfitrió ho cobreix.
Una prova dins del convidat és l'única evidència que compta. Comproveu l'adreça de sortida des del convidat, resoleu un nom intern, reconnecteu la VPN i repetiu. El resultat del navegador de l'amfitrió no substitueix res d'això.
Què costa el mite
La gent desactiva el kill switch, afegeix rutes estàtiques o esborra i torna a crear commutadors només perquè passi una prova. Cada drecera canvia el mode de fallada: el convidat pot arribar a internet per un camí que ningú no volia, o l'amfitrió pot perdre la connectivitat quan un commutador extern torna a enllaçar el seu adaptador físic.
Tornar a enllaçar un commutador extern interromp l'accés propi de l'amfitrió, així que manteniu obert un camí fora de banda i eviteu esborrar commutadors mentre encara diagnostiqueu. El resultat correcte és el camí desitjat del convidat, incloent-hi com es reconnecta i com falla, no una marca verda d'una càrrega de pàgina.
La resposta duradora és una línia per màquina virtual a l'inventari: quin commutador utilitza i quin component li proporciona la passarel·la. Amb això escrit, el proper canvi de VPN és una consulta en lloc d'una tarda d'endevinar.