Dubbele IKE-pakketten: vind de ontbrekende overgang

Het log toont hetzelfde IKE-verzoek twee keer, iemand wijst naar de mobiele uplink en het ticket sluit met een gok. Die gok is de mythe: een herhaald pakket is een waarneming over een uitwisseling, geen diagnose van een link. Retransmissie is normaal gedrag met eigen regels, en het verschijnt op gezonde paden zodra een antwoord traag is. Volg het antwoord voordat je een interface de schuld geeft.

De mythe: een herhaald verzoek bewijst verlies op een link

Twee verschillende dingen veroorzaken een duplicaat, en geen van beide noemt een schuldige. De aanvrager kan een verzoek herhalen omdat er geen antwoord kwam, of het opnamepunt kan hetzelfde pakket twee keer tonen door waar het aan de stack hangt. Een tap die inkomend en uitgaand verkeer op dezelfde host ziet, logt een pakket met plezier als twee, en de operator die dat log leest heeft geen manier om het verschil te zien zonder de uitwisselingsidentificaties. Behandel het duplicaat als een timergebeurtenis tot je kunt zeggen welk van de twee je in handen hebt.

Twee uplinks maken de verwarring erger in plaats van beter. Een logregel noemt een interface, terwijl het antwoord via de andere kan zijn vertrokken, dus de interface in het bericht beschrijft waar een pakket is gezien en niet de vorm van het gesprek. Daarom is de eerste vraag welke uitwisseling je bekijkt, niet welke link defect is.

Wat de retransmissie je werkelijk vertelt

In IKEv2 werkt retransmissie zo: de aanvrager herhaalt een verzoek wanneer er geen antwoord is aangekomen, en de beantwoorder kan zijn gecachte antwoord opnieuw sturen in plaats van een nieuw te berekenen. Berichtidentificaties horen bij die uitwisseling, en dat is wat een herhaald verzoek met dezelfde identificatie herkenbaar maakt als het protocol dat werkt en niet als een nieuwe poging. Een eerste poging heeft vaak meer nodig dan een bronadres of een initiator-SPI om te correleren, dus het eigen uitwisselingsrecord van het platform verslaat een pakketlijst. IKEv1 volgt andere regels met andere identificaties, en een leverancierswaarschuwing over een dubbel eerste pakket betekent niet hetzelfde over versies heen.

Dus een retransmissietijdstempel vertelt je dat een timer is verlopen. Het vertelt je niet welke hop traag was, en het vertelt zeker niet dat de operator schuld heeft. Dat zijn aparte beweringen, en alleen de tweede is nuttig in een ticket.

De praktische consequentie is de uitwisseling vastleggen voordat je een conclusie trekt. Noteer het lokale ontvangstadres, het antwoordpad dat het beleid koos, de peer-tuple en de uitwisselingsidentificaties op een plek, want elk daarvan beantwoordt een andere vraag wanneer het record later wordt gelezen.

Vier observatiepunten als een keten

Zie de uitwisseling als vier schakels in een keten en niet als vier afzonderlijke plekken om te kijken. Een schakel bevat bewijs of blijft onbekend, en de keten is alleen zo informatief als zijn zwakste vastgelegde schakel. De tabel hieronder is de inventaris: wat elke positie kan vaststellen en wat die ongemoeid laat.

Vul de keten alleen waar je toegang hebt, en markeer de rest als onbekend in plaats van die af te leiden. Een hook die pakketten op een machine vastlegt, zegt niets over wat de verre machine ontving, en een logregel dat een verzoek is gezien is geen bewijs dat er ooit een antwoord uitging. Eerlijke gaten zijn nuttiger dan een record dat er compleet uitziet en uit gissingen is opgebouwd.

Vind de eerste ontbrekende overgang

Loop de keten vanaf de initiator naar buiten en stop bij de eerste schakel zonder bewijs. Als de gateway het verzoek nooit logt, zit de fout op het pad ervoor. Wanneer de gateway hetzelfde verzoek steeds opnieuw logt terwijl de client nooit een antwoord logt, is de terugweg verdacht: bronadres, vertaling en filtering bij elke grens die je beheert. Als het antwoord aankomt en de client komt toch niet verder, heeft de vraag het transport verlaten en is het beleid of toestand geworden.

Houd de peer en het protocol vast terwijl je vergelijkt, en onthoud dat vertraging, verlies, beleid en toestand elk een andere tijdlijn opleveren. Een mobiel netwerk is niet automatisch de oorzaak, en een vaste lijn is niet automatisch betrouwbaar genoeg voor elke eis. Leg beide richtingen vast terwijl de uitwisseling leeft:

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

Wanneer de toegang voor het verre einde stopt, helpt het record nog als het zegt waar het stopt. Een opname alleen op de initiator kan een verzoek zien vertrekken en geen antwoord zien aankomen, wat de fout beperkt tot alles na die hook zonder te doen alsof je weet welke hop het liet vallen. Markeer de verre schakels als onbekend en laat de volgende persoon met toegang ze invullen. Zo opgeschreven blijft het record eerlijk en nog steeds kort.

Vergelijk voordat je iets verandert. Hetzelfde verzoek naar dezelfde peer met hetzelfde protocol herhalen houdt de variabelen telbaar, terwijl een reset, een sleutelvernieuwing of een beleidswijziging tussen opnames de vergelijking vernietigt. Als een wijziging onvermijdelijk is, leg dan direct daarna opnieuw vast, zodat voor en na nog steeds dezelfde uitwisseling beschrijven.

Wat een bruikbaar rapport zegt

Een rapport dat de moeite waard is om op te handelen, koppelt een verzoek aan zijn antwoord en noemt de eerste stap waar geen bewijs achter zit. Die zin overleeft het een week later gelezen worden door een ingenieur die er niet bij was, en geeft de volgende persoon een beginpunt in plaats van een verdachte.

Verzwak nooit identiteitscontroles en verbreed de toegestane protocolset niet alleen om een retransmissietheorie te controleren. Bewaar de originele pakketten en gebeurtenisrecords voor elke reset, want een reset vernietigt precies het materiaal dat je wilde verzamelen en wist de timing die liet zien waar de uitwisseling vastliep.

De mythe is dat een duplicaat bewijst dat een operator schuld heeft. De werkelijkheid is dat een duplicaat bewijst dat een timer is verlopen, en het antwoord leeft op het antwoordpad.