A IP WAN cambiou e o túnel caeu: as comprobacións por orde

O túnel cae, o router rexistra unha reconexión e nada na LAN se moveu. Un novo enderezo WAN invalida a conexión exterior sen cambiar nada dentro: o enderezo de orixe do cliente cambiou, o estado NAT antigo apunta a unha orixe que xa non existe e o par remoto pode seguir enviando ao enderezo anterior. A recuperación é un comportamento normal, e a pregunta útil é que estado non se actualizou.

Nomee o evento antes de ler o rexistro

Comprobe que ocorreu realmente na capa de acceso. Unha renovación do arrendamento do ISP é un evento. Unha sesión PPPoE que se reconectou é outro. Un módem de fibra que se reiniciou, ou unha conmutación por erro de WAN dunha conexión a outra, cambia o enderezo exterior ou a súa ruta dunha terceira forma. Non son o mesmo evento e non deixan o mesmo residuo.

Unha liña de reconexión no rexistro do VPN tampouco é proba dun cambio de WAN. Un tempo de espera por inactividade, un intervalo de reautenticación e a detección de par morto producen reconexións sen ningún cambio de enderezo. Compare as marcas de tempo do rexistro de acceso co rexistro do VPN antes de concluír algo, e manteña a xanela de comparación abonda longa para atrapar un cambio que ocorreu durante a noite.

O roaming e a reconexión son protocolos distintos

WireGuard ten roaming autenticado integrado no protocolo: cando un par recibe un paquete autenticado correctamente desde un novo enderezo de orixe, actualiza o punto final dese par. O inicio rápido de WireGuard describe a configuración do par que fai posible isto, e por iso un cliente nun enderezo cambiante a miúdo recupérase sen un reinicio visible.

OpenVPN compórtase de forma distinta por defecto. Unha sesión UDP pode rematar e reconectarse, e o comportamento opcional float permite que un par autenticado continúe desde un novo enderezo onde a configuración o permite. Os túneles baseados en TCP son máis estritos, porque a propia conexión está ligada ao par de enderezos. Esa diferenza decide se a recuperación parece invisible ou se anuncia no rexistro cada vez.

Ningún dos dous comportamentos di nada sobre as aplicacións de dentro. Un túnel recuperado non restaura unha sesión TCP que o par xa consideraba morta.

Estado que o túnel non posúe

O estado de tradución e de encamiñamento sobrevive á reconexión de formas que sorprenden. Unha entrada de conntrack creada para a orixe antiga mantén a ruta de resposta ancorada a un enderezo que xa non existe, e caduca segundo o seu propio calendario, non cando o túnel volveu. Reiniciar o servizo do túnel non acurta esa espera, así que unha ligazón reparada aínda pode parecer rota durante un tempo.

As rutas e as regras de política poden referenciar a pasarela ou a interface antigas. Un conxunto de regras que era correcto antes dun cambio de WAN pode apuntar a un dispositivo que agora está caído, o que produce un túnel que informa que está conectado e tráfico que non vai a ningures. O DNS dinámico para un servidor que aloxa é un problema distinto do dun cliente que obtén unha nova orixe. O rexistro debe actualizarse para que os clientes remotos o atopen, e ningunha configuración do lado do cliente compensa un enderezo que a tradución augas arriba non reenviará.

Ordene as comprobacións de fóra cara a dentro

A orde seguinte vai da conexión exterior cara a dentro, e deterse no primeiro paso que falla é o que a fai útil: cada pasada descarta a capa de enriba. Manteña esa orde mesmo cando a avaría pareza obvia.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

O primeiro comando mostra o punto final actual e a idade da aperta de mans de cada par. O segundo e o terceiro mostran se a interface exterior e a ruta ao punto final seguen tendo sentido. A conta de conntrack é unha comprobación groseira do estado que queda do enderezo anterior, e o rexistro do sistema é onde se anota o motivo da reconexión.

Despois probe desde un cliente da LAN en lugar de desde o router. Un ping orixinado polo propio router usa unha ruta distinta do tráfico reenviado, así que un ping correcto desde o router demostra que o túnel existe e nada sobre a accesibilidade do cliente.

Decida o comportamento esperado e escríbao

Reconectarse é o comportamento correcto para a maioría dos despregamentos, así que o obxectivo non é evitalo. Decida en cambio que debe pasar co tráfico durante o oco: deterlo, retelo ou pasar a outra ruta. Esa decisión pertence á devasa e á política de encamiñamento, non ao perfil do VPN.

Rexistre os eventos de acceso e as horas de reconexión xuntos durante unha semana. Os cambios repetidos sen un evento de acceso correspondente apuntan ao servizo de acceso, e substituír o perfil do VPN non arranxará unha ligazón que non deixa de renegociar. Un só par de entradas no mesmo minuto resolve a cuestión para ese incidente e dá unha liña base ao seguinte.