Por que a túa VPN de Windows mata a impresora local e como evitalo

Conecta a VPN e a impresora desaparece, o recurso compartido do NAS deixa de abrirse e unha sesión de Escritorio remoto cara ao equipo de ao lado esgótase. Non se rompeu nada. O cliente engadiu unha ruta predeterminada e agora posúe cada destino que o portátil pode nomear, incluídos os que están a tres metros. Ese é todo o mecanismo, e chamarlle fallo da VPN é o que converte unha corrección dunha liña nun caso de soporte.

Le primeiro a táboa de rutas

Antes de cambiar nada, captura a táboa IPv4 con route print -4 e garda a saída. Conecta, volve capturar e compara as liñas 0.0.0.0: a ruta predeterminada activa nomea unha interface, e se esa interface é o túnel, a impresión e a navegación locais envíanse primeiro á oficina.

O número de interface da segunda columna é ao que unha ruta persistente terá que referirse máis tarde, así que anótao mentres o túnel está activo. Tamén é o valor que cambia cando se recrea o adaptador, e por iso as rutas fixadas a el poden sobrevivir en silencio á súa utilidade.

Elimina a ruta predeterminada, de tres maneiras

Nun perfil integrado de Windows o control é unha caixa de verificación. Abre as propiedades da conexión, IPv4, logo Avanzado, e desmarca Use default gateway on remote network; a aplicación Configuración máis recente esconde o mesmo diálogo unha capa máis abaixo. Desde unha consola elevada o mesmo cambio é un cmdlet:

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

Un perfil OpenVPN funciona doutro xeito, e por iso o seu comportamento confunde a quen espera unha caixa de verificación. A súa directiva redirect-gateway def1 non substitúe en absoluto a ruta predeterminada; instala dúas rutas de medio rango, 0.0.0.0/1 e 128.0.0.0/1, que xuntas gañan á predeterminada sen borrala. Como a predeterminada orixinal sobrevive, engadir un prefixo apuntado a net_gateway devolve só ese prefixo ao router local. Ese detalle explica por que a corrección para un perfil def1 é unha ruta de prefixo e non unha caixa que ninguén atopa.

Volve engadir só o que pertence ao traballo

Coa ruta predeterminada fóra, o túnel non transporta nada, así que os prefixos de traballo deben nomearse explicitamente. O cmdlet que liga un prefixo á conexión é máis seguro que unha ruta persistente, porque só se instala mentres esa conexión está activa e non depende dun número de interface:

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

O enfoque máis antigo aínda funciona e aínda está en todas as listas de comprobación: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, co índice de interface e o enderezo de pasarela propios do túnel. Persiste entre reinicios, que é o propósito e tamén o perigo, xa que o índice pode pertencer a outra cousa no seguinte arranque.

As métricas deciden o resto. Se tanto o adaptador físico como o do túnel reclaman unha ruta para o mesmo prefixo, gaña a métrica máis baixa, e subir a métrica do túnel é un control lexítimo do lado do cliente e non un truco.

Cando o servidor decide por ti

Un cliente que ignora a túa caixa de verificación normalmente está a obedecer unha política. Os perfís de Cisco levan un axuste Allow Local LAN Access, e un headend pode empurrar unha política tunnel-all que anula o que o cliente preferiría; nun despregamento de túnel obrigatorio non hai ningún conmutador local que cambiar. Le o rexistro do cliente para as rutas e liñas de política empurradas en vez de volver comprobar o mesmo diálogo.

Despois mira a resolución de nomes, que é un conmutador separado do encamiñamento. Un túnel dividido aínda pode recibir un resolvedor interno e un sufixo de busca, así que un dispositivo local é alcanzable por enderezo e imposible de atopar por nome ata que o lado DNS tamén estea arranxado.

Os solapamentos son un problema distinto

Se a LAN da casa e a LAN da oficina comparten un prefixo como 192.168.0.0/24, ningunha ruta pode distinguilas. Cada paquete desa faixa ten un só resultado de busca, e a corrección é renumerar un lado ou chegar á oficina mediante un enderezo traducido do pool. Engadir rutas máis específicas só move que metade da rede se rompe.

Remata cunha verificación en lugar de cinco: conecta e despois executa tracert contra un host interno e un público. O primeiro salto debería diferir, e se non o fai, a división non está en marcha, diga o que diga o cliente. Despois volve conectar unha vez e repite, porque as rutas empurradas volven con cada sesión.