Dupliserte IKE-pakkar: finn den manglande overgangen

Loggen viser den same IKE-førespurnaden to gonger, nokon peikar på den mobile opplenka, og saka vert lukka med eit gjet. Det gjetet er myten: ein gjenteken pakke er ei observasjon om éi utveksling, ikkje ein diagnose av ei lenke. Retransmisjon er normal åtferd med eigne reglar, og han dukkar opp på sunne stiar kvar gong eit svar er tregt. Følg svaret før du gjev eit grensesnitt skulda.

Myten: ein gjenteken førespurnad beviser tap på éi lenke

To ulike ting lagar ein duplikat, og ingen av dei namngjev ein skuldig. Førespurnadaren kan gjenta ein førespurnad fordi han ikkje fekk noko svar, eller fangstpunktet kan vise same pakke to gonger på grunn av kvar det er kopla til stakken. Ein tap som ser inngåande og utgåande trafikk på same vert, loggar gjerne éin pakke som to, og operatøren som les den loggen har ingen måte å skilje dei utan utvekslingsidentifikatorane. Handsame duplikaten som ei timerhending til du kan seie kva for ein av dei to du held på.

To opplenker gjer forvirringa verre i staden for betre. Éi logglinje namngjev eitt grensesnitt, medan svaret kan ha gått ut gjennom det andre, så grensesnittet i meldinga skildrar kvar ein pakke vart sett og ikkje forma på samtalen. Difor er det første spørsmålet kva utveksling du ser på, ikkje kva lenke som er defekt.

Kva retransmisjonen faktisk fortel deg

I IKEv2 fungerer retransmisjon slik: førespurnadaren gjentek ein førespurnad når det ikkje har kome noko svar, og svararen kan senda det mellomlagra svaret sitt på nytt i staden for å rekne ut eit nytt. Meldingsidentifikatorar høyrer til den utvekslinga, og det er dette som gjer ein gjenteken førespurnad med same identifikator gjenkjenneleg som protokollen som arbeider, ikkje som eit nytt forsøk. Eit første forsøk treng ofte meir enn ei kjeldeadresse eller ein initiator-SPI for å korrelerast, så den eigne utvekslingsposta til plattforma slår ei pakkeliste. IKEv1 følgjer andre reglar med andre identifikatorar, og eit leverandørvarsel om ein duplisert første pakke tyder ikkje det same på tvers av versjonar.

Så eit retransmisjonstidsstempel fortel deg at ein timer er gått ut. Det fortel deg ikkje kva hopp som var tregt, og det fortel absolutt ikkje at operatøren har skulda. Det er separate påstandar, og berre den andre er nyttig i ei sak.

Den praktiske konsekvensen er å registrere utvekslinga før du dreg ein konklusjon. Noter den lokale mottaksadressa, svarvegen politikken valde, peer-tuplen og utvekslingsidentifikatorane på ein stad, fordi kvar av dei svarar på eit anna spørsmål når posten vert lesen seinare.

Fire observasjonspunkt som éi kjede

Tenk på utvekslinga som fire ledd i ei kjede i staden for fire separate stader å sjå. Eit ledd held evidens eller blir ukjent, og kjeda er berre så informativ som det svakaste registrerte leddet. Tabellen nedanfor er inventaret: kva kvar posisjon kan fastslå og kva han lèt vere urørt.

Fyll berre ut kjeda der du har tilgang, og merk resten som ukjend i staden for å slutte det. Ein krok som registrerer pakkar på éi maskin, seier ingenting om kva den fjerne maskina tok imot, og ei logglinje som noterer at ein førespurnad vart sett, er ikkje bevis for at eit svar nokon gong gjekk ut. Ærlege hol er meir nyttige enn ein post som ser komplett ut og er bygd på gjet.

Finn den første manglande overgangen

Gå kjeda frå initiatoren og utover, og stopp ved det første leddet utan evidens. Viss gatewayen aldri loggar førespurnaden, sit feilen på stien før han. Når gatewayen loggar same førespurnad om og om igjen medan klienten aldri loggar eit svar, er retninga tilbake den mistenkte: kjeldeadresse, omsetjing og filtrering ved kvar grense du kontrollerer. Viss svaret kjem og klienten framleis ikkje kjem vidare, har spørsmålet forlate transporten og vorte politikk eller tilstand.

Hald peeren og protokollen fast medan du samanliknar, og hugs at forseinking, tap, politikk og tilstand kvar gjev ei anna tidslinje. Eit mobilt nettverk er ikkje automatisk årsaka, og ei fast line er ikkje automatisk påliteleg nok for alle krav. Tak opp begge retningar medan utvekslinga er levande:

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

Når tilgangen stoppar før den fjerne enden, hjelper posten framleis viss han seier kvar han stoppar. Eit opptak berre på initiatoren kan vise ein førespurnad som går ut og ingen svar som kjem inn, noko som snevrar feilen til alt etter den kroken utan å late som vi veit kva hopp som sleppte han. Merk dei fjerne ledda som ukjende, og lat neste person med tilgang fylla dei ut. Skrive slik held posten seg ærleg og framleis kort.

Samanlikn før du endrar noko. Å gjenta same førespurnad mot same peer med same protokoll held variablane teljande, medan ein tilbakestilling, ein nøkkelregenerering eller ei politikkgransking mellom opptak øydelegg samanlikninga. Viss ei endring er uunngåeleg, tak opp att rett etterpå, slik at før og etter framleis skildrar same utveksling.

Kva ein nyttig rapport seier

Ein rapport som er verdt å handle på, parar éin førespurnad med svaret sitt og namngjev det første trinnet som ikkje har evidens bak seg. Den setninga toler å bli lesen ei veke seinare av ein ingeniør som ikkje var der, og ho gjev neste person ein stad å byrje i staden for ein mistenkt.

Svekk aldri identitetskontrollar eller utvid det tillatne protokollsettet berre for å sjekke ein retransmisjonsteori. Lagre dei originale pakkane og hendingspostane før kvar tilbakestilling, fordi ei tilbakestilling øydelegg nøyaktig materialet du var i ferd med å samle inn, og slettar timinga som viste kvar utvekslinga stoppa.

Myten er at éin duplikat beviser at ein operatør har skulda. Røyndomen er at éin duplikat beviser at ein timer er gått ut, og svaret lever på svarvegen.