Xarxa local inaccessible amb la VPN connectada? Quatre comprovacions

El túnel s’aixeca, la intranet apareix i la impressora deixa de respondre. No ha fallat res a la xarxa local; el client ha canviat el camí que fa servir per a les adreces que ja no considera locals. Recorre les quatre comprovacions següents en ordre i atura’t quan una produeixi una discrepància concreta, perquè el mateix símptoma té quatre causes habituals i només una es resol editant la VPN.

Primer, mira la taula de rutes que ha instal·lat el client

Obre la taula de rutes del client mentre la VPN està connectada. A Linux fes servir ip route, a Windows route print o Get-NetRoute, i a macOS netstat -rn. Busques una ruta per defecte a través del túnel i què ha passat amb la ruta per defecte física.

Un client de túnel complet sovint afegeix dues rutes mig per defecte, 0.0.0.0/1 i 128.0.0.0/1, en lloc de substituir 0.0.0.0/0. La ruta per defecte original continua visible però perd totes les consultes, i per això la taula pot semblar intacta mentre tot el trànsit fora de la subxarxa es mou. Si el client VPN ofereix una opció de túnel dividit i la política ho permet, aquesta és la reparació més neta.

Si el túnel ha de continuar sent la ruta per defecte, fixa la subxarxa local. A Linux la ruta indica la interfície física i la porta d’enllaç; a Windows afegeix -p perquè sigui persistent i llegeix el número d’interfície de route print en lloc d’endevinar-lo:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Una ruta fixada només aguanta mentre l’adreça que indica no canvia. Un portàtil que renumera l’adaptador Wi-Fi a cada connexió trencarà la regla una altra vegada, així que comprova l’adreça de la interfície abans de decidir que la reparació ha fallat.

Segon, confirma que l’adreça era local des del principi

Si la destinació és dins de la subxarxa connectada, la ruta per defecte del túnel no s’aplica mai i la VPN no n’és la causa. Una impressora a 192.168.1.40 en un client amb 192.168.1.0/24 fa servir la ruta connectada; si aquesta adreça falla, mira el dispositiu, el commutador o el tallafoc del client en lloc de la VPN.

El cas que enganya la gent és una adreça pública per a un servidor local. Des de dins de la xarxa local, arribar a l’adreça WAN del router i tornar requereix NAT de forquilla, i molts routers simplement no el implementen per a redireccions de port. Prova l’adreça privada al costat de la pública. Si la privada funciona i la pública no, la VPN només ha deixat al descobert una limitació de NAT que ja hi era.

Un nom d’amfitrió ho empitjora. Si el nom local ara es resol a l’adreça pública, el client continuarà provant el camí que no pot tornar. Fes servir l’adreça privada per a la prova i després arregla el nom en lloc d’afegir una altra redirecció de port.

Tercer, mira qui respon als noms ara

Un resolutor corporatiu coneix la intranet i normalment no sap res d’un nom d’amfitrió NAS, del nom Bonjour d’una impressora o de l’àlies local d’un router. Quan la VPN empeny els seus servidors DNS, aquests noms deixen de resoldre’s encara que les seves adreces segueixin sent accessibles. Consulta el nom directament i compara la resposta amb l’adreça que saps que té el dispositiu.

A Linux, resolvectl query nas.local mostra quin resolutor ha respost. A Windows, nslookup nas.local indica el servidor, i ipconfig /all mostra l’ordre dels resolutors. Si el sufix local ara el gestiona el resolutor corporatiu, o bé redirigeix aquest sufix al resolutor local o bé fes servir l’adreça IP del dispositiu.

La descoberta és una capa separada. mDNS i la difusió no travessen un túnel encaminat, així que un dispositiu pot ser accessible per adreça mentre el seu nom continua invisible. Un reflector o una entrada DNS local ho resol; una ruta no.

Quart, comprova si l’altra màquina també és en una VPN

Quan la màquina a la qual vols arribar també executa un client VPN, la teva sessió pot arribar mentre la seva resposta surt per l’altre túnel. Això produeix una connexió que s’estableix i després s’encalla, o un intent de RDP i SSH que expira sense cap error a la teva banda. Revisa la taula de rutes de l’altre amfitrió i la seva ruta per defecte abans de culpar el teu client.

Comprova també l’adreça en què escolta el servei. Un oient lligat només a l’adreça del túnel accepta connexions de la VPN i les rebutja de la xarxa local, fins i tot quan l’encaminament és perfecte. Això és configuració del servei, no un camí de xarxa, i és habitual en interfícies de gestió que es van tancar a l’adreça de la VPN.

Mantén un camí de gestió que no depengui del túnel: una ruta estàtica que anomeni la teva xarxa d’origen, una altra interfície connectada a la xarxa local o una consola que eviti el túnel del tot. Dissenyar aquest camí després que caigui la sessió és molt més difícil que afegir-lo abans de la propera connexió.

Aplica la reparació que correspon a la comprovació que ha fallat

Si la taula de rutes ha mostrat una captura de mig per defecte, tria túnel dividit quan la política ho permeti i una ruta local fixada quan no ho permeti. Si l’adreça resulta ser pública, canvia la prova i el nom a l’adreça privada. Si el resolutor ha canviat de mans, limita el sufix local o fes servir l’adreça. Si l’altre amfitrió és dins d’un túnel, arregla la seva ruta de tornada o la vinculació de l’oient.

Canvia una cosa i després repeteix la mateixa comprovació. Una ruta afegida per a la subxarxa equivocada, un sufix de resolutor amb una errata i una ruta fixada en una interfície que es renumera semblen tots la fallada original. La repetició és el que separa una reparació d’una casualitat.

Anota la ruta, l’adreça i el resolutor que funcionaven amb la VPN connectada. La propera reconnexió canviarà almenys un d’ells, i la nota converteix la propera avaria en una comparació curta en lloc d’una investigació nova.