O keepalive non é unha reconexión: escolle segundo o fallo que teñas

Os keepalives e as reconexións configúranse ao mesmo tempo e resolven problemas distintos, por iso axustar un raramente arranxa o outro. Un keepalive envía tráfico pequeno para manter viva unha entrada de estado ou para notar que un par deixou de responder. Unha reconexión derruba o que está roto e volve construír a relación, incluídas claves, enderezos e rutas. Escolle o mecanismo que encaixa co fallo, non o que xa coñeces de memoria. Dúas preguntas decídeno: está morto o camiño ou algo entre os pares o está esquecendo?

Cando a correspondencia é o problema

Un túnel que morre só tras minutos de silencio adoita perder unha entrada de tradución e non un par. O PersistentKeepalive de WireGuard existe para o estado de NAT e cortalumes, e as notas do propio proxecto presentan o así, non como unha comprobación de saúde. Un intervalo de varias decenas de segundos mantén a entrada quente, mentres que un paquete cada segundo é unha decisión de batería e non de fiabilidade. OpenVPN chega ao mesmo sitio mediante ping e ping-restart , que notan primeiro o silencio e despois actúan.

Eses axustes tampouco son intercambiables entre protocolos. Unha política de par morto de IKEv2, un temporizador ping de OpenVPN e un keepalive de WireGuard responden á mesma pregunta con tres sintaxes e tres valores por defecto distintos, así que copiar un número entre eles é adiviñar disfrazado de axuste.

Cando a relación desapareceu

Se o par cambia de enderezo, a credencial caduca ou o extremo remoto se reinicia, os paquetes pequenos non son a reparación. A reconexión ten que reconstruír o estado : obter un enderezo, reinstalar as rutas, renegociar as claves e, nalgúns despregamentos, reautenticar un usuario.

Os clientes que se reconectan sen supervisión gardan un certificado ou un segredo almacenado. Un cliente que preguntaría a unha persoa falla xusto cando non hai ninguén, que é o escenario no que a reconexión importaba. Iso é unha decisión de deseño tomada meses antes, non un axuste que poidas cambiar durante unha caída.

O que ningún dos dous demostra

Un túnel pode estar reconectado, con claves e rutas, mentres o servizo que hai detrás está caído, e un keepalive pode manter aberta unha correspondencia para unha sesión cuxo servidor leva horas desaparecido. Ambos mecanismos poden informar de éxito mentres o que de verdade che importa non está dispoñible.

Por iso a proba remata nunha petición real. Envía algo polo túnel despois do intervalo que che importa e logo provoca por separado o fallo para o que deseñaches: un período de inactividade para o caso da correspondencia, un reinicio ou un cambio de enderezo para o caso da reconexión.

Bloquear o tráfico directo é unha decisión aparte

Un bucle de reconexión pode estar perfectamente san mentres unha aplicación usa en silencio a ruta ordinaria, e iso é unha fuga, non un fallo. Se o requisito é que nada saia fóra do túnel, dío explicitamente na configuración do cliente e demóstrao baixando o túnel e mirando que segue conectando. Ningún dos dous mecanismos implica ese comportamento e ningunha disciplina de reintentos o establece.

Anota que mecanismo se executou e se despois funcionou unha petición nova. Eses dous feitos son o que necesita o seguinte enxeñeiro, e ningún se ve nunha icona de estado. Unha liña de rexistro que di que o cliente se reconectou non é o mesmo ca unha petición que funcionou.

Escribe a política, non só o número

Pon o par nunha frase: o intervalo de inactividade, o limiar de vitalidade, que desencadea unha reconstrución , e que fai o cliente mentres reintenta. Sen esa frase, cada incidente futuro reabre a mesma discusión sobre se o keepalive é demasiado curto ou a reconexión demasiado lenta.

As notas de WireGuard sobre limitacións son un recordatorio útil de que o keepalive é unha solución provisional para middleboxes e non un deseño xeral de vitalidade. Le esa limitación antes de subir a frecuencia en resposta a un problema que non pode resolver.