Os túneles caen, a recuperación tarda noventa segundos e o temporizador de par morto está fixado en dez, así que se culpa o temporizador. Ese razoamento omite tres etapas que ocorren despois da detección e que normalmente consomen a maior parte do tempo. A detección de vitalidade advirte o silencio; despois, a selección de par, a autenticación, a instalación da ruta e a reconexión da aplicación toman cada unha a súa quenda. Acortar a primeira etapa non pode acortar as demais, e pode engadir axitación a un sistema que xa estaba loitando.

Catro etapas, unha das cales pode cronometrar

Escriba a recuperación como catro eventos con marcas de tempo. O fallo vólvese observable: o último tráfico protexido útil e a primeira petición fallida. O mecanismo responsable reacciona: detección de vitalidade, un monitor de ruta ou outro disparador documentado. A alternativa vólvese utilizable: selección de par, autenticación, unha nova asociación e unha ruta que realmente transporta o tráfico previsto. A aplicación recupérase: unha operación nova ten éxito e o que estaba en curso ten un resultado definido.

As regras de vitalidade de IKEv2 describen probas sobre o par e os seus intercambios, e non din nada sobre unha base de datos ou un servizo de ficheiros detrás dese par. Ler un tempo de espera de vitalidade como unha comprobación de saúde de todo o camiño é o erro que inicia a caza do temporizador.

Por que o temporizador é o número menos interesante

Os valores configurados non son unidades intercambiables. Algúns son intervalos de reintento, outros son límites superiores dun intento e outros execútanse ao mesmo tempo que os demais. Sumalos produce un número que parece unha predición e compórtase como un rumor. Lea a documentación do campo que está a piques de tocar e anote cal dos tres tipos é.

Outras etapas non son temporizadores en absoluto. Un retroceso de reconexión, unha solicitude de autenticación interactiva ou un cliente que só reavalia a súa configuración ao reiniciar poden dominar cada un a interrupción mentres todos os temporizadores do protocolo están comodamente baixos.

Mida a etapa que é realmente lenta

Capture o fallo unha vez, con marcas de tempo nos dous lados, e despois compare os catro eventos en lugar dos contadores propios do protocolo. Unha xanela de observación ben feita vale máis que un mes de axustes.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Se o punto final alternativo nunca responde, ningún cambio de temporizador axuda, porque a inalcanzabilidade non é un problema de detección. Se o novo estado de seguranza se forma rapidamente pero a ruta segue apuntando ao camiño morto, o problema é a instalación da ruta e outro axuste de vitalidade só engade axitación.

A alternativa debe estar xa utilizable

Unha copia de seguridade definida nunha configuración non é unha copia de seguridade que funcione. Debe ser alcanzable desde a rede actual do cliente, capaz de autenticar a mesma identidade e autorizada a transportar o mesmo tráfico baixo a mesma política. Descubra calquera desas tres lagoas durante unha interrupción e a discusión do temporizador vólvese irrelevante. Probe a alternativa mentres a primaria está sá, porque é o único momento en que pode ler ambos os rexistros un ao lado do outro.

Aprovisione a alternativa de antemán, próbea deliberadamente mentres a primaria está sá e rexistre cal das catro etapas consume o tempo. Ese rexistro é o que converte o seguinte cambio nunha medición en lugar dunha conxectura.

Axitación de retorno e a ruta de xestión

Restaurar a primaria é unha decisión separada. Un retorno agresivo pode interromper traballo que xa se recuperara na copia de seguridade, e un camiño inestable pode parecer un túnel inestable cando o fallo real é unha ruta que oscila entre dúas opcións iguais.

Dous camiños de igual custo sen preferencia son a fonte habitual da oscilación visible, porque cada monitor reacciona á elección do outro. Decida que camiño se prefire en condicións normais e faga explícita esa preferencia na configuración en lugar de deixala á orde das rutas. Defina de antemán o comportamento de retorno desexado e quen é o seu dono. Conserve a configuración anterior e unha ruta de xestión independente, porque un cambio que elimina o seu propio acceso durante unha interrupción converte un incidente de rede nunha visita ao sitio.

Logo repita a mesma carga de traballo e compare as mesmas catro marcas de tempo. Unha recuperación máis curta que aínda deixa a aplicación esperando a mesma ruta ou inicio de sesión ausente non é progreso, é un número distinto no mesmo gráfico.

Artigos relacionados