Vixiar unha VPN do router sen confiar nunha soa luz de estado

A páxina de estado di conectado, a luz está verde e a oficina non chega ao servidor de ficheiros. Un deses feitos trata do túnel e o outro do camiño a través del. Vixiar ambos é a diferenza entre unha alerta sobre a que pode actuar e unha que aprende a ignorar.

Cinco comprobacións, en orde, desde o par cara a fóra.

Comprobación 1: estado do par ou da asociación

Cada protocolo expón o seu propio estado. WireGuard mostra o último handshake e os contadores de transferencia por par mediante wg show. OpenVPN escribe o estado da sesión no seu ficheiro de estado ou na interface de xestión, e IPsec expón as asociacións de seguridade mediante ferramentas como ipsec statusall. A trampa é ler unha marca de tempo como veredicto: un par de WireGuard inactivo sen nada que enviar non fará un handshake recente, e iso non é unha caída.

Compare a marca de tempo co tráfico esperado e a configuración de keepalive antes de avisar a alguén.

Comprobación 2: a ruta seleccionada

Unha interface de túnel pode existir mentres nada encamiña cara a ela. Revise a táboa de envío para o destino que lle importa, non para a subrede propia do túnel. Se o prefixo falta ou apunta a outro lugar, o estado do par é irrelevante.

Esa comprobación detecta o fallo que unha luz de estado nunca mostra.

Unha segunda comprobación útil tamén compara o enderezo de orixe. ip route get 10.20.5.10 devolve o seguinte salto, a interface e a orixe preferida, e unha orixe equivocada abonda para romper o tráfico de retorno no extremo remoto. Anote a tripla esperada unha vez e alerte cando cambie calquera elemento. Esa soa liña detecta cambios de NAT, inestabilidades da interface e erros de encamiñamento por política.

Comprobación 3: un camiño de aplicación permitido

Probe algo representativo do requisito real. Un ping orixinado no router sae do enderezo e da política do propio router, que poden diferir do tráfico LAN reenviado, e moitos equipos limitan ICMP. Se o requisito é un servizo privado, probe ese servizo no seu porto real.

Manteña o volume da proba modesto. Un bucle de vixilancia non debe converterse no tráfico que mide.

Comprobación 4: que cambiou e cando

Correlacione cambios de WAN, renovacións de chaves, retiradas de rutas e fallos de aplicacións nunha soa liña temporal. Distinga un fallo do túnel dunha ruta de reserva que restaura en silencio o acceso normal a internet, porque ambas producen informes de usuario idénticos e diagnósticos opostos. Os erros de fuso horario inverterán a orde, así que normalice antes de comparar. A liña temporal é o que converte catro comprobacións nunha causa.

Conserve os rexistros das transicións, non da carga útil.

Comprobación 5: a alerta debe nomear o límite

Unha alerta que di VPN caída envía a alguén ao lugar equivocado a metade das veces. Unha que di handshake do par obsoleto desde hai doce minutos, ruta a 10.20.0.0/16 ausente ou proba ao porto 445 fallida sinala unha comprobación concreta.

Manteña contadores operativos en lugar de navegar por cargas útiles. Os contadores responden a pregunta de vixilancia sen recoller contido que non necesita.

E deixe que a política de conmutación decida que ocorre despois. A vixilancia debe identificar que límite fallou, non autorizar unha omisión ampla cada vez que falla unha proba. O manual de OpenVPN 2.6 documenta o ficheiro de estado e a interface de xestión que fan que a primeira comprobación sexa programable.