Paquets IKE duplicats: trobeu la transició que falta
Una sol·licitud IKE repetida és un esdeveniment de temporitzador, no un diagnòstic. Construïu una cadena d'evidències de l'iniciador a la resposta, amb els identificadors de versió correctes.
El registre mostra la mateixa sol·licitud IKE dues vegades, algú assenyala l'enllaç mòbil i l'incident es tanca amb una conjectura. Aquesta conjectura és el mite: un paquet repetit és una observació sobre un intercanvi, no un diagnòstic d'un enllaç. La retransmissió és un comportament normal amb les seves pròpies regles i apareix en camins sans sempre que una resposta és lenta. Seguiu la resposta abans de culpar una interfície.
El mite: una sol·licitud repetida demostra pèrdua en un enllaç
Dues coses diferents produeixen un duplicat i cap de les dues assenyala un culpable. El sol·licitant pot repetir una sol·licitud perquè no va rebre cap resposta, o el punt de captura pot mostrar el mateix paquet dues vegades per on està connectat a la pila. Una sonda que veu l'entrada i la sortida al mateix amfitrió registrarà feliçment un paquet com a dos, i l'operador que llegeix aquest registre no té manera de distingir-ho sense els identificadors de l'intercanvi. Tracteu el duplicat com un esdeveniment de temporitzador fins que pugueu dir quin dels dos teniu a les mans.
Dos enllaços ascendents empitjoren la confusió en lloc de millorar-la. Una sola línia de registre anomena una interfície, mentre que la resposta pot haver sortit per l'altra, així que la interfície del missatge descriu on es va veure un paquet i no la forma de la conversa. Per això la primera pregunta és quin intercanvi esteu mirant, no quin enllaç és defectuós.
Què us diu realment la retransmissió
A IKEv2, la retransmissió funciona així: el sol·licitant repeteix una sol·licitud quan no ha arribat cap resposta, i el responedor pot reenviar la seva resposta en cau en lloc de recalcular-ne una. Els identificadors de missatge pertanyen a aquest intercanvi, i és el que fa que una sol·licitud repetida amb el mateix identificador es reconegui com el protocol funcionant i no com un intent nou. Un intent inicial sovint necessita més que una adreça d'origen o un SPI d'iniciador per correlacionar-se, així que el registre d'intercanvi de la plataforma supera una llista de paquets. IKEv1 segueix regles diferents amb identificadors diferents, i un avís de proveïdor sobre un primer paquet duplicat no significa el mateix entre versions.
Així, una marca de temps de retransmissió us diu que un temporitzador ha caducat. No us diu quin salt era lent, i certament no us diu que l'operador sigui el culpable. Són afirmacions separades, i només la segona és útil en un tiquet.
La conseqüència pràctica és registrar l'intercanvi abans de treure una conclusió. Anoteu l'adreça local de recepció, el camí de resposta que va triar la política, la tupla del parell i els identificadors de l'intercanvi en un sol lloc, perquè cadascun respon una pregunta diferent quan el registre es llegeix més tard.
Quatre punts d'observació com una sola cadena
Penseu en l'intercanvi com quatre baules d'una cadena i no com quatre llocs separats on mirar. Una baula té evidència o queda desconeguda, i la cadena només és tan informativa com la seva baula registrada més feble. La taula següent és l'inventari: què pot establir cada posició i què deixa intacte.
| Posició | Evidència que pot aportar | Què deixa obert |
|---|---|---|
| L'iniciador envia | Una sol·licitud va sortir d'aquest amfitrió | Si va arribar al parell |
| El responedor rep | La sol·licitud va arribar | Si es va produir una resposta |
| El responedor envia | Una resposta va sortir de la passarel·la | Si va seguir el camí previst |
| L'iniciador rep | L'intercanvi es va completar | Si la política va acceptar el resultat |
Ompliu la cadena només on teniu accés i marqueu la resta com a desconeguda en lloc d'inferir-la. Un ganxo que registra paquets en una màquina no diu res sobre què va rebre la màquina remota, i una línia de registre que anota que es va veure una sol·licitud no és prova que una resposta hagi sortit mai. Els buits honestos són més útils que un registre que sembla complet i està fet de conjectures.
Trobeu la primera transició que falta
Recorreu la cadena des de l'iniciador cap enfora i atureu-vos a la primera baula sense evidència. Si la passarel·la no registra mai la sol·licitud, la falla és al camí anterior. Quan la passarel·la registra la mateixa sol·licitud una vegada i una altra mentre el client no registra mai cap resposta, el sospitós és la direcció de tornada: adreça d'origen, traducció i filtratge a cada frontera que controleu. Si la resposta arriba i el client encara no avança, la pregunta ha deixat el transport i s'ha convertit en política o estat.
Mantingueu el parell i el protocol fixos mentre compareu, i recordeu que el retard, la pèrdua, la política i l'estat produeixen cadascun una línia temporal diferent. Una xarxa mòbil no és automàticament la causa, i una línia fixa no és automàticament prou fiable per a tots els requisits. Captureu les dues direccions mentre l'intercanvi és viu:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'Quan l'accés s'atura abans de l'extrem llunyà, el registre encara ajuda si diu on s'atura. Una captura només a l'iniciador pot mostrar una sol·licitud que surt i cap resposta que arriba, cosa que estreny la falla a tot el que ve després d'aquell ganxo sense fingir saber quin salt la va deixar caure. Marqueu les baules llunyanes com a desconegudes i deixeu que la propera persona amb accés les ompli. Escrit així, el registre es manté honest i encara curt.
Compareu abans de canviar res. Repetir la mateixa sol·licitud contra el mateix parell amb el mateix protocol manté les variables comptables, mentre que un reinici, una renovació de clau o una edició de política entre captures destrueix la comparació. Si un canvi és inevitable, captureu de nou immediatament després perquè l'abans i el després encara descriguin el mateix intercanvi.
Què diu un informe útil
Un informe que val la pena aplicar aparella una sol·licitud amb la seva resposta i anomena el primer pas que no té evidència al darrere. Aquesta frase sobreviu a ser llegida una setmana després per un enginyer que no hi era, i dona a la propera persona un lloc per començar en lloc d'un sospitós.
No debiliteu mai les comprovacions d'identitat ni amplieu el conjunt de protocols permès només per comprovar una teoria de retransmissió. Deseu els paquets i els registres d'esdeveniments originals abans de qualsevol reinici, perquè un reinici destrueix exactament el material que estàveu a punt de recollir i esborra el temps que mostrava on s'havia encallat l'intercanvi.
El mite és que un duplicat demostra que l'operador és culpable. La realitat és que un duplicat demostra que un temporitzador ha caducat, i la resposta viu al camí de resposta.