Keepalive no és una reconnexió: tria segons la fallada que tens

Els keepalives i les reconnexions es configuren alhora i resolen problemes diferents, i per això ajustar-ne un poques vegades arregla l'altre. Un keepalive envia trànsit petit per mantenir viva una entrada d'estat o per notar que un igual ha deixat de respondre. Una reconnexió enderroca el que està trencat i torna a construir la relació, incloent-hi claus, adreces i rutes. Trieu el mecanisme que encaixa amb la fallada, no el que ja coneixeu el botó. Dues preguntes ho decideixen: el camí és mort o alguna cosa entre els iguals l'ha oblidat?

Quan el problema és el mapatge

Un túnel que mor només després de minuts de silenci normalment perd una entrada de traducció, no un igual. El PersistentKeepalive de WireGuard existeix per a l'estat de NAT i tallafocs, i les notes del mateix projecte el presenten així, no com una comprovació de salut. Un interval de poques desenes de segons manté l'entrada calenta, mentre que un paquet cada segon és una decisió de bateria i no de fiabilitat. OpenVPN arriba al mateix lloc mitjançant ping i ping-restart , que primer noten el silenci i després hi actuen.

Aquests paràmetres tampoc són intercanviables entre protocols. Una política de parell mort d'IKEv2, un temporitzador ping d'OpenVPN i un keepalive de WireGuard responen la mateixa pregunta amb tres sintaxis i tres valors per defecte diferents, així que copiar un número entre ells és una endevinalla disfressada d'ajust.

Quan la relació ha desaparegut

Si l'igual canvia d'adreça, la credencial caduca o l'extrem remot es reinicia, els paquets petits no són la reparació. La reconnexió ha de reconstruir l'estat : obtenir una adreça, reinstal·lar les rutes, renegociar les claus i, en alguns desplegaments, reautenticar un usuari.

Els clients que es reconnecten sense supervisió tenen un certificat o un secret desat. Un client que preguntaria a una persona falla justament quan no n'hi ha cap, que és l'escenari on la reconnexió importava. Això és una decisió de disseny presa mesos abans, no un paràmetre que pugueu canviar durant una caiguda.

Què no demostra cap dels dos

Un túnel pot estar reconnectat, amb claus i rutes, mentre el servei que hi ha darrere està caigut, i un keepalive pot mantenir obert un mapatge per a una sessió el servidor de la qual va desaparèixer fa hores. Tots dos mecanismes poden informar d'èxit mentre allò que realment us importa no està disponible.

Per això la prova acaba en una petició real. Envieu alguna cosa pel túnel després de l'interval que us importa i després provoqueu per separat la fallada per a la qual heu dissenyat: un període d'inactivitat per al cas del mapatge, un reinici o un canvi d'adreça per al cas de la reconnexió.

Bloquejar el trànsit directe és una decisió a part

Un bucle de reconnexió pot estar perfectament sa mentre una aplicació fa servir en silenci la ruta ordinària, i això és una fuita, no una fallada. Si el requisit és que res surti fora del túnel, digueu-ho explícitament a la configuració del client i demostreu-ho abaixant el túnel i mirant què encara es connecta. Cap mecanisme no implica aquest comportament i cap disciplina de reintents no l'estableix.

Anoteu quin mecanisme s'ha executat i si després ha funcionat una petició nova. Aquests dos fets són el que necessita el següent enginyer, i cap dels dos no es veu en una icona d'estat. Una línia de registre que diu que el client s'ha reconnectat no és el mateix que una petició que ha funcionat.

Escriviu la política, no només el número

Poseu la parella en una frase: l'interval d'inactivitat, el llindar de vida, què desencadena una reconstrucció , i què fa el client mentre reintenta. Sense aquesta frase, cada incident futur reobre la mateixa discussió sobre si el keepalive és massa curt o la reconnexió massa lenta.

Les notes de WireGuard sobre limitacions són un recordatori útil que el keepalive és una solució provisional per a middleboxes i no un disseny general de vida. Llegeix aquesta limitació abans d'augmentar la freqüència en resposta a un problema que no pot resoldre.