Dupliserte IKE-pakker: finn den manglende overgangen

Loggen viser den samme IKE-forespørselen to ganger, noen peker på den mobile opplenken, og saken lukkes med en gjetning. Den gjetningen er myten: en gjentatt pakke er en observasjon om én utveksling, ikke en diagnose av en lenke. Retransmisjon er normal atferd med egne regler, og den dukker opp på sunne stier hver gang et svar er tregt. Følg svaret før du gir et grensesnitt skylden.

Myten: en gjentatt forespørsel beviser tap på én lenke

To forskjellige ting lager en duplikat, og ingen av dem navngir en skyldig. Forespørreren kan gjenta en forespørsel fordi den ikke fikk noe svar, eller fangstpunktet kan vise samme pakke to ganger på grunn av hvor det er koblet til stakken. En tap som ser inngående og utgående trafikk på samme vert, logger gjerne én pakke som to, og operatøren som leser den loggen har ingen måte å skille dem uten utvekslingsidentifikatorene. Behandle duplikaten som en timerhendelse til du kan si hvilken av de to du holder på.

To opplenker gjør forvirringen verre i stedet for bedre. Én logglinje navngir ett grensesnitt, mens svaret kan ha gått ut gjennom det andre, så grensesnittet i meldingen beskriver hvor en pakke ble sett og ikke samtalens form. Derfor er det første spørsmålet hvilken utveksling du ser på, ikke hvilken lenke som er defekt.

Hva retransmisjonen faktisk forteller deg

I IKEv2 fungerer retransmisjon slik: forespørreren gjentar en forespørsel når det ikke har kommet noe svar, og svareren kan sende sitt mellomlagrede svar på nytt i stedet for å regne ut et nytt. Meldingsidentifikatorer hører til den utvekslingen, og det er dette som gjør en gjentatt forespørsel med samme identifikator gjenkjennelig som protokollen som arbeider, ikke som et nytt forsøk. Et første forsøk trenger ofte mer enn en kildeadresse eller en initiator-SPI for å korreleres, så plattformens egen utvekslingspost slår en pakkeliste. IKEv1 følger andre regler med andre identifikatorer, og en leverandøradvarsel om en duplisert første pakke betyr ikke det samme på tvers av versjoner.

Så et retransmisjonstidsstempel forteller deg at en timer er utløpt. Det forteller deg ikke hvilket hopp som var tregt, og det forteller absolutt ikke at operatøren har skylden. Det er separate påstander, og bare den andre er nyttig i en sak.

Den praktiske konsekvensen er å registrere utvekslingen før du trekker en konklusjon. Noter den lokale mottaksadressen, svarveien politikken valgte, peer-tuplen og utvekslingsidentifikatorene på ett sted, fordi hver av dem svarer på et annet spørsmål når posten leses senere.

Fire observasjonspunkter som én kjede

Tenk på utvekslingen som fire ledd i en kjede i stedet for fire separate steder å se. Et ledd holder evidens eller forblir ukjent, og kjeden er bare så informativ som det svakeste registrerte leddet. Tabellen nedenfor er inventaret: hva hver posisjon kan fastslå og hva den lar være urørt.

Fyll bare ut kjeden der du har tilgang, og merk resten som ukjent i stedet for å utlede det. En krok som registrerer pakker på én maskin, sier ingenting om hva den fjerne maskinen mottok, og en logglinje som noterer at en forespørsel ble sett, er ikke bevis for at et svar noen gang gikk ut. Ærlige hull er mer nyttige enn en post som ser komplett ut og er bygget på gjetninger.

Finn den første manglende overgangen

Gå kjeden fra initiatoren og utover, og stopp ved det første leddet uten evidens. Hvis gatewayen aldri logger forespørselen, sitter feilen på stien før den. Når gatewayen logger samme forespørsel om og om igjen mens klienten aldri logger et svar, er retningen tilbake den mistenkte: kildeadresse, oversettelse og filtrering ved hver grense du kontrollerer. Hvis svaret ankommer og klienten fortsatt ikke kommer videre, har spørsmålet forlatt transporten og blitt politikk eller tilstand.

Hold peeren og protokollen fast mens du sammenligner, og husk at forsinkelse, tap, politikk og tilstand hver gir en annen tidslinje. Et mobilt nettverk er ikke automatisk årsaken, og en fast linje er ikke automatisk pålitelig nok for alle krav. Ta opp begge retninger mens utvekslingen er levende:

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

Når tilgangen stopper før den fjerne enden, hjelper posten fortsatt hvis den sier hvor den stopper. Et opptak kun på initiatoren kan vise en forespørsel som går ut og ingen svar som kommer inn, noe som snevrer feilen til alt etter den kroken uten å late som vi vet hvilket hopp som slapp den. Merk de fjerne leddene som ukjente, og la neste person med tilgang fylle dem ut. Skrevet slik forblir posten ærlig og fortsatt kort.

Sammenlign før du endrer noe. Å gjenta samme forespørsel mot samme peer med samme protokoll holder variablene tellbare, mens en tilbakestilling, en nøkkelregenerering eller en politikredigering mellom opptak ødelegger sammenligningen. Hvis en endring er uunngåelig, ta opp igjen rett etterpå, slik at før og etter fortsatt beskriver samme utveksling.

Hva en nyttig rapport sier

En rapport som er verdt å handle på, parer én forespørsel med svaret sitt og navngir det første trinnet som ikke har evidens bak seg. Den setningen tåler å bli lest en uke senere av en ingeniør som ikke var der, og den gir neste person et sted å begynne i stedet for en mistenkt.

Svek aldri identitetskontroller eller utvid det tillatte protokollsettet bare for å sjekke en retransmisjonsteori. Lagre de originale pakkene og hendelsespostene før enhver tilbakestilling, fordi en tilbakestilling ødelegger nøyaktig materialet du var i ferd med å samle inn, og sletter timingen som viste hvor utvekslingen stoppet.

Myten er at én duplikat beviser at en operatør har skylden. Virkeligheten er at én duplikat beviser at en timer er utløpt, og svaret lever på svarveien.