Dublerede IKE-pakker: find den manglende overgang

Loggen viser den samme IKE-anmodning to gange, nogen peger på det mobile uplink, og sagen lukkes med et gæt. Det gæt er myten: en gentaget pakke er en observation om én udveksling, ikke en diagnose af et link. Gentransmission er normal adfærd med sine egne regler, og den vises på sunde stier, hver gang et svar er langsomt. Følg svaret, før du giver en grænseflade skylden.

Myten: en gentagen anmodning beviser tab på ét link

To forskellige ting skaber en dublet, og ingen af dem navngiver en skyldig. Anmoderen kan gentage en anmodning, fordi den ikke fik noget svar, eller optagelsespunktet kan vise den samme pakke to gange på grund af, hvor det er koblet til stakken. Et tap, der ser indgående og udgående trafik på samme vært, logger gerne én pakke som to, og operatøren, der læser den log, har ingen måde at skelne uden udvekslingsidentifikatorerne. Behandl dubletten som en timerhændelse, indtil du kan sige, hvilken af de to du holder på.

To uplinks gør forvirringen værre i stedet for bedre. Én loglinje navngiver én grænseflade, mens svaret kan være gået ud gennem den anden, så grænsefladen i meddelelsen beskriver, hvor en pakke blev set, og ikke samtalens form. Derfor er det første spørgsmål, hvilken udveksling du ser på, ikke hvilket link der er defekt.

Hvad gentransmissionen rent faktisk fortæller dig

I IKEv2 fungerer gentransmission sådan: anmoderen gentager en anmodning, når der ikke er kommet noget svar, og svareren kan sende sit cachelagrede svar igen i stedet for at beregne et nyt. Meddelelsesidentifikatorer hører til den udveksling, og det er det, der gør en gentagen anmodning med samme identifikator genkendelig som protokollen, der arbejder, og ikke et nyt forsøg. Et første forsøg kræver ofte mere end en kildeadresse eller en initiator-SPI for at korrelere, så platformens egen udvekslingspost slår en pakkeliste. IKEv1 følger andre regler med andre identifikatorer, og en leverandøradvarsel om en dubleret første pakke betyder ikke det samme på tværs af versioner.

Så et gentransmissionstidsstempel fortæller dig, at en timer er udløbet. Det fortæller dig ikke, hvilket hop der var langsomt, og det fortæller bestemt ikke, at operatøren har skylden. Det er separate påstande, og kun den anden er nyttig i en sag.

Den praktiske konsekvens er at registrere udvekslingen, før du drager en konklusion. Noter den lokale modtageadresse, den svarvej politikken valgte, peer-tuple og udvekslingsidentifikatorerne på ét sted, fordi hver af dem besvarer et forskelligt spørgsmål, når posten læses senere.

Fire observationspunkter som én kæde

Tænk på udvekslingen som fire led i en kæde i stedet for fire separate steder at kigge. Et led holder evidens, eller det forbliver ukendt, og kæden er kun så informativ som sit svageste registrerede led. Tabellen nedenfor er inventaret: hvad hver position kan fastslå, og hvad den lader urørt.

Udfyld kun kæden, hvor du har adgang, og markér resten ukendt i stedet for at udlede den. Et hook, der registrerer pakker på én maskine, siger intet om, hvad den fjerne maskine modtog, og en loglinje, der noterer, at en anmodning blev set, er ikke bevis for, at et svar nogensinde forlod. Ærlige huller er mere nyttige end en post, der ser komplet ud og er bygget på gæt.

Find den første manglende overgang

Gå kæden fra initiatoren og udefter, og stop ved det første led uden evidens. Hvis gatewayen aldrig logger anmodningen, sidder fejlen på stien før den. Når gatewayen logger den samme anmodning gentagne gange, mens klienten aldrig logger et svar, er retningen tilbage den mistænkte: kildeadresse, oversættelse og filtrering ved hver grænse, du kontrollerer. Hvis svaret ankommer, og klienten stadig ikke kommer videre, har spørgsmålet forladt transporten og er blevet politik eller tilstand.

Hold peer'en og protokollen fast, mens du sammenligner, og husk, at forsinkelse, tab, politik og tilstand hver især giver en anden tidslinje. Et mobilt netværk er ikke automatisk årsagen, og en fast linje er ikke automatisk pålidelig nok til alle krav. Optag begge retninger, mens udvekslingen er live:

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

Når adgangen stopper før den fjerne ende, hjælper posten stadig, hvis den siger, hvor den stopper. En optagelse kun på initiatoren kan vise en anmodning, der forlader, og intet svar, der ankommer, hvilket indsnævrer fejlen til alt efter det hook uden at foregive at vide, hvilket hop der tabte den. Markér de fjerne led som ukendte, og lad den næste person med adgang udfylde dem. Sådan skrevet forbliver posten ærlig og stadig kort.

Sammenlign, før du ændrer noget. At gentage den samme anmodning mod den samme peer med den samme protokol holder variablene tællelige, mens en nulstilling, en nøglefornyelse eller en politikredigering mellem optagelser ødelægger sammenligningen. Hvis en ændring er uundgåelig, så optag igen umiddelbart efter, så før og efter stadig beskriver den samme udveksling.

Hvad en nyttig rapport siger

En rapport, der er værd at handle på, parrer én anmodning med dens svar og navngiver det første skridt, der ikke har evidens bag sig. Den sætning overlever at blive læst en uge senere af en ingeniør, der ikke var der, og den giver den næste person et sted at begynde i stedet for en mistænkt.

Svækk aldrig identitetskontroller eller udvid det tilladte protokolsæt bare for at kontrollere en gentransmissionsteori. Gem de originale pakker og hændelsesposter før enhver nulstilling, fordi en nulstilling ødelægger præcis det materiale, du var ved at indsamle, og sletter den timing, der viste, hvor udvekslingen gik i stå.

Myten er, at én dublet beviser, at en operatør har skylden. Virkeligheden er, at én dublet beviser, at en timer er udløbet, og svaret lever på svarvejen.