Encurtar o temporizador DPD não torna o failover VPN mais rápido

Os túneis caem, a recuperação demora noventa segundos e o temporizador de par morto está definido para dez, por isso o temporizador é culpado. Esse raciocínio salta três fases que acontecem depois da deteção e que normalmente consomem a maior parte do tempo. A deteção de vitalidade nota o silêncio; depois a seleção de par, a autenticação, a instalação da rota e a reconexão da aplicação tomam cada uma a sua vez. Encurtar a primeira fase não pode encurtar as restantes, e pode acrescentar agitação a um sistema que já estava com dificuldades.

Quatro fases, uma das quais pode cronometrar

Escreva a recuperação como quatro eventos com marcas temporais. A falha torna-se observável: o último tráfego protegido útil e o primeiro pedido falhado. O mecanismo responsável reage: deteção de vitalidade, um monitor de rota ou outro acionador documentado. A alternativa torna-se utilizável: seleção de par, autenticação, uma nova associação e uma rota que transporta realmente o tráfego pretendido. A aplicação recupera: uma nova operação tem sucesso e o que estava em curso tem um resultado definido.

As regras de vitalidade do IKEv2 descrevem provas sobre o par e as suas trocas, e não dizem nada sobre uma base de dados ou um serviço de ficheiros atrás desse par. Ler um tempo limite de vitalidade como um controlo de saúde de todo o caminho é o erro que inicia a caça ao temporizador.

Porque o temporizador é o número menos interessante

Os valores configurados não são unidades permutáveis. Alguns são intervalos de repetição, outros são limites superiores de uma tentativa e outros correm em paralelo com os demais. Somá-los produz um número que parece uma previsão e se comporta como um rumor. Leia a documentação do campo que está prestes a tocar e anote qual dos três tipos é.

Outras fases não são temporizadores de todo. Um atraso de reconexão, um pedido de autenticação interativo ou um cliente que só reavalia a configuração ao reiniciar podem dominar cada um a interrupção enquanto todos os temporizadores do protocolo estão confortavelmente baixos.

Meça a fase que é realmente lenta

Capture a falha uma vez, com marcas temporais dos dois lados, e depois compare os quatro eventos em vez dos contadores do próprio protocolo. Uma janela de observação bem feita vale mais do que um mês de ajustes.

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

Se o ponto final alternativo nunca responder, nenhuma mudança de temporizador ajuda, porque a inalcançabilidade não é um problema de deteção. Se o novo estado de segurança se formar rapidamente mas a rota continuar a apontar para o caminho morto, o problema é a instalação da rota e outro ajuste de vitalidade só acrescenta agitação.

A alternativa tem de estar já utilizável

Uma cópia de segurança definida numa configuração não é uma cópia de segurança que funciona. Tem de ser alcançável a partir da rede atual do cliente, conseguir autenticar a mesma identidade e estar autorizada a transportar o mesmo tráfego sob a mesma política. Descubra qualquer uma dessas três lacunas durante uma interrupção e a discussão do temporizador torna-se irrelevante. Teste a alternativa enquanto a primária está saudável, porque é o único momento em que pode ler os dois registos lado a lado.

Providencie a alternativa com antecedência, teste-a deliberadamente enquanto a primária está saudável e registe qual das quatro fases consome o tempo. É esse registo que faz da alteração seguinte uma medição em vez de uma suposição.

Agitação de retorno e o caminho de gestão

Restaurar a primária é uma decisão separada. Um retorno agressivo pode interromper trabalho que já se tinha recuperado na cópia de segurança, e um caminho instável pode parecer um túnel instável quando a falha real é uma rota que oscila entre duas opções iguais.

Dois caminhos de custo igual sem preferência são a fonte habitual da oscilação visível, porque cada monitor reage à escolha do outro. Decida qual caminho é preferido em condições normais e torne essa preferência explícita na configuração em vez de a deixar à ordem das rotas. Defina antecipadamente o comportamento de retorno desejado e quem é o responsável. Mantenha as definições anteriores e um caminho de gestão independente, porque uma alteração que retira o seu próprio acesso durante uma interrupção transforma um incidente de rede numa visita ao local.

Depois repita a mesma carga de trabalho e compare as mesmas quatro marcas temporais. Uma recuperação mais curta que ainda deixa a aplicação à espera da mesma rota ou início de sessão em falta não é progresso, é um número diferente no mesmo gráfico.