keepalive d'OpenVPN o reinici de systemd: què recupera el túnel?

Tres coses diferents poden anar malament amb un túnel, i demanen tres reaccions diferents. El parell deixa de respondre, el procés del dimoni mor o l'aplicació darrere del túnel deixa de servir. Una configuració que reinicia el servei davant de qualsevol d'elles no és una supervisió acurada; és una acció contundent aplicada a fallades no relacionades. Comparar què pot observar realment cada mecanisme fa òbvia la divisió de la feina.

Tres fallades que semblen una

El silenci del parell vol dir que l'altre extrem ha deixat d'enviar, i OpenVPN ho pot detectar sol perquè posseeix el batec. La mort del procés vol dir que el dimoni ha sortit, cosa que el gestor de serveis nota i OpenVPN no pot. La fallada de l'aplicació vol dir que el túnel està bé i alguna cosa darrere no ho està, i cap dels altres dos mecanismes no té manera de saber-ho. Cadascuna necessita una reacció diferent, i cap no és el mateix que adonar-se que el túnel està actiu.

Són senyals diferents de capes diferents, i cadascun té un propietari que pot actuar-hi sense endevinar. Barrejar-los produeix un sistema que reinicia davant de símptomes que no pot interpretar.

Escriviu els tres casos abans de canviar cap temporitzador. La llista mateixa sol mostrar que es demana a un mecanisme que cobreixi tots tres.

A què s'expandeix realment keepalive

La directiva keepalive és una abreviatura, i l'expansió varia segons el mode. En un servidor, keepalive 10 60 es converteix en un ping local cada deu segons, un temps d'espera de reinici local de 120 segons i valors de 10 i 60 enviats als clients. El temps d'espera del servidor es duplica expressament perquè un client tingui l'oportunitat de reiniciar-se abans que el servidor es rendeixi. Llegiu la forma expandida a la configuració en execució, no l'abreviatura del perfil.

Aquesta duplicació és la raó per la qual qualsevol descripció que afirmi que tots dos extrems reinicien al cap de seixanta segons és incorrecta. També explica per què els dos extrems no oscil·len alhora quan un camí es degrada.

El batec és trànsit de parell d'OpenVPN, no una sonda ICMP d'algun amfitrió públic. Una resposta només demostra que l'extrem llunyà del túnel és viu. No diu res sobre la base de dades ni el servei web que l'usuari necessita realment.

Què no vigila Restart=on-failure

Llegiu la unitat instal·lada abans d'afegir una substitució. Restart=on-failure respon a condicions documentades de fallada del procés, cosa que no és el mateix que vigilar l'estat de la connexió. No s'activa perquè hagi començat una reconnexió interna, i una sortida neta té una semàntica diferent d'una caiguda.

Aquesta distinció importa perquè un reinici intern manté viu el mateix procés. La unitat no veu res, el túnel es recupera sol, i aquest és el resultat correcte.

Establiu RestartSec i els límits d'inici deliberadament, o un bucle de caigudes martellejarà la passarel·la i enterrarà l'error real sota missatges de reinici. Un límit de reinici que s'activa deixa la unitat en estat de fallada, cosa que és visible, mentre que un bucle il·limitat no ho és.

ping-restart i ping-exit no són intercanviables

ping-restart desencadena el reinici intern d'OpenVPN i manté el procés. ping-exit acaba el procés amb el mateix tipus de temps d'espera, cosa que lliura la decisió al gestor de serveis. Són mútuament excloents, i triar el segon canvia qui posseeix la recuperació. La diferència és qui decideix tornar-ho a provar i quant estat sobreviu a l'intent.

Si trieu sortir en esgotar-se el temps, la unitat necessita una política de reinici i un tractament de l'estat de sortida que hi encaixin, o una fallada de vitalitat semblarà una aturada permanent. Les opcions de persistència també poden conservar interfícies i rutes durant un reinici intern, però no durant una sortida del procés.

Trieu un cicle de vida per desplegament i escriviu per què. Un perfil que porta les dues directives és un perfil que no ha decidit.

Proveu cada fallada com el seu propi cas

Simuleu un parell silenciós, un dimoni assassinat i una aplicació no disponible en una finestra aprovada, i comproveu quina recuperació s'ha activat. Un parell silenciós hauria de produir una reconnexió interna, un procés assassinat un reinici de la unitat, i una caiguda de l'aplicació cap de les dues. Quan dos casos produeixen la mateixa acció, la propietat encara està barrejada.

La recuperació repetida tampoc no és una reparació. Credencials rebutjades o dos clients que comparteixen un nom efectiu continuaran substituint-se, i els temporitzadors més ràpids només fan més ràpida aquesta oscil·lació.