Por que unha subrede segue evitando a ruta predeterminada da VPN

Cambias a VPN a túnel completo, a maioría do tráfico obedece, e entón un enderezo responde directamente — unha impresora, un NAS, un host de salto en 10.x. A lectura obvia é que o túnel ten unha fuga, así que baixas a métrica da ruta predeterminada e non cambia nada. Ese intento fallido é a pista: unha ruta predeterminada é un recurso de reserva, non un veredicto. A consulta de encamiñamento toma o prefixo coincidente máis longo antes de comparar sequera métricas, así que unha /24 segue gañando a unha /0 fagas o que fagas co número que poñas en calquera delas. Unha vez claro esa orde, a fuga adoita ser unha ruta que alguén instalou a propósito, ou un prefixo que o cliente nunca pretendía cubrir.

Que promete realmente unha ruta predeterminada

0.0.0.0/0 coincide con calquera destino IPv4 con cero bits de especificidade. Existe para que un host acade calquera cousa que a súa táboa non describa mellor. Unha ruta a 192.168.1.0/24 leva 24 bits coincidentes, así que para 192.168.1.40 gaña antes de que ninguén compare métricas, distancia administrativa ou como queira que o cliente chame ao seu campo de prioridade. A mesma regra vale na FIB de Linux, na táboa de encamiñamento de Windows e na pila BSD detrás de macOS.

Nunha LAN normal ese comportamento é unha característica. A subrede local está conectada directamente, a impresora segue funcionando mentres o túnel leva a túa navegación, e nada está mal configurado. A pregunta que paga a pena non é por que ese enderezo vai directo, senón que prefixo de que táboa coincide con el e quen o puxo alí.

Medias rutas predeterminadas, ou por que a entrada predeterminada pode parecer intacta

O exemplo máis limpo é redirect-gateway def1 de OpenVPN. En lugar de borrar a túa ruta predeterminada e substituíla, engade 0.0.0.0/1 e 128.0.0.0/1. Xuntas, a parella cobre todo IPv4, cada prefixo é máis longo que /0, e ambas superan a ruta predeterminada do router deixándoa no seu sitio. Executa unha listaxe de rutas despois e a ruta predeterminada orixinal segue aí, segue apuntando á túa pasarela; simplemente nunca se escolle para destinos de internet.

O wg-quick de WireGuard chega ao mesmo resultado mediante encamiñamento por políticas. Con AllowedIPs cubrindo 0.0.0.0/0 crea a súa propia táboa, envía alí os paquetes marcados e engade unha regra que ignora o prefixo de lonxitude cero da táboa principal. A táboa principal conserva a súa entrada predeterminada, e as regras deciden que a táboa do túnel se consulta primeiro para o tráfico que posúe a interface.

Ambos deseños necesitan exactamente unha ruta fóra do túnel: unha ruta de host ao enderezo propio do servidor VPN a través da pasarela orixinal. Sen ela, o cliente intentaría levar os paquetes que constrúen o túnel dentro do túnel, e a conexión nunca se completaría. Unha ruta que non é de túnel na túa táboa é, por tanto, normal mesmo nun perfil estrito de túnel completo. As rutas que merecen cuestionarse son as que cobren destinos que de verdade che importan.

As métricas deciden empates, os prefixos deciden gañadores

As métricas só se comparan entre candidatos que coinciden igual de ben co destino. En Linux, ip route get 10.20.5.9 imprime o gañador xunto coa súa táboa, e ip route show table all lista os candidatos, incluíndo as medias rutas predeterminadas e calquera táboa á que apunte unha regra. En Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 devolve a ruta seleccionada e o enderezo de orixe, mentres que Get-NetRoute mostra a táboa en bruto — pero o custo efectivo é a métrica de ruta máis a métrica de interface, así que un adaptador lento pode perder un empate que parece gañar.

Tres casos cobren a maior parte do que verás:

