Por que unha ruta VPN eliminada volve tras reconectar

Unha ruta que eliminaches a man volve tras a seguinte reconexión, e a táboa queda exactamente como estaba. Non é un fallo de encamiñamento: algo recrea a entrada desde a configuración ou desde unha acción do ciclo de vida da conexión. A maioría dos runbooks detéñense na táboa activa, por iso a eliminación parece funcionar un minuto e despois falla. Identifica o propietario, cambia iso e demóstrao nunha reconexión.

Quen instalou a ruta

Comeza por unha lista de candidatos en lugar dunha corrección. Un perfil de VPN pode levar as súas propias rutas, un servidor pode envialas ao conectar, un perfil do xestor de rede pode declaralas, unha unidade de arranque ou un script pode engadilas, e as implementacións de IPsec instalan rutas para os selectores de tráfico que negocian. As regras de encamiñamento por política tamén poden redirixir o tráfico por completo a outra táboa.

O momento en que aparecen sepáraas máis rápido que a arqueoloxía de configuración. Unha entrada que aparece no instante en que sobe a interface pertence ao cliente; unha que chega un segundo despois adoita vir dun push do servidor; unha que existe ao arrincar pertence á configuración gardada. Rexistra a táboa antes e despois dunha conexión, unha desconexión e un reinicio, e o patrón nomeará o propietario. Unha ruta que só volve cando se reinicia o servizo apunta a unha unidade e non á VPN.

Le a táboa antes de editarla

Mira a visión do propio núcleo en lugar dun ficheiro gardado. A columna de protocolo mostra que instalou cada entrada:

ip route show
ip route show table all
ip rule show

O campo de protocolo, a métrica e o número de táboa dícenche se estás a ver unha entrada estática, unha creada polo núcleo ou algo que engadiu un demonio. A lista de regras importa porque unha busca pode abandonar a táboa principal por completo, o que fai que unha edición alí sexa invisible para a aplicación que estás depurando. Le a liña de esquerda a dereita: destino, porta de enlace, dispositivo, protocolo e métrica.

Despois pregunta ao núcleo que ruta usaría realmente. Un enderezo protexido é unha sonda mellor ca unha pública:

ip route get 10.20.5.7

Cambia o propietario, non o síntoma

Unha vez coñecido o propietario, o cambio pertence a ese propietario. Retira a ruta do perfil do cliente, corrixe a ruta enviada no servidor ou edita a conexión do xestor de rede en lugar de engadir unha ruta persistente competidora que gañe por métrica. Dúas regras que loitan entre si producen unha táboa que ninguén poderá explicar despois.

Mantén a exclusión do extremo. Unha ruta de host que envía o enderezo público propio do servidor VPN a través da porta de enlace física é o que mantén fluíndo os paquetes exteriores do túnel; se a eliminas, o túnel intenta levalo a si mesmo. Nun perfil de túnel dividido, o mesmo coidado se aplica ás subredes locais que deben evitar o túnel.

Reconecta e verifica ambos os camiños

Reconecta e despois comproba ambos os destinos nunha soa pasada. O enderezo protexido e o extremo excluído responden a preguntas distintas:

ip route get 10.20.5.7
ip route get 198.51.100.20

A primeira debería resolverse pola interface do túnel e a segunda pola porta de enlace física. Se ambas se resolven polo túnel, falta a exclusión; se ningunha o fai, o cambio de perfil non surtiu efecto e estás a ver un propietario distinto do que pensabas.

Anota o propósito da ruta, o seu propietario e canto tempo debe vivir. Esa nota é o que impide que a seguinte persoa repita o mesmo ciclo de eliminar e reconectar.