Pacotes IKE duplicados: encontre a transição em falta

O registo mostra o mesmo pedido IKE duas vezes, alguém aponta para o uplink móvel e o ticket fecha-se com um palpite. Esse palpite é o mito: um pacote repetido é uma observação sobre uma troca, não um diagnóstico de uma ligação. A retransmissão é um comportamento normal com as suas próprias regras, e aparece em caminhos saudáveis sempre que uma resposta é lenta. Siga a resposta antes de culpar uma interface.

O mito: um pedido repetido prova perda numa ligação

Duas coisas diferentes produzem um duplicado e nenhuma delas nomeia um culpado. O requerente pode repetir um pedido porque não recebeu resposta, ou o ponto de captura pode mostrar o mesmo pacote duas vezes por causa de onde está ligado à pilha. Uma sonda que vê a entrada e a saída no mesmo anfitrião registará de bom grado um pacote como dois, e o operador que lê esse registo não tem forma de distinguir sem os identificadores da troca. Trate o duplicado como um evento de temporizador até conseguir dizer qual dos dois tem na mão.

Dois uplinks pioram a confusão em vez de a melhorar. Uma linha de registo nomeia uma interface, enquanto a resposta pode ter saído pela outra, por isso a interface na mensagem descreve onde um pacote foi visto e não a forma da conversa. É também por isso que a primeira pergunta é que troca está a observar, e não que ligação está avariada.

O que a retransmissão lhe diz realmente

No IKEv2, a retransmissão funciona assim: o requerente repete um pedido quando não chegou qualquer resposta, e o respondente pode reenviar a resposta em cache em vez de calcular uma nova. Os identificadores de mensagem pertencem a essa troca, e é isso que torna um pedido repetido com o mesmo identificador reconhecível como o protocolo a funcionar e não como uma tentativa nova. Uma tentativa inicial precisa muitas vezes de mais do que um endereço de origem ou um SPI de iniciador para ser correlacionada, por isso o registo de troca da própria plataforma vale mais do que uma lista de pacotes. O IKEv1 segue regras diferentes com identificadores diferentes, e um aviso de fornecedor sobre um primeiro pacote duplicado não significa o mesmo entre versões.

Assim, um carimbo temporal de retransmissão diz-lhe que um temporizador expirou. Não diz que salto estava lento, e certamente não diz que o operador tem culpa. São afirmações separadas, e só a segunda é útil num ticket.

A consequência prática é registar a troca antes de tirar uma conclusão. Anote o endereço local de receção, o caminho de resposta escolhido pela política, o tuplo do par e os identificadores da troca num só lugar, porque cada um responde a uma pergunta diferente quando o registo é lido mais tarde.

Quatro pontos de observação como uma só cadeia

Pense na troca como quatro elos de uma cadeia e não como quatro locais separados para olhar. Um elo guarda provas ou fica desconhecido, e a cadeia só é tão informativa como o seu elo registado mais fraco. A tabela abaixo é o inventário: o que cada posição pode estabelecer e o que deixa intacto.

Preencha a cadeia apenas onde tem acesso e marque o resto como desconhecido em vez de o inferir. Um gancho que registra pacotes numa máquina não diz nada sobre o que a máquina remota recebeu, e uma linha de registo a anotar que um pedido foi visto não é prova de que alguma vez tenha saído uma resposta. As lacunas honestas são mais úteis do que um registo com aparência completa construído com suposições.

Encontre a primeira transição em falta

Percorra a cadeia desde o iniciador para fora e pare no primeiro elo sem provas. Se o gateway nunca registra o pedido, a falha está no caminho antes dele. Quando o gateway registra o mesmo pedido vezes sem conta enquanto o cliente nunca registra uma resposta, a direção de retorno é a suspeita: endereço de origem, tradução e filtragem em cada fronteira que controla. Se a resposta chega e o cliente continua sem avançar, a pergunta deixou o transporte e tornou-se política ou estado.

Mantenha o par e o protocolo fixos enquanto compara, e lembre-se de que atraso, perda, política e estado produzem cada um uma linha temporal diferente. Uma rede móvel não é automaticamente a causa, e uma linha fixa não é automaticamente suficientemente fiável para todos os requisitos. Capture as duas direções enquanto a troca está viva:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Quando o acesso termina antes do extremo remoto, o registo ainda ajuda se disser onde termina. Uma captura apenas no iniciador pode mostrar um pedido a sair e nenhuma resposta a chegar, o que estreita a falha a tudo o que vem depois desse gancho sem fingir saber que salto a deixou cair. Marque os elos remotos como desconhecidos e deixe a próxima pessoa com acesso preenchê-los. Escrito assim, o registo mantém-se honesto e ainda curto.

Compare antes de mudar seja o que for. Repetir o mesmo pedido para o mesmo par com o mesmo protocolo mantém as variáveis contáveis, enquanto um reinício, uma renovação de chave ou uma edição de política entre capturas destrói a comparação. Se a mudança for inevitável, capture novamente logo a seguir para que o antes e o depois ainda descrevam a mesma troca.

O que diz um relatório útil

Um relatório que merece ação associa um pedido à sua resposta e nomeia o primeiro passo que não tem provas por trás. Essa frase sobrevive a ser lida uma semana depois por um engenheiro que não estava lá, e dá à pessoa seguinte um ponto de partida em vez de um suspeito.

Nunca enfraqueça as verificações de identidade nem alargue o conjunto de protocolos permitido só para verificar uma teoria de retransmissão. Guarde os pacotes e os registos de eventos originais antes de qualquer reinício, porque um reinício destrói exatamente o material que ia recolher e apaga a temporização que mostrava onde a troca encravou.

O mito é que um duplicado prova que o operador tem culpa. A realidade é que um duplicado prova que um temporizador expirou, e a resposta vive no caminho de resposta.