Per què la teva VPN de Windows mata la impressora local i com aturar-ho

Connecta la VPN i la impressora desapareix, el recurs compartit del NAS deixa d’obrir-se i una sessió d’Escriptori remot cap a la màquina del costat pateix un temps d’espera esgotat. No s’ha trencat res. El client ha afegit una ruta per defecte i ara posseeix cada destinació que l’ordinador pot anomenar, incloses les que són a tres metres. Aquest és tot el mecanisme, i anomenar-ho una fallada de la VPN és el que converteix una solució d’una línia en un cas de suport.

Llegeix primer la taula de rutes

Abans de canviar res, captura la taula IPv4 amb route print -4 i conserva la sortida. Connecta, torna a capturar i compara les línies 0.0.0.0: la ruta per defecte activa anomena una interfície, i si aquesta interfície és el túnel, la impressió i la navegació locals s’envien primer a l’oficina.

El número d’interfície de la segona columna és el que una ruta persistent haurà de referenciar més tard, així que anota’l mentre el túnel està actiu. També és el valor que canvia quan l’adaptador es recrea, i per això les rutes fixades a ell poden sobreviure silenciosament a la seva utilitat.

Elimina la ruta per defecte, de tres maneres

En un perfil de Windows integrat el control és una casella de verificació. Obre les propietats de la connexió, IPv4, després Avançat, i desmarca Use default gateway on remote network ; l’aplicació Configuració més nova amaga el mateix diàleg una capa més avall. Des d’un símbol del sistema elevat el mateix canvi és un cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Un OpenVPN perfil funciona diferent, i per això el seu comportament confon qui espera una casella de verificació. La seva redirect-gateway def1 directiva no substitueix gens la ruta per defecte; instal·la dues rutes de mig rang, 0.0.0.0/1 i 128.0.0.0/1, que juntes guanyen la ruta per defecte sense esborrar-la. Com que la ruta per defecte original sobreviu, afegir un prefix apuntat a net_gateway retorna només aquest prefix al router local. Aquest detall explica per què la solució per a un perfil def1 és una ruta de prefix i no una casella que ningú no troba.

Torna a afegir només el que és de la feina

Amb la ruta per defecte fora, el túnel no transporta res, així que els prefixos de feina s’han de nomenar explícitament. El cmdlet que lliga un prefix a la connexió és més segur que una ruta persistent, perquè només s’instal·la mentre aquesta connexió és activa i no depèn d’un número d’interfície:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

L’enfocament més antic encara funciona i encara és a totes les llistes de comprovació: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, amb l’índex d’interfície i l’adreça de passarel·la propis del túnel. Persisteix entre reinicis, que és el propòsit i també el perill, ja que l’índex pot pertànyer a una altra cosa en la següent arrencada.

Les mètriques decideixen la resta. Si tant l’adaptador físic com el del túnel reclamen una ruta per al mateix prefix, guanya la mètrica més baixa, i apujar la mètrica del túnel és un control legítim del costat del client i no un pedaç.

Quan el servidor decideix per tu

Un client que ignora la teva casella de verificació normalment obeeix una política. Els perfils de Cisco porten un paràmetre Allow Local LAN Access, i un headend pot empènyer una política tunnel-all que anul·la el que el client preferiria; en un desplegament de túnel obligatori no hi ha cap commutador local per canviar. Llegeix el registre del client per les rutes i línies de política empenyades en lloc de tornar a comprovar el mateix diàleg.

Després mira la resolució de noms, que és un commutador separat de l’encaminament. Un túnel dividit encara pot rebre un resolutor intern i un sufix de cerca, així que un dispositiu local és accessible per adreça i no es pot trobar pel nom fins que el costat DNS també estigui arreglat.

Els solapaments són un problema diferent

Si la LAN de casa i la LAN de l’oficina comparteixen un prefix com ara 192.168.0.0/24, cap ruta no les pot distingir. Cada paquet d’aquest rang té un sol resultat de consulta, i la solució és renumerar un costat o arribar a l’oficina mitjançant una adreça traduïda del pool. Afegir rutes més específiques només mou quina meitat de la xarxa es trenca.

Acaba amb una verificació en lloc de cinc: connecta i després executa tracert contra un amfitrió intern i un de públic. El primer salt hauria de diferir, i si no ho fa, la divisió no està en marxa, digui el que digui el client. Després torna a connectar-te un cop i repeteix, perquè les rutes empenyades tornen a cada sessió.