Hogyan olvassuk az első IKEv2-cserét egy csomagrögzítésben

A munkamenet közepén készült rögzítések a szokásos oka annak, hogy egy IKEv2-nyom zajnak tűnik, mert a felek már kulcsokat újítanak vagy titkosított hasznos terhelést cserélnek, amikor a felvétel elkezdődik. Kezdje inkább egy friss kapcsolódási kísérlettel, hogy a fájl első üzenete az legyen, amely megnyitja az egyeztetést. Az alábbi olvasási sorrend ezt feltételezi, és megjelöli azt a pontot, ahol egy csomag már semmit sem bizonyít a távoli oldalról. Ennek a lépésnek a kihagyása az, ahogyan egy működő alagút blokkolt portként diagnosztizálódik.

Erősítse meg, hogy a nyitó cserét látja

Az IKEv2 egyeztetés IKE_SA_INIT-tal kezdődik, 34-es cserefajtával, 0-s üzenetazonosítóval. A kezdeményező nullától eltérő SPI-t választ, a válaszadó SPI-je pedig nulla ebben az első kérésben és nullától eltérő a válaszban. Ez a három tény választja el a friss kísérletet a kulcsújítástól vagy egy olyan IKE_AUTH üzenettől, amely véletlenül egy rögzítés tetején van.

A fejlécmezők olvashatók, valamint a javaslat, a kulcscsere és a nonce hasznos terhelései is. Az olvashatóság nem hitelesítés: egyik fél sem bizonyította a személyazonosságát ezen a ponton, és a Diffie-Hellman privát értéke soha nem jelenik meg a vonalon.

Táblázatként írja ki a mezőket a dekódolópanel görgetése helyett, mert az újraküldések és a nem illeszkedő SPI-k oszlopokban nyilvánvalóvá válnak.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Páronként olvassa a kimenetet. Egy 0-s üzenetazonosítójú kérés, amelyet ugyanazt az azonosítót és nullától eltérő válaszadó SPI-t hordozó válasz követ, egyetlen csere, még akkor is, ha háromszor jelenik meg, mert a kérést újraküldték. Három azonos kérés nem három bejelentkezés, és ha így kezeljük őket, abból a következtetésből lesz, hogy egy kliens hurkol, miközben csak türelmes. Rendezze üzenetazonosító, majd időbélyeg szerint, és az egész beszélgetés rövid kísérletlistává zsugorodik.

Előbb olvassa el az elutasítást, mint a sikert

Egy válasz nem automatikusan előrelépés. A válaszadó válaszolhat cookie-értesítéssel, és várhatja, hogy a kezdeményező újra próbálkozzon, vagy INVALID_KE_PAYLOAD-dal megnevezve egy csoportot, amelyet inkább elfogadna. Mindkettő szabályosan formált IKE-üzenetként érkezik, és mindkettő befejezett cserének tűnik egy csak csomagokat számláló szűrő számára.

Nyissa meg az értesítés hasznos terhelését, és mindenekelőtt a típust olvassa el. A cookie-kihívás azt jelenti, hogy a válaszadó a hamisított forrás címek ellen védekezik, és a kliensnek a cookie-t csatolva újra kell küldenie. Az érvénytelen csoport azt jelenti, hogy a két javaslat nem egyezik, amit semmilyen újrapróbálkozás nem változtat meg, amíg az egyik fél konfigurációja el nem mozdul.

Csak az IKE_AUTH, a második csere hordozza a titkosított személyazonosságot és a hitelesítési hasznos terheléseket. Egy befejezett IKE_SA_INIT tehát azt mondja meg, hogy a felek egyetértenek az algoritmusokban és a származtatott kulcsokban, és semmit arról, hogy a hitelesítő adatokat elfogadják-e. Ott is várjon két üzenetet, és várja, hogy mindkettő átláthatatlan legyen a munkamenetkulcsok nélkül.

A 4500-as port nem egyetlen protokoll

A nyitó cserét általában az UDP 500 szállítja. Miután a NAT-felderítés lefutott, az IKE átvált a 4500-ra, és minden üzenet elé egy négybájtos nulla, nem ESP jelölőt tesz. Ugyanazon a porton a beágyazott ESP ehelyett nullától eltérő ESP SPI-vel kezdődik, az egybájtos NAT-keepalive pedig egy harmadik forma, amely akkor jelenik meg, amikor semmi más nem történik.

A csak a portra illeszkedő szűrő mindhármat összekeveri, ezért dönt el olyan keveset, hogy "van forgalom a 4500-on". Protokoll szerint bontsa fel a nézetet, mielőtt bármit megállapítana a távoli oldalról.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

A csend a megfigyelési pontot írja le

A válasz nélküli kérések pontosan egy dolgot bizonyítanak: azon a rögzítési ponton nem jelent meg válasz. A szűrés, a választ máshová küldő útvonal, az elérhetetlen válaszadó vagy a javaslatot nem kedvelő válaszadó mind ugyanazt az üres eredményt adja, és egy általános UDP-próba nem választja szét őket.

Az ICMP elérhetetlenség másfajta bizonyíték. Olvassa el a benne idézett csomagot, és állapítsa meg, melyik eszköz bocsátotta ki, mert egy útválasztó adminisztratív elutasítása nem a távoli oldal hitelesített hibája.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Korrelálja ugyanazt a kísérletet a kiszolgálóoldali naplókkal ott, ahol van engedélye olvasni őket. Megérkezett-e a kérés, válaszolt-e a szolgáltatás, és hol állt meg a válasz? Ez a három válasz útvonalproblémához vagy házirendproblémához küldi, és kevesebbe kerül, mint a hitelesítő adatok negyedik cseréje.