keepalive de OpenVPN ou reinicio de systemd: cal recupera o túnel?

Tres cousas distintas poden fallar nun túnel, e esixen tres reaccións distintas. O par deixa de responder, o proceso do demo morre ou a aplicación detrás do túnel deixa de servir. Unha configuración que reinicia o servizo ante calquera delas non é unha supervisión coidadosa; é unha acción contundente aplicada a fallos non relacionados. Comparar o que cada mecanismo pode observar de verdade fai evidente o reparto do traballo.

Tres fallos que parecen un

O silencio do par significa que o outro extremo deixou de enviar, e OpenVPN pode detectalo por si mesmo porque posúe o latexo. A morte do proceso significa que o demo saíu, o que o xestor de servizos nota e OpenVPN non pode. O fallo da aplicación significa que o túnel está ben e algo detrás non o está, e ningún dos outros dous mecanismos ten forma de sabelo. Cada un necesita unha reacción distinta, e ningún é o mesmo que advertir que o túnel está activo.

Son sinais distintos de capas distintas, e cada unha ten un dono que pode actuar sobre ela sen adiviñar. Mesturalas produce un sistema que reinicia ante síntomas que non pode interpretar.

Escriba os tres casos antes de cambiar calquera temporizador. A lista mesma adoita mostrar que se lle pide a un mecanismo que cubra os tres.

A que se expande realmente keepalive

A directiva keepalive é unha abreviatura, e a expansión varía segundo o modo. Nun servidor, keepalive 10 60 convértese nun ping local cada dez segundos, un tempo de espera de reinicio local de 120 segundos e valores de 10 e 60 enviados aos clientes. O tempo de espera do servidor duplícase a propósito para que un cliente teña ocasión de reiniciar antes de que o servidor se renda. Lea a forma expandida na configuración en execución, non a abreviatura do perfil.

Esa duplicación é a razón pola que calquera descrición que afirme que ambos extremos reinician aos sesenta segundos é incorrecta. Tamén explica por que os dous extremos non oscilan á vez cando un camiño se degrada.

O latexo é tráfico de pares de OpenVPN, non unha sonda ICMP a algún host público. Unha resposta só demostra que o extremo afastado do túnel está vivo. Non di nada sobre a base de datos ou o servizo web que o usuario necesita de verdade.

O que Restart=on-failure non vixía

Lea a unidade instalada antes de engadir unha anulación. Restart=on-failure responde a condicións documentadas de fallo do proceso, o que non é o mesmo que vixiar o estado da conexión. Non se dispara porque comezase unha reconexión interna, e unha saída limpa ten unha semántica distinta dunha caída.

Esa distinción importa porque un reinicio interno mantén vivo o mesmo proceso. A unidade non ve nada, o túnel recupérase só, e ese é o resultado correcto.

Fixe RestartSec e os límites de arranque a propósito, ou un bucle de caídas golpeará a pasarela e enterrará o erro real baixo mensaxes de reinicio. Un límite de reinicio que se activa deixa a unidade en estado de fallo, o cal é visible, mentres que un bucle ilimitado non o é.

ping-restart e ping-exit non son intercambiables

ping-restart desencadea o reinicio interno de OpenVPN e conserva o proceso. ping-exit remata o proceso co mesmo tipo de tempo de espera, o que entrega a decisión ao xestor de servizos. Son mutuamente excluíntes, e escoller o segundo cambia quen posúe a recuperación. A diferenza é quen decide reintentar e canto estado sobrevive ao intento.

Se escolle saír ao esgotarse o tempo, a unidade necesita unha política de reinicio e un tratamento do estado de saída que encaixen, ou un fallo de vitalidade parecerá unha parada permanente. As opcións de persistencia tamén poden conservar interfaces e rutas durante un reinicio interno, pero non durante unha saída do proceso.

Escolla un ciclo de vida por despregamento e escriba por que. Un perfil que leva ambas as directivas é un perfil que non decidiu.

Probe cada fallo como o seu propio caso

Simule un par silencioso, un demo asasinado e unha aplicación non dispoñible nunha ventá aprobada, e logo comprobe que recuperación se disparou. Un par silencioso debería producir unha reconexión interna, un proceso asasinado un reinicio da unidade, e unha caída da aplicación ningunha das dúas. Cando dous casos producen a mesma acción, a propiedade segue mesturada.

A recuperación repetida tampouco é unha reparación. As credenciais rexeitadas ou dous clientes que comparten un nome efectivo seguirán substituíndose, e os temporizadores máis rápidos só fan máis rápida esa oscilación.