VPN connectat, VM inaccessible? La ruta probablement no era mai el problema

Connecteu la VPN i la VM de desenvolupament que responia fa un minut queda en silenci. La història òbvia s'escriu sola: el túnel s'ha quedat la ruta, l'amfitrió ara envia el trànsit del convidat cap a la xarxa corporativa, i la solució és afegir una ruta estàtica o canviar l'adaptador a mode pont. Aquesta història de vegades és certa. Però no és la causa habitual, i actuar-hi primer sol trencar una altra cosa.

La xarxa host-only és una xarxa de programari propietat de l'amfitrió i compartida amb els seus convidats, separada de qualsevol connexió física. Res de la interfície pròpia del client VPN no canvia aquesta xarxa, així que abans de tocar-la, esbrineu quina de les quatre capes ha fallat realment.

La ruta normalment continua sent local

Pregunteu al nucli en lloc de la primera pàgina de la taula d'encaminament. A Linux, ip route get 192.168.56.10 informa de la ruta, la interfície i l'adreça d'origen exactes que s'utilitzarien, cosa que és una resposta diferent de llegir una ruta per defecte i endevinar. Si la sortida anomena la interfície host-only, el túnel no hi participa en absolut.

Dues coses sí que poden trencar-ho, i totes dues són problemes d'adreces i no de VPN. Una subxarxa remota que se solapa amb el prefix host-only fa guanyar la ruta més específica, i un client VPN que instal·la una ruta àmplia amb una mètrica més baixa pot endur-se el prefix. Tots dos són visibles a la mateixa ordre: la interfície que apareix a la sortida serà el túnel, i la correcció pertany a qui posseeix aquest pla d'adreces.

Selecció de ruta i admissió de paquets són decisions diferents

Aquesta és la part que el model mental sol oblidar. Fins i tot amb una ruta local perfecta, un client VPN pot rebutjar el paquet. Molts clients apliquen una política d'accés local a la xarxa que decideix quines destinacions es permeten fora del túnel, i una subxarxa connectada no actualitza aquesta llista automàticament.

Així, la fallada sembla idèntica a un problema d'encaminament des del costat de l'aplicació i completament diferent des del costat del client. Si ip route get anomena la interfície correcta i la connexió continua esgotant el temps, deixeu d'editar rutes i llegiu en canvi el comportament d'accés local documentat del client. Alguns clients ofereixen una llista d'autoritzats per a subxarxes locals, d'altres bloquegen tot el que no és el túnel, i d'altres només bloquegen quan hi ha un kill switch activat.

Aquesta distinció importa perquè les correccions no són intercanviables. Afegir una ruta no satisfà un filtre, i desactivar un filtre per arribar a un sol convidat és una decisió molt més gran del que suggereix el símptoma.

El convidat té tres maneres de dir que no

Un convidat que pot navegar per internet no ha demostrat res sobre el servei que voleu. El servei d'escolta pot estar lligat a 127.0.0.1 dins del convidat, i en aquest cas cap petició de l'amfitrió no pot arribar-hi, per bo que sigui el camí. Comproveu-ho amb ss -ltn dins del convidat i mireu la columna d'adreça local, no només el port.

Després hi ha el tallafoc del propi convidat. Una imatge de desenvolupament amb un valor per defecte restrictiu pot acceptar els paquets de l'amfitrió i descartar-los a la frontera del servei, cosa que produeix un temps d'espera que sembla exactament un forat negre d'encaminament. Finalment hi ha la configuració del servei: una aplicació web lligada a un nom d'amfitrió concret, o una llista d'adreces de client autoritzades, rebutjarà una petició de la subxarxa host-only encara que hi arribin tots els paquets.

Repasseu aquests tres punts abans de plantejar-vos canviar el mode de xarxa de la VM. Cadascun és un canvi més petit que redissenyar la connexió del convidat, i cadascun té una prova clara.

Què és realment un pont, i quant costa

Canviar l'adaptador a mode pont no és una reparació del camí host-only. És la decisió de posar el convidat en una altra xarxa, normalment la LAN física, on esdevé visible per a tot el que hi viu. Pot ser exactament el que voleu. Però no és el que feia la configuració original.

Feu-lo servir quan el convidat realment hagi de ser un igual en aquella LAN i l'exposició estigui aprovada. No el feu servir perquè un sol servei ha deixat de respondre, ja que el canvi pot treure el convidat de l'aïllament que el feia segur per desenvolupar-hi.

Després de qualsevol correcció aprovada, proveu en un ordre fix: una petició nova de l'amfitrió al convidat, un recurs corporatiu necessari a través del túnel, i el comportament denegat previst amb el túnel baixat. Si l'últim ja no es compleix, la correcció ha anat més enllà del problema.

La secció de VirtualBox sobre xarxa host-only descriu la interfície de programari del costat de l'amfitrió i com difereix d'una connexió en pont, que és la referència que val la pena llegir abans de suposar que els dos modes són intercanviables.