La vostra VM fa servir la VPN de l'amfitrió? Proveu-ho des de dins del convidat

Comproveu la IP pública de l'amfitrió, hi apareix la VPN i concloeu que la VM està coberta. Aquesta conclusió no la sosté la prova. El convidat té la seva pròpia taula d'encaminament, el seu propi resolutor i les seves pròpies interfícies, i l'adreça de sortida de l'amfitrió no diu res d'aquestes.

La prova s'ha de fer dins del convidat i ha de dir què ha mesurat.

Comenceu dins del convidat, no al navegador de l'amfitrió

Anoteu primer el mode de xarxa de l'hipervisor: NAT, bridged, host-only o macvtap. En mode NAT l'amfitrió encamina el trànsit del convidat, així que el túnel de l'amfitrió es pot aplicar o no segons com el client instal·li les rutes. En mode bridged el convidat és un igual a la LAN física i el túnel de l'amfitrió és irrellevant. Aquests dos modes donen respostes oposades amb la mateixa configuració de l'amfitrió.

Anoteu el mode abans de canviar res, perquè determina què pot significar el resultat.

Feu una petició de destinació coneguda

Feu servir una petició innòcua a un servei que informi de l'adreça d'origen que ha vist. Després comproveu la decisió d'encaminament del mateix convidat per a aquesta destinació: ip route get 203.0.113.5 imprimeix la interfície i la porta d'enllaç que farà servir el convidat.

Si la interfície és la NIC normal del convidat, el trànsit no passa per cap túnel dins del convidat.

Un segon adaptador, un paràmetre de proxy o un client VPN al costat del convidat poden canviar la resposta per a una aplicació i no per a una altra. Proveu l'aplicació que realment us importa, no una petició genèrica feta des d'una shell.

Comproveu el resolutor a part

Una adreça de sortida diferent no us diu quin resolutor ha gestionat el nom de l'amfitrió. Consulteu el nom explícitament amb l'eina que correspongui a la plataforma i anoteu quin servidor ha respost. Un DNS dividit vol dir que la pregunta del resolutor i la de l'encaminament tenen respostes diferents.

Aquestes dues poden divergir en qualsevol direcció, i la divergència sovint és l'error real.

En un amfitrió amb systemd, resolvectl query anomena la interfície i el servidor DNS que hi ha darrere la resposta. Les instal·lacions més antigues mostren el servidor a la sortida de dig — en qualsevol cas, el punt és veure quin servidor ha respost, no només si ha arribat una resposta.

Proveu la política de fallada, no només l'èxit

Si el requisit és que cap trànsit surti fora del túnel, una petició correcta no demostra res. Feu servir la prova de fallada controlada compatible amb el client: atureu el túnel de la manera suportada i mireu si es bloqueja una petició nova del convidat. No presumiu que el kill switch del client de l'amfitrió cobreixi qualsevol disposició de reenviament virtual. El seu abast documentat és l'únic en què us podeu refiar.

Un convidat que torna a la NIC física quan cau el túnel fa exactament el que el mode NAT permet.

Anoteu el mode i l'abast

Anoteu el mode de l'hipervisor, la interfície i la ruta del convidat, el resolutor i l'aplicació que heu provat. Afegiu la data, perquè restaurar una instantània o actualitzar l'hipervisor pot canviar les quatre coses.

Si IPv4 ha seguit el túnel, digueu-ho. No estengueu l'afirmació a IPv6, a un altre espai de noms o a una altra VM en una altra xarxa.