Como distinguir as rutas inseridas pola VPN das estáticas en Linux

Un prefixo aparece no portátil cando o túnel se levanta, así que parece que o instalou a VPN. Pode que si, pero o mesmo resultado pode vir dun script de cliente que se executa ao conectar, dun perfil de conexión que enumera a subrede ou dunha ruta estática que estivo alí todo o tempo e só comezou a funcionar cando existiu a interface. Escoller o propietario equivocado significa que a ruta volve tras cada limpeza, e a seguinte persoa repite a mesma corrección. A secuencia seguinte separa os tres antes de cambiar nada.

Paso 1: nomee o mecanismo que instala prefixos

Distintos protocolos fornecen accesibilidade de distintas maneiras, e chamar a todo iso anuncio oculta a distinción. Un servidor OpenVPN empuxa unha directiva de ruta polo canal de control e o cliente instálaa salvo que un filtro pull a bloquee. Unha configuración de WireGuard enumera localmente os prefixos permitidos, que o cliente usa tanto para o encamiñamento de claves criptográficas como para as rutas que engade. Un túnel IPsec acorda selectores de tráfico co par, e o núcleo instala rutas a partir deses selectores.

Identifique cal deses usa o seu túnel antes de ler calquera táboa. Unha ruta empuxada ao conectar non é un anuncio dun protocolo de encamiñamento e non promete que o prefixo sexa accesible detrás do extremo remoto. Anote o mecanismo xunto ao prefixo, porque decide onde corresponde a corrección.

Paso 2: compare a táboa ao longo dunha conexión

Garde a táboa principal co túnel baixado, súbao, gárdea outra vez e compare as dúas capturas. Todo o que apareceu pertence ao ciclo de vida da conexión, e todo o que quedou pertence á configuración local.

Captúrea con ip route show table main > /tmp/route-down.txt, concéctese e capture de novo. Faga o mesmo con ip -6 route se o sitio usa IPv6, porque un prefixo ausente alí produce fallos que parecen non ter relación co encamiñamento.

Paso 3: lea a métrica, non só a presenza

Dúas entradas para o mesmo prefixo poden coexistir, e o núcleo escolle a métrica máis baixa. Unha ruta estática con métrica 50 seguirá gañando a unha ruta empuxada con 100 aínda que ambas sexan visibles, por iso «a ruta está aí» e «o tráfico úsaa» son afirmacións distintas.

Pregunte ao núcleo directamente con ip route get 10.20.5.7 e lea a interface que informa. Se o tráfico sae polo adaptador físico mentres unha ruta do túnel está na táboa, explícao a métrica ou a lonxitude do prefixo, non o cliente VPN. Repita a consulta para un host que sabe que está detrás do túnel e para un que sabe que non, e a diferenza mostra se a división se comporta como se pretende.

Paso 4: atope as entradas que sobreviven ao túnel

As rutas estáticas sobreviven a unha desconexión por deseño, e de aí veñen as entradas obsoletas. Unha ruta persistente que apunta a unha interface que xa non existe pode tragar unha subrede en silencio, e unha que apunta a un nome de interface reutilizado pode enviar tráfico privado pola porta equivocada tras un reinicio.

Revise o lado persistente no lugar que usa a súa distribución, xa sexa unha unidade de systemd-networkd, un perfil de NetworkManager ou un script no directorio up do cliente. Corrixir a táboa viva con ip route del só aguanta ata a próxima conexión. Trate ese borrado como unha proba da hipótese e non como a reparación.

Onde o extremo remoto fornece a cobertura equivocada, expóñao ao operador en lugar de filtrar todo. Descartar todos os axustes empuxados tamén descarta o DNS e a política de túnel dividido dos que depende o perfil.

Paso 5: confirme o camiño de volta antes de culpar o cliente

Para un sitio a sitio ou unha subrede detrás do túnel, o lado remoto necesita unha ruta de volta ao enderezo do seu cliente e o reenvío activado na pasarela. Un camiño de ida parece exactamente un fallo de encamiñamento do cliente, salvo que o handshake e o paquete saínte teñen éxito ambos.

O filtrado de ruta inversa engade unha segunda trampa nas pasarelas Linux. Unha resposta que chega por unha interface distinta da que a ruta predí é descartada polo modo estrito, e as rutas asimétricas por dous provedores desencadéano de forma fiable. Os contadores de descarte na pasarela, non no cliente, dinnos se o filtrado é a causa.

Paso 6: probe o recurso, non o ping

Unha vez que a ruta elixida é correcta, abra o recurso real e confirme o tráfico de volta. Unha resposta de ping demostra o camiño nunha dirección e nada sobre o servizo, e un servizo que responde nunha conexión en caché demostra aínda menos.

Despois repita toda a comprobación tras reconectar. O valor da secuencia é que predí que fará a próxima conexión, por iso tanto a comparación como a métrica pertencen ao tícket.