Paquetes IKE duplicados: atopade a transición que falta

O rexistro mostra a mesma solicitude IKE dúas veces, alguén sinala a ligazón móbil e o ticket péchase cunha conxectura. Esa conxectura é o mito: un paquete repetido é unha observación sobre un intercambio, non un diagnóstico dunha ligazón. A retransmisión é un comportamento normal coas súas propias regras, e aparece en camiños sans sempre que unha resposta é lenta. Seguide a resposta antes de culpar unha interface.

O mito: unha solicitude repetida demostra perda nunha ligazón

Dúas cousas distintas producen un duplicado e ningunha delas nomea un culpable. O solicitante pode repetir unha solicitude porque non recibiu resposta, ou o punto de captura pode mostrar o mesmo paquete dúas veces polo lugar onde está conectado á pila. Unha sonda que ve a entrada e a saída no mesmo host rexistrará alegremente un paquete como dous, e o operador que le ese rexistro non ten forma de distinguilo sen os identificadores do intercambio. Tratade o duplicado como un evento de temporizador ata que poidades dicir cal dos dous tedes na man.

Dúas ligazóns ascendentes empeoran a confusión en lugar de mellorala. Unha soa liña de rexistro nomea unha interface, mentres que a resposta puido saír pola outra, así que a interface da mensaxe describe onde se viu un paquete e non a forma da conversa. Por iso a primeira pregunta é que intercambio estades mirando, non que ligazón está defectuosa.

Que vos di realmente a retransmisión

En IKEv2, a retransmisión funciona así: o solicitante repite unha solicitude cando non chegou ningunha resposta, e o respondedor pode reenviar a súa resposta en caché en lugar de recalcular unha. Os identificadores de mensaxe pertencen a ese intercambio, e iso é o que fai que unha solicitude repetida co mesmo identificador se recoñeza como o protocolo funcionando e non como un intento novo. Un intento inicial adoita necesitar máis ca un enderezo de orixe ou un SPI de iniciador para correlacionarse, así que o rexistro de intercambio da plataforma supera unha listaxe de paquetes. IKEv1 segue regras distintas con identificadores distintos, e un aviso de provedor sobre un primeiro paquete duplicado non significa o mesmo entre versións.

Así que unha marca de tempo de retransmisión dinos que un temporizador caducou. Non di que salto era lento, e desde logo non di que o operador teña a culpa. Son afirmacións separadas, e só a segunda é útil nun ticket.

A consecuencia práctica é rexistrar o intercambio antes de sacar unha conclusión. Anotade o enderezo local de recepción, o camiño de resposta que escolleu a política, a tupla do par e os identificadores do intercambio nun só lugar, porque cada un responde a unha pregunta distinta cando o rexistro se le máis tarde.

Catro puntos de observación como unha soa cadea

Pensade no intercambio como catro elos dunha cadea e non como catro lugares separados onde mirar. Un elo contén probas ou queda descoñecido, e a cadea só é tan informativa como o seu elo rexistrado máis feble. A táboa de abaixo é o inventario: que pode establecer cada posición e que deixa intacto.

Enched a cadea só onde teñades acceso e marcade o resto como descoñecido en lugar de inferilo. Un gancho que rexistra paquetes nunha máquina non di nada sobre o que recibiu a máquina remota, e unha liña de rexistro que anota que se viu unha solicitude non é proba de que algunha vez saíse unha resposta. Os ocos honestos son máis útiles ca un rexistro que parece completo e está construído con conxecturas.

Atopade a primeira transición que falta

Percorrede a cadea dende o iniciador cara a fóra e parades no primeiro elo sen probas. Se a pasarela nunca rexistra a solicitude, a falla está no camiño anterior. Cando a pasarela rexistra a mesma solicitude unha e outra vez mentres o cliente nunca rexistra unha resposta, a dirección de volta é a sospeitosa: enderezo de orixe, tradución e filtrado en cada fronteira que controledes. Se a resposta chega e o cliente segue sen avanzar, a pregunta deixou o transporte e converteuse en política ou estado.

Mantede o par e o protocolo fixos mentres comparades, e lembrade que o retardo, a perda, a política e o estado producen cada un unha liña temporal distinta. Unha rede móbil non é automaticamente a causa, e unha liña fixa non é automaticamente o bastante fiable para todos os requisitos. Capturades as dúas direccións mentres o intercambio está activo:

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

Cando o acceso se detén antes do extremo remoto, o rexistro aínda axuda se di onde se detén. Unha captura só no iniciador pode mostrar unha solicitude que sae e ningunha resposta que chega, o que estreita a falla a todo o posterior a ese gancho sen pretender saber que salto a deixou caer. Marcade os elos remotos como descoñecidos e deixade que a seguinte persoa con acceso os encha. Escrito así, o rexistro mantense honesto e aínda breve.

Comparade antes de cambiar nada. Repetir a mesma solicitude contra o mesmo par co mesmo protocolo mantén as variables contables, mentres que un reinicio, unha renovación de chave ou unha edición de política entre capturas destrúe a comparación. Se un cambio é inevitable, capturade de novo inmediatamente despois para que o antes e o despois sigan describindo o mesmo intercambio.

Que di un informe útil

Un informe que merece actuación emparexa unha solicitude coa súa resposta e nomea o primeiro paso que non ten probas detrás. Esa frase sobrevive a ser lida unha semana despois por un enxeñeiro que non estaba alí, e dálle á seguinte persoa un lugar por onde comezar en lugar dun sospeitoso.

Nunca debilitades as comprobacións de identidade nin ampliedes o conxunto de protocolos permitido só para comprobar unha teoría de retransmisión. Gardade os paquetes e os rexistros de eventos orixinais antes de calquera reinicio, porque un reinicio destrúe exactamente o material que iades recoller e borra a temporización que mostraba onde se atascou o intercambio.

O mito é que un duplicado demostra que o operador ten a culpa. A realidade é que un duplicado demostra que un temporizador caducou, e a resposta vive no camiño de resposta.