OpenVPN cae tras unha renovación DHCP: conserve a ruta do extremo

O túnel conéctase, despois unha renovación do arrendamento no enlace de acceso mátano, e o rexistro culpa un tempo de espera en lugar dunha ruta. Non cambiou nada na configuración da VPN, e esa é a pista: algo fóra dela si. Un evento DHCP reescribiu o enderezo ou a pasarela, e a ruta de host que mantiña accesible o extremo do túnel agora apunta a un seguinte salto que xa non existe. Este é un problema de propiedade antes que un problema de encaminamento.

Compare o síntoma coas rutas medio predeterminadas

Con redirect-gateway def1, OpenVPN instala 0.0.0.0/1 e 128.0.0.0/1 en lugar de substituír a ruta predeterminada. Xuntas, esas dúas cobren todo o espazo de enderezos, e vencen a 0.0.0.0/0 só pola lonxitude do prefixo. Por iso calquera destino sen unha coincidencia máis específica entra no túnel.

O extremo necesita unha excepción. OpenVPN engade unha ruta de host cara ao enderezo do servidor a través da pasarela de acceso orixinal antes de que entren as medio predeterminadas, para que os paquetes encapsulados poidan saír. Cando esa excepción desaparece, ou conserva un seguinte salto que xa non existe, os propios paquetes exteriores do túnel coinciden cunha medio predeterminada e son enviados de volta ao túnel. O resultado é unha conexión que morre no seguinte keepalive ou aperto de mans, sen nada no rexistro que pareza un erro de encaminamento.

Confirme a forma da táboa antes de tocar calquera outra cousa. ip route show debería listar ambas as metades máis unha ruta de host para o enderezo do servidor; cando falta a ruta de host, o resto da investigación ten un punto de partida obvio.

Por que gañan as medio predeterminadas sen cambiar a métrica

Unha métrica máis baixa non vence un prefixo máis longo. As rutas /1 gañan porque o núcleo primeiro fai coincidir a ruta máis específica, así que subir unha métrica na ruta predeterminada non cambia nada sobre onde vai o tráfico destinado ao túnel. Perseguir métricas é o desvío máis común neste diagnóstico.

Comprobe a selección con ip route get 203.0.113.10, substituíndo o enderezo real do servidor. A resposta nomea a interface e o seguinte salto que o núcleo usaría realmente, o que é máis informativo que ler unha táboa e razoar sobre ela.

Execute ese comando antes de que arranque o túnel, mentres está activo e despois do evento de arrendamento. Tres respostas dun só comando, e o punto de diverxencia faise visible.

Tome tres instantáneas, non unha

Recolla o enderezo de acceso, a pasarela de acceso, o destino do extremo, a ruta seleccionada e calquera regra de política en tres momentos: despois de configurar o enlace de acceso, despois de que se conecte a VPN e despois do evento de arrendamento ou do operador. Cada instantánea é un puñado de comandos, e só significan algo xuntas. Unha única instantánea posterior ao fallo rexistra o estado en lugar da transición. Escriba os comandos nun pequeno script para que cada instantánea se tome da mesma maneira.

Garde as instantáneas nun só ficheiro con marcas de tempo, porque a pregunta interesante despois é a orde. Chegou o evento DHCP antes ou despois de que OpenVPN refrescase a súa ruta? A resposta decide quen ten que arranxalo. Unha marca de tempo dun reloxo equivocado é peor que ningunha, así que tómea do host que posúe a táboa de encaminamento.

Cando o extremo está configurado como un nome en lugar dun enderezo, resólvao tamén en cada instantánea. Un cambio de DNS no enlace de acceso pode mover o extremo sen que se toque ningunha ruta.

Decida que compoñente refresca a excepción

Nun sistema dhcpcd, os ganchos execútanse desde o directorio de ganchos e desde o gancho de saída, e o modo xestor difire en alcance do modo por interface. Faga o que faga o gancho, ten que ser idempotente, porque as renovacións poden chegar en refachos.

O propietario fiable é a integración que xa coñece ambos os lados: un xestor de rede que administra a conexión VPN, ou unha unidade ordenada despois de que suba o enlace de acceso. Unha ruta estática engadida por un gancho funciona ata o seguinte cambio de pasarela, e logo falla exactamente da mesma maneira. Se usa un gancho, faga que lea a pasarela actual en tempo de execución en lugar de codificar a que viu hoxe.

Rexistre o propietario dentro da configuración. A seguinte persoa que depure unha reconexión necesita saber que un gancho, non a VPN, é responsable da ruta de excepción.

Probe o ciclo de vida, non só a reconexión

Force unha renovación con dhcpcd -n eth0 ou liberando e renovando o arrendamento, e despois comprobe ip route get de novo para o extremo. Fágao dúas veces, porque a segunda pasada atrapa ganchos que engaden rutas duplicadas. Despois reinicie, porque a persistencia é unha propiedade distinta da corrección.

Un túnel que sobrevive a unha renovación e a un reinicio ten propietario e unha excepción que funciona. O que só sobrevive a un reinicio manual non ten ningunha das dúas, e fallará no seguinte evento que non poida programar.