• Mesmo destino, /24 contra /0: a /24 gaña por lonxitude de prefixo, digan o que digan as métricas.
• Mesmo destino, dúas /24 con métricas distintas: gaña a métrica efectiva máis baixa.
• Mesmo destino, dúas táboas, unha escollida por unha regra de política: a regra escolle primeiro a táboa, e a comparación de prefixos ocorre dentro dela.

O terceiro caso é onde acaban a maioría destes informes. Unha ip rule de Linux ou un filtro de tráfico VPN de Windows pode enviar tráfico a unha táboa que nunca tivo a ruta predeterminada do túnel, e a táboa principal parece perfecta todo o tempo.

Quen adoita ser dono da evasión

Comeza polo perfil, non pola táboa. As configuracións de túnel dividido e os axustes de VPN por aplicación deixan deliberadamente prefixos con nome fóra do túnel; un perfil de traballo que protexe unha subrede privada e deixa que a navegación xeral vaia directa compórtase como se deseñou, e anulalo rompe a política que debía aplicar. A guía de encamiñamento VPN de Microsoft traza a mesma liña entre tráfico forzado polo túnel e excepcións explícitas, o que a converte nunha comprobación cruzada útil antes de editar nada.

Despois busca restos. Unha ruta que apunta a unha interface que xa non existe, ou a un enderezo da rede anterior, aparece despois de que estacións de acoplamento, adaptadores USB e pontes de contedores vaian e veñan. Borrala unha vez non é o final: os perfís de conexión de NetworkManager, os ficheiros netplan e as rutas persistentes de Windows reinstálana na seguinte conexión ou arranque, así que atopa o ficheiro ou perfil que a posúe antes de editar nada.

Logo comproba IPv6 por separado. ip -6 route e Get-NetRoute -AddressFamily IPv6 manteñen estado separado, rutas predeterminadas separadas e comportamento de cliente separado. Unha auditoría só de IPv4 non di nada sobre un host de dobre pila que prefire en silencio unha ruta IPv6 nativa, e iso só pode facer que un cliente pareza de túnel dividido.

Confirma co fluxo real da aplicación

Anota o destino que a aplicación usa realmente e logo pregunta ao sistema pola ruta que tomaría desde o enderezo de orixe ao que se ata esa aplicación. ip route get 10.20.5.9 from 192.168.1.40 responde iso en Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 máis o enderezo local faino en Windows. Compara o resultado co que afirma o perfil. A páxina de IP pública dun navegador proba un destino cun protocolo e non di nada sobre o enderezo privado que iniciou a queixa.

Corrixe o obxecto máis estreito que explique a diferenza. Se a excepción está aprobada, anota o prefixo e déixao; se non, elimina a ruta ou engade unha ruta explícita máis estreita polo túnel en lugar de baixar a métrica da predeterminada. Baixar unha métrica non pode superar un prefixo máis longo, e editar a predeterminada mentres dúas rutas /1 posúen a ruta de internet tampouco cambia nada.

Logo reconecta o túnel e repite a mesma consulta. Os clientes reinstalan rutas en cada conexión, así que un cambio que só dura ata o seguinte handshake non está probado. Se a ruta segue diverxendo, os sospeitosos restantes son unha regra de política, unha segunda táboa ou un filtro do lado do cliente: non a ruta predeterminada.

• Nomea o destino e o enderezo de orixe que a aplicación usa realmente.
• Mostra a ruta gañadora con ip route get ou Find-NetRoute.
• Comproba se un par /1 ou unha táboa de política posúe a ruta de internet.
• Enumera cada prefixo máis longo que /0 que coincida co destino.
• Repite a comprobación de IPv6 por separado.
• Rastrexa a ruta supervivente ata o ficheiro, perfil ou filtro que a instala.
• Reconecta e volve executar a consulta antes de dala por corrixida.

Se os sete coinciden co perfil, o túnel fai exactamente o que estaba configurado para facer, e o arranxo pertence ao perfil e non a unha métrica.