A detección de par morto de IKEv2 non proba a súa aplicación

A comprobación de vitalidade de IKEv2 formula unha pregunta: segue respondendo o outro par na relación de control protexida. Non mide se unha aplicación interna está sa, se existe unha ruta detrás da pasarela nin se navegar parece rápido. A comprobación pode pasar mentres todo o útil detrás do túnel falla.

Lea os dous tipos de evidencia por separado antes de cambiar un temporizador.

Que pregunta realmente a comprobación de vitalidade

Un intercambio de vitalidade envíase dentro da asociación de seguridade IKE establecida e agarda unha resposta nunha xanela configurada. O éxito significa que a implementación de IKE do par segue aí e segue disposta a falar. Non di nada sobre as asociacións de seguridade fillas que transportan tráfico, nada sobre o encamiñamento máis alá da pasarela e nada sobre o servizo polo que abriu o túnel. Son tres preguntas separadas con tres modos de fallo separados.

Esa distinción decide onde mirar cando unha sesión queda en silencio. Un par que segue respondendo mentres unha ruta de datos está rota apunta a política, encamiñamento ou un servizo posterior. Un par que deixa de responder apunta a alcanzabilidade ou ao estado propio do extremo afastado.

Lea as asociacións de seguridade antes do navegador

O estado de control e o estado de datos lístanse por separado en canto se pregunta ao daemon, e os contadores din se se intentou algo. Unha asociación filla que nunca se instalou non se parece en nada a unha que se instalou e logo deixou de pasar paquetes, aínda que ambas producen a mesma queixa do usuario.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Anote os nomes de estado literalmente no tícket, xunto cos contadores no momento da queixa. Unha descrición como túnel caído oculta cal das dúas asociacións rematou, e normalmente ese é o único dato que paga a pena ter.

Un fallo de ruta parece exactamente un par morto

A pasarela pode responder aos intercambios de control mentres un servidor privado está fóra de liña, falta unha ruta reenviada ou a resolución de nomes interna falla por completo. Desde o cliente, todo iso preséntase como unha sesión activa e un destino que non o está. Comprobe a ruta de volta co mesmo coidado que a de ida, porque o encamiñamento asimétrico no extremo afastado produce silencio só nunha dirección.

Probe a aplicación prevista directamente e nomee o enderezo que tentou, en lugar de probar se o túnel está levantado. Un ping á pasarela demostra que a pasarela responde; nunca demostrou que a aplicación o fixese. Rexistre o enderezo exacto que tentou a aplicación. Esa cadea acouta a busca máis adiante, e é o único dato que o tícket adoita omitir.

Manteña os temporizadores fóra do diagnóstico

Acortar un intervalo de detección non é un cambio de rendemento e non engade capacidade. Con perda de paquetes cambia a rapidez con que se recoñece un fallo, o que pode facer que un síntoma pareza distinto sen mellorar nada. Rexistre primeiro a hora real do fallo e logo decida se a tolerancia é incorrecta para a ligazón que realmente ten.

As actualizacións de mapeo NAT pertencen á mesma categoría. Manteñen utilizábel unha ruta traducida e non son evidencia de que a aplicación remota funcione.

Unha política de recuperación completa di que debe facer o cliente cando se declara morto un par: reiniciar, pechar ou agardar, e que pode facer o resto do tráfico mentres ocorre. Sen iso, o mesmo incidente vólvese diagnosticar desde cero cada trimestre.