O VPN bloquea a LAN local en Windows: ruta ou política do cliente?
O acceso á LAN local en Windows rompe por dúas razóns distintas: falta unha ruta ou unha política de pasarela que descarta a subrede. Tres comprobacións din cal.
Unha impresora, un NAS ou unha máquina de desenvolvemento no seu propio escritorio deixan de responder no momento en que se conecta o VPN do traballo. Ás veces un comando de ruta soluciónao en segundos; outras veces a mesma ruta é correcta e os paquetes desaparecen igualmente, o que significa que está ante un problema distinto cun síntoma parecido. A decisión redúcese a tres preguntas, e facelas na orde equivocada é a razón pola que a xente pasa unha noite enteira borrando e volvendo engadir rutas.
Tres preguntas antes de calquera comando
Primeira: hai unha entrada para o prefixo local e apunta ao adaptador físico? Segunda: recibe o cliente un permiso ou unha denegación de rede local da pasarela ao conectarse? Terceira: só necesita acceso de saída á LAN, ou algo en internet tamén debe chegar a un servizo que se executa na súa máquina?
A primeira pregunta separa un fallo de encamiñamento dun fallo de filtrado. A segunda di se se permite que unha corrección de ruta funcione. A terceira cambia a reparación: unha ruta arranxa o tráfico de saída, mentres que un servizo de entrada inalcanzable adoita ser un problema de ligazón do oínte e de camiño de volta que unha ruta empeora.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Pregunta primeira: ruta, filtro ou nome
Lea a táboa antes de engadir nada. O índice de interface importa, porque cada comando de ruta de abaixo está ancorado nel:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricUnha subrede conectada directamente adoita conservar unha ruta na ligazón mesmo co túnel activo, así que pode existir unha entrada e o tráfico pode fallar igualmente. Esa combinación é a sinatura dun filtro que se executa despois do encamiñamento, e é o caso en que unha segunda ruta máis específica non cambia absolutamente nada.
Probe por enderezo e por nome por separado. Se ping 192.168.1.50 responde e net view 192.168.1.50 non, a táboa de encamiñamento nunca foi o problema: o túnel cambiou o resolutor e o nome local xa non se resolve. Engadir unha ruta para iso é traballo perdido.
Pregunta segunda: permite a pasarela o acceso á LAN local?
Un cliente comercial instala máis que rutas. Recibe unha política ao conectarse, e esa política pode incluír un permiso explícito de rede local. En despregamentos Cisco IPsec a política de grupo leva o axuste de túnel dividido e un indicador separado de acceso á LAN local; a caixa do cliente é unha solicitude que a pasarela pode rexeitar. En AnyConnect o perfil controla as listas de inclusión e exclusión do túnel dividido e o mesmo permiso. En Windows RRAS os equivalentes son a opción de pasarela predeterminada no perfil máis as rutas estáticas que asigna o servidor.
Cando o indicador está desactivado, o comportamento documentado é que o cliente bloquea o tráfico á subrede conectada directamente aínda que exista unha ruta válida e máis específica. É tamén por iso que as rutas que o cliente non posúe poden desaparecer segundos despois de engadilas: o cliente reconstrúe o estado que se lle dixo que construíse, non loita contra vostede.
O rexistro do cliente anota a decisión ao conectarse, e lelo é máis rápido que calquera experimento na máquina. Se o rexistro di que o acceso local está bloqueado, detéñase: ningunha corrección de liña de comandos sobrevive a iso, e os únicos camiños que quedan son un cambio de política, chegar ao recurso polo túnel, ou encerrar o cliente nunha máquina virtual e deixar o anfitrión na rede local.
Pregunta terceira: que dirección necesita?
O tráfico de saída cara a un dispositivo próximo é unha cuestión de encamiñamento. Apunte o prefixo da LAN á pasarela local cunha métrica abondo baixa como para bater a ruta predeterminada do túnel:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pA segunda forma fixa un só dispositivo, que é o que quere cando un enderezo é todo o requisito. O equivalente netsh rexistra a mesma decisión por nome de interface en lugar de por índice:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentOs comandos de ruta fallan con O parámetro non é correcto cando o enderezo e a máscara non concordan, por exemplo un enderezo de host cunha máscara /24. Use o enderezo de rede para unha ruta de subrede e unha máscara de host para un só host.
A entrada é distinta. Un servidor VNC ou SSH na mesma máquina vólvese inalcanzable cando as respostas a unha conexión entrante saen pola pasarela do VPN e nunca regresan. Comprobe en que escoita o servizo antes de tocar as rutas:
netstat -ano | findstr :5900Un oínte ligado a un enderezo concreto non responderá na outra interface. Ligalo a todas as interfaces é unha decisión deliberada, tomada xunto cunha regra de devasa limitada á rede na que confía. Só despois diso a reparación da ruta restaura o camiño de volta.
Aplique o cambio máis pequeno que encaixe
O outro movemento habitual é desmarcar «Usar pasarela predeterminada na rede remota» nas propiedades avanzadas de IPv4. Mantén o tráfico de internet local, pero fai dúas cousas á vez: o VPN deixa de ser o camiño predeterminado e o cliente deixa de recibir rutas para a rede remota, incluído multicast. Desmárqueo e a LAN remota desaparece a non ser que o servidor empurre os prefixos remotos concretos que cada cliente necesita.
Esa asimetría decide a orde do traballo. Se o lado remoto debe seguir sendo plenamente alcanzable, empurre as subredes remotas desde o servidor e deixe en paz a predeterminada local. Se non pode cambiar o servidor, engada unha ruta persistente ao prefixo remoto a través do enderezo que asignou o túnel, e comprobe con route print que o prefixo apunta á interface do VPN mentres a predeterminada segue apuntando á pasarela física.
Logo confirme que a reparación sobrevive a unha reconexión, porque as rutas non persistentes morren co adaptador e un script que se execute despois de cada conexión é o lugar honesto para elas. Probe un dispositivo local e un recurso remoto na mesma sesión, desconecte, reconecte e probe outra vez. Se o dispositivo local segue fallando mentres a ruta parece correcta, volva á pregunta segunda: o cliente está filtrando, e a resposta é un cambio de política e non unha segunda ruta competidora.