Superviseu una VPN del router sense confiar en un sol llum d'estat

La pàgina d'estat diu connectat, el llum és verd i l'oficina no pot arribar al servidor de fitxers. Un d'aquests fets tracta del túnel i l'altre del camí que el travessa. Supervisar tots dos és la diferència entre una alerta que podeu atendre i una que apreneu a ignorar.

Cinc comprovacions, en ordre, des del parell cap a fora.

Comprovació 1: estat del parell o de l'associació

Cada protocol exposa el seu propi estat. WireGuard mostra l'últim handshake i els comptadors de transferència per parell mitjançant wg show. OpenVPN escriu l'estat de la sessió al seu fitxer d'estat o a la interfície de gestió, i IPsec exposa les associacions de seguretat amb eines com ipsec statusall. El parany és llegir una marca de temps com un veredicte: un parell WireGuard inactiu que no té res a enviar no farà un handshake recent, i això no és una caiguda.

Compareu la marca de temps amb el trànsit esperat i la configuració de keepalive abans d'avisar algú.

Comprovació 2: la ruta seleccionada

Una interfície de túnel pot existir mentre no hi encamina res. Reviseu la taula d'encaminament per a la destinació que us importa, no per a la subxarxa pròpia del túnel. Si el prefix falta o apunta a un altre lloc, l'estat del parell és irrellevant.

Aquesta comprovació detecta la fallada que un llum d'estat no mostra mai.

Una segona comprovació útil també compara l'adreça d'origen. ip route get 10.20.5.10 retorna el següent salt, la interfície i l'origen preferit, i un origen equivocat n'hi ha prou per trencar el trànsit de tornada a l'extrem remot. Anoteu la tripleta esperada una vegada i alerteu quan canviï qualsevol element. Aquesta sola línia detecta canvis de NAT, inestabilitats de la interfície i errors d'encaminament per política.

Comprovació 3: un camí d'aplicació permès

Proveu alguna cosa representativa del requisit real. Un ping originat al router surt de l'adreça i la política del mateix router, que poden diferir del trànsit LAN reenviat, i molts amfitrions limiten l'ICMP. Si el requisit és un servei privat, proveu aquest servei al seu port real.

Mantingueu el volum de la prova modest. Un bucle de supervisió no ha de convertir-se en el trànsit que mesura.

Comprovació 4: què va canviar i quan

Correlacioneu canvis de WAN, renegociacions de claus, retirades de rutes i fallades d'aplicacions en una sola línia temporal. Distingiu una fallada del túnel d'una ruta de reserva que restaura en silenci l'accés normal a internet, perquè totes dues produeixen informes d'usuari idèntics i diagnòstics oposats. Els errors de zona horària invertiran l'ordre, així que normalitzeu abans de comparar. La línia temporal és el que converteix quatre comprovacions en una causa.

Conserveu els registres de les transicions, no de la càrrega útil.

Comprovació 5: l'alerta ha de nomenar el límit

Una alerta que diu VPN caiguda envia algú al lloc equivocat la meitat de les vegades. Una que diu handshake del parell obsolet des de fa dotze minuts, ruta a 10.20.0.0/16 absent o prova al port 445 fallida assenyala una comprovació concreta.

Conserveu comptadors operatius en lloc de navegar per càrregues útils. Els comptadors responen la pregunta de supervisió sense recollir contingut que no necessiteu.

I deixeu que la política de commutació decideixi què passa després. La supervisió ha d'identificar quin límit ha fallat, no autoritzar una exempció àmplia cada vegada que falla una prova. El manual d'OpenVPN 2.6 documenta el fitxer d'estat i la interfície de gestió que fan que la primera comprovació sigui programable.