El VPN bloqueja la LAN local a Windows: ruta o política del client?
L'accés a la LAN local a Windows es trenca per dues raons diferents: una ruta que falta o una política de passarel·la que descarta la subxarxa. Tres comprovacions diuen quina és.
Una impressora, un NAS o una màquina de desenvolupament al vostre propi escriptori deixen de respondre en el moment en què es connecta el VPN de la feina. De vegades una comanda de ruta ho arregla en segons; de vegades la mateixa ruta és correcta i els paquets desapareixen igualment, cosa que vol dir que mireu un problema diferent amb un símptoma semblant. La decisió es redueix a tres preguntes, i fer-les en l'ordre equivocat és per què la gent passa una nit sencera esborrant i tornant a afegir rutes.
Tres preguntes abans de qualsevol comanda
Primera: hi ha una entrada per al prefix local, i apunta a l'adaptador físic? Segona: el client rep del passarel·la un permís o una denegació de xarxa local en connectar-se? Tercera: només necessiteu accés de sortida a la LAN, o hi ha d'haver també alguna cosa a internet que arribi a un servei que corre a la vostra màquina?
La primera pregunta separa una fallada d'encaminament d'una fallada de filtratge. La segona us diu si una correcció d'encaminament pot funcionar. La tercera canvia la reparació: una ruta arregla el trànsit de sortida, mentre que un servei d'entrada inabastable sol ser un problema d'enllaç del oient i de camí de tornada que una ruta empitjora.
| 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 primera: ruta, filtre o nom
Llegiu la taula abans d'afegir-hi res. L'índex d'interfície importa, perquè cada comanda de ruta d'abaix hi va ancorada:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricUna subxarxa connectada directament normalment conserva una ruta enllaçada fins i tot amb el túnel actiu, així que una entrada pot existir i el trànsit pot fallar igualment. Aquesta combinació és la signatura d'un filtre que s'executa després de l'encaminament, i és el cas en què una segona ruta més específica no canvia absolutament res.
Proveu per adreça i per nom per separat. Si ping 192.168.1.50 respon i net view 192.168.1.50 no, la taula d'encaminament mai va ser el problema: el túnel va canviar el resolutor i el nom local ja no es resol. Afegir una ruta per això és feina perduda.
Pregunta segona: el passarel·la permet l'accés a la LAN local?
Un client comercial instal·la més que rutes. Rep una política en connectar-se, i aquesta política pot incloure un permís explícit de xarxa local. En desplegaments Cisco IPsec la política de grup porta la configuració de split-tunneling i un indicador separat d'accés a la LAN local; la casella del client és una sol·licitud que el passarel·la pot refusar. A AnyConnect el perfil controla les llistes d'inclusió i exclusió del split i el mateix permís. A Windows RRAS els equivalents són l'opció de passarel·la predeterminada al perfil més les rutes estàtiques que assigna el servidor.
Quan l'indicador està desactivat, el comportament documentat és que el client bloqueja el trànsit a la subxarxa connectada directament tot i que existeixi una ruta vàlida i més específica. És també per això que les rutes que el client no posseeix poden desaparèixer segons després d'afegir-les: el client reconstrueix l'estat que se li va dir que construís, no lluita contra vós.
El registre del client enregistra la decisió en connectar-se, i llegir-lo és més ràpid que qualsevol experiment a la màquina. Si el registre diu que l'accés local està bloquejat, atureu-vos: cap correcció de línia de comandes hi sobreviu, i els únics camins que queden són un canvi de política, arribar al recurs pel túnel, o contenir el client en una màquina virtual i deixar l'amfitrió a la xarxa local.
Pregunta tercera: quina direcció necessiteu?
El trànsit de sortida cap a un dispositiu proper és una qüestió d'encaminament. Apunteu el prefix de la LAN al passarel·la local amb una mètrica prou baixa per superar la ruta predeterminada del 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 -pLa segona forma fixa un sol dispositiu, que és el que voleu quan una adreça és tot el requisit. L'equivalent netsh enregistra la mateixa decisió pel nom d'interfície en lloc de l'índex:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentLes comandes de ruta fallen amb El paràmetre no és correcte quan l'adreça i la màscara no concorden, per exemple una adreça d'amfitrió amb una màscara /24. Feu servir l'adreça de xarxa per a una ruta de subxarxa i una màscara d'amfitrió per a un sol amfitrió.
L'entrada és diferent. Un servidor VNC o SSH a la mateixa màquina esdevé inabastable quan les respostes a una connexió entrant surten pel passarel·la del VPN i no tornen mai. Comproveu què escolta el servei abans de tocar les rutes:
netstat -ano | findstr :5900Un oient lligat a una adreça concreta no respondrà a l'altra interfície. Lligar-lo a totes les interfícies és una decisió deliberada, presa juntament amb una regla de tallafocs limitada a la xarxa en què confieu. Només després d'això la reparació de la ruta restaura el camí de tornada.
Apliqueu el canvi més petit que encaixi
L'altre moviment habitual és desmarcar «Utilitza la passarel·la predeterminada a la xarxa remota» a les propietats avançades d'IPv4. Manté el trànsit d'internet local, però fa dues coses alhora: el VPN deixa de ser el camí predeterminat, i el client deixa de rebre rutes per a la xarxa remota, inclòs el multicast. Desmarqueu-ho i la LAN remota desapareix tret que el servidor empenyi els prefixos remots concrets que cada client necessita.
Aquesta asimetria decideix l'ordre de treball. Si el costat remot ha de romandre plenament abastable, empenyeu les subxarxes remotes des del servidor i deixeu la predeterminada local tranquil·la. Si no podeu canviar el servidor, afegiu una ruta persistent al prefix remot a través de l'adreça que el túnel va assignar, i comproveu amb route print que el prefix apunta a la interfície del VPN mentre la predeterminada encara apunta al passarel·la físic.
Després confirmeu que la reparació sobreviu a una reconnexió, perquè les rutes no persistents moren amb l'adaptador i un script que s'executi després de cada connexió és el lloc honest per a elles. Proveu un dispositiu local i un recurs remot a la mateixa sessió, desconnecteu, reconnecteu i torneu a provar. Si el dispositiu local encara falla mentre la ruta sembla correcta, torneu a la pregunta segona: el client està filtrant, i la resposta és un canvi de política i no una segona ruta competidora.