Rede local inaccesible coa VPN conectada? Catro comprobacións

O túnel levanta, a intranet aparece e a impresora deixa de responder. Nada da rede local fallou; o cliente cambiou a ruta que usa para os enderezos que xa non considera locais. Percorre as catro comprobacións seguintes en orde e detente cando unha produza unha discrepancia concreta, porque o mesmo síntoma ten catro causas habituais e só unha se arranxa editando a VPN.

Primeiro, mira a táboa de rutas que instalou o cliente

Abre a táboa de rutas do cliente mentres a VPN está conectada. En Linux usa ip route, en Windows route print ou Get-NetRoute, e en macOS netstat -rn. Buscas unha ruta predeterminada a través do túnel e que pasou coa ruta predeterminada física.

Un cliente de túnel completo adoita engadir dúas rutas medias predeterminadas, 0.0.0.0/1 e 128.0.0.0/1, en lugar de substituír 0.0.0.0/0. A ruta predeterminada orixinal segue visible pero perde todas as consultas, e por iso a táboa pode parecer intacta mentres todo o tráfico fóra da subrede se move. Se o cliente VPN ofrece unha opción de túnel dividido e a política o permite, esa é a reparación máis limpa.

Se o túnel debe seguir sendo a ruta predeterminada, fixa a subrede local. En Linux a ruta nomea a interface física e a porta de enlace; en Windows engade -p para facela persistente e le o número de interface de route print en lugar de adiviñalo:

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

Unha ruta fixada só aguanta mentres o enderezo que nomea siga igual. Un portátil que renumera o seu adaptador Wi-Fi en cada conexión volverá romper a regra, así que comproba o enderezo da interface antes de decidir que a reparación fallou.

Segundo, confirma que o enderezo era local desde o principio

Se o destino está dentro da subrede conectada, a ruta predeterminada do túnel nunca se aplica e a VPN non é a causa. Unha impresora en 192.168.1.40 nun cliente con 192.168.1.0/24 usa a ruta conectada; se ese enderezo falla, mira o dispositivo, o conmutador ou a devasa do cliente en lugar da VPN.

O caso que engana a xente é un enderezo público para un servidor local. Desde dentro da rede local, chegar ao enderezo WAN do router e volver require NAT de forcada, e moitos routers simplemente non o implementan para redireccións de porto. Proba o enderezo privado xunto ao público. Se o privado funciona e o público non, a VPN só deixou ao descuberto unha limitación de NAT que xa estaba aí.

Un nome de host empeórao. Se o nome local agora resolve ao enderezo público, o cliente seguirá tentando a ruta que non pode volver. Usa o enderezo privado para a proba e despois arranxa o nome en lugar de engadir outra redirección de porto.

Terceiro, mira quen responde aos nomes agora

Un resolutor corporativo coñece a intranet e normalmente nada sobre un nome de host NAS, o nome Bonjour dunha impresora ou o alias local dun router. Cando a VPN empurra os seus servidores DNS, eses nomes deixan de resolverse aínda que os seus enderezos sigan sendo accesibles. Consulta o nome directamente e compara a resposta co enderezo que sabes que ten o dispositivo.

En Linux, resolvectl query nas.local mostra que resolutor respondeu. En Windows, nslookup nas.local nomea o servidor e ipconfig /all mostra a orde dos resolutores. Se o sufixo local agora o xestiona o resolutor corporativo, ou redirixe ese sufixo ao resolutor local ou usa o enderezo IP do dispositivo.

O descubrimento é unha capa aparte. mDNS e a difusión non cruzan un túnel encamiñado, así que un dispositivo pode ser accesible por enderezo mentres o seu nome segue invisible. Un reflector ou unha entrada DNS local resólveo; unha ruta non.

Cuarto, comproba se a outra máquina tamén está nunha VPN

Cando a máquina á que queres chegar tamén executa un cliente VPN, a túa sesión pode chegar mentres a súa resposta sae polo outro túnel. Iso produce unha conexión que se establece e logo se atasca, ou un intento de RDP e SSH que expira sen ningún erro pola túa parte. Revisa a táboa de rutas do outro host e a súa ruta predeterminada antes de culpar o teu cliente.

Comproba tamén o enderezo no que escoita o servizo. Un escoitante ligado só ao enderezo do túnel acepta conexións da VPN e réxeitaas da rede local, mesmo cando o encamiñamento é perfecto. Iso é configuración do servizo, non unha ruta de rede, e é habitual en interfaces de xestión que se pecharon ao enderezo da VPN.

Mantén unha ruta de xestión que non dependa do túnel: unha ruta estática que nomee a túa rede de orixe, outra interface conectada á rede local ou unha consola que evite o túnel por completo. Deseñar esa ruta despois de que caia a sesión é moito máis difícil que engadila antes da seguinte conexión.

Aplica a reparación que corresponde á comprobación que fallou

Se a táboa de rutas mostrou unha captura de media predeterminada, escolle túnel dividido cando a política o permita e unha ruta local fixada cando non. Se o enderezo resultou ser público, cambia a proba e o nome ao enderezo privado. Se o resolutor cambiou de mans, limita o sufixo local ou usa o enderezo. Se o outro host está nun túnel, arranxa a súa ruta de volta ou a vinculación do seu escoitante.

Cambia unha cousa e despois repite a mesma comprobación. Unha ruta engadida para a subrede equivocada, un sufixo de resolutor cun erro tipográfico e unha ruta fixada nunha interface que se renumera parecen todos o fallo orixinal. A repetición é o que separa unha reparación dunha casualidade.

Anota a ruta, o enderezo e o resolutor que funcionaban coa VPN conectada. A próxima reconexión cambiará polo menos un deles, e a nota converte a próxima avaría nunha comparación curta en lugar dunha investigación nova.