Dubblerade IKE-paket: hitta den saknade övergången

Loggen visar samma IKE-begäran två gånger, någon pekar på den mobila upplänken och ärendet stängs med en gissning. Den gissningen är myten: ett upprepat paket är en observation om ett enda utbyte, inte en diagnos av en länk. Omsändning är normalt beteende med egna regler, och det dyker upp på friska vägar varje gång ett svar är långsamt. Följ svaret innan du skyller på ett gränssnitt.

Myten: en upprepad begäran bevisar förlust på en länk

Två olika saker skapar en dubblett, och ingen av dem namnger en skyldig. Begäraren kan upprepa en begäran eftersom inget svar kom, eller så kan fångstpunkten visa samma paket två gånger på grund av var den sitter på stacken. En avlyssnare som ser in- och utgående trafik på samma värd loggar gärna ett paket som två, och operatören som läser den loggen har inget sätt att skilja dem utan utbytesidentifierarna. Behandla dubbletten som en timerhändelse tills du kan säga vilken av de två du håller i.

Två upplänkar gör förvirringen värre i stället för bättre. En loggrad namnger ett gränssnitt, medan svaret kan ha gått ut genom det andra, så gränssnittet i meddelandet beskriver var ett paket sågs och inte samtalets form. Därför är den första frågan vilket utbyte du tittar på, inte vilken länk som är defekt.

Vad omsändningen faktiskt säger dig

I IKEv2 fungerar omsändning så här: begäraren upprepar en begäran när inget svar har anlänt, och svararen kan skicka sitt cachade svar igen i stället för att räkna ut ett nytt. Meddelandeidentifierare hör till det utbytet, och det är det som gör en upprepad begäran med samma identifierare igenkännbar som protokollet som arbetar och inte som ett nytt försök. Ett första försök behöver ofta mer än en källadress eller en initiator-SPI för att korreleras, så plattformens egen utbytespost slår en paketlista. IKEv1 följer andra regler med andra identifierare, och en leverantörsvarning om ett dubblerat första paket betyder inte samma sak över versioner.

Så en tidsstämpel för omsändning säger att en timer har gått ut. Den säger inte vilket hopp som var långsamt, och den säger absolut inte att operatören har skulden. Det är separata påståenden, och bara det andra är användbart i ett ärende.

Den praktiska konsekvensen är att registrera utbytet innan du drar en slutsats. Notera den lokala mottagaradressen, den svarsväg som policyn valde, peer-tupeln och utbytesidentifierarna på ett ställe, eftersom var och en av dem svarar på en annan fråga när posten läses senare.

Fyra observationspunkter som en enda kedja

Tänk på utbytet som fyra länkar i en kedja och inte som fyra separata ställen att titta på. En länk håller bevis eller förblir okänd, och kedjan är bara så informativ som dess svagaste registrerade länk. Tabellen nedan är inventariet: vad varje position kan fastställa och vad den lämnar orört.

Fyll bara i kedjan där du har åtkomst, och markera resten som okänd i stället för att sluta dig till den. En hook som registrerar paket på en maskin säger ingenting om vad den avlägsna maskinen tog emot, och en loggrad som noterar att en begäran sågs är inget bevis för att ett svar någonsin gick ut. Ärliga luckor är mer användbara än en post som ser komplett ut och är byggd på gissningar.

Hitta den första saknade övergången

Gå kedjan från initiativtagaren och utåt och stanna vid den första länken utan bevis. Om gatewayen aldrig loggar begäran sitter felet på vägen före den. När gatewayen loggar samma begäran om och om igen medan klienten aldrig loggar ett svar är riktningen tillbaka den misstänkta: källadress, översättning och filtrering vid varje gräns du kontrollerar. Om svaret anländer och klienten ändå inte kommer vidare har frågan lämnat transporten och blivit policy eller tillstånd.

Håll peeren och protokollet fasta medan du jämför, och kom ihåg att fördröjning, förlust, policy och tillstånd var och en ger en annan tidslinje. Ett mobilt nätverk är inte automatiskt orsaken, och en fast linje är inte automatiskt tillräckligt tillförlitlig för varje krav. Fånga båda riktningarna medan utbytet är levande:

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

När åtkomsten upphör före den avlägsna änden hjälper posten fortfarande om den säger var den upphör. En fångst bara på initiativtagaren kan visa en begäran som går ut och inget svar som kommer in, vilket snävar in felet till allt efter den hooken utan att låtsas veta vilket hopp som tappade den. Markera de avlägsna länkarna som okända och låt nästa person med åtkomst fylla i dem. Skrivet så förblir posten ärlig och fortfarande kort.

Jämför innan du ändrar något. Att upprepa samma begäran mot samma peer med samma protokoll håller variablerna räkningsbara, medan en återställning, en nyckelomgenerering eller en policyändring mellan fångster förstör jämförelsen. Om en ändring är oundviklig, fånga igen direkt efteråt så att före och efter fortfarande beskriver samma utbyte.

Vad en användbar rapport säger

En rapport som är värd att agera på parar ihop en begäran med sitt svar och namnger det första steget som inte har bevis bakom sig. Den meningen tål att läsas en vecka senare av en ingenjör som inte var där, och den ger nästa person en startpunkt i stället för en misstänkt.

Försvaga aldrig identitetskontroller och utöka inte den tillåtna protokolluppsättningen bara för att kontrollera en omsändningsteori. Spara originalpaketen och händelseposterna före varje återställning, eftersom en återställning förstör exakt det material du var på väg att samla in och raderar den tidsangivelse som visade var utbytet fastnade.

Myten är att en dubblett bevisar att en operatör har skulden. Verkligheten är att en dubblett bevisar att en timer har gått ut, och svaret lever på svarsvägen.