Hoe't de earste IKEv2-útwikseling yn in pakketopname lêzen wurdt

Opnamen midden yn in sesje binne de gewoane reden dat in IKEv2-spoar as lûd liket, om't de partijen al kaaien fernije of fersifere ladingen útwikselje as de opname begjint. Begjin ynstee mei in nij ferbiningsbesykjen, sadat it earste berjocht yn it bestân datjinge is dat de ûnderhanneling iepenet. De lêsfolchoarder hjirûnder giet dêrfan út en markearret it punt dêr't in pakket ophâldt eat oer de fiere kant te bewizen. It oerslaan fan dy stap is hoe't in wurkjende tunnel as in blokkearre poarte diagnostisearre wurdt.

Befêstigje dat jo nei de iepeningsútwikseling sjogge

In IKEv2-ûnderhanneling begjint mei IKE_SA_INIT, útwikselingstype 34, berjocht-ID 0. De inisjatyfnimmer kiest in SPI dy't net nul is, en de SPI fan 'e beäntwurder is nul yn dat earste fersyk en net nul yn it antwurd. Dy trije feiten skiede in nij besykjen fan in kaaifernijing of fan in IKE_AUTH-berjocht dat tafallich boppe-oan in opname stiet.

De koptekstfjilden binne lêsber, en dat jilde ek foar de foarstel-, kaai-útwikseling- en nonce-ladingen. Lêsber is net autentisearre: gjin fan beide partijen hat op dit punt identiteit bewiisd, en de priveewearde fan Diffie-Hellman ferskynt nea op 'e tried.

Print de fjilden as in tabel ynstee fan troch in dekodaasjepaniel te rôljen, om't werhellings en SPI's dy't net oerienkomme in kolommen dúdlik wurde.

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

Lês de útfier yn pearen. In fersyk mei berjocht-ID 0 folge troch in antwurd mei deselde ID en in net-nul beäntwurder-SPI is ien útwikseling, sels as it trije kear ferskynt om't it fersyk op 'e nij stjoerd is. Trije identike fersiken binne gjin trije oanmeldingen, en se sa behannelje is hoe't minsken konkludearje dat in klant yn in loope sit wylst er allinnich geduldich is. Sortearje op berjocht-ID, dan op tiidstimpel, en it hiele petear krimpt ta in koarte list fan besykjen.

Lês in ôfwizing foar't jo in súkses lêze

In antwurd is net automatysk foarútgong. De beäntwurder kin antwurdzje mei in cookie-notifikaasje en ferwachtsje dat de inisjatyfnimmer it op 'e nij besiket, of mei INVALID_KE_PAYLOAD dat in groep neamt dy't er leaver akseptearret. Beide komme as goed foarme IKE-berjochten, en beide lykje op in ôfmakke útwikseling foar in filter dat allinnich pakketten telt.

Iepenje de notifikaasjelading en lês it type foar al it oare. In cookie-útdaging betsjut dat de beäntwurder him ferdigenet tsjin ferfalske boarneadressen, en de klant moat op 'e nij stjoere mei de cookie derby. In ûnjildige groep betsjut dat de beide foarstellen net oerienkomme, wat gjin hoemannichte werheljen feroarje sil oant de konfiguraasje fan ien kant beweecht.

Allinnich IKE_AUTH, de twadde útwikseling, draacht de fersifere identiteit en de autentikaasjeladingen. In foltôge IKE_SA_INIT fertelt jo dus dat de partijen it iens binne oer algoritmen en ôflate kaaien, en hielendal neat oer de fraach oft de oanmeldgegevens akseptearre wurde. Ferwachtsje dêr ek twa berjochten, en ferwachtsje dat beide ûntrochsichtig binne sûnder de sesjekaaien.

Poarte 4500 is net ien protokol

UDP 500 draacht meastentiids de iepeningsútwikseling. Sadree't NAT-deteksje rûn hat, ferhuist IKE nei 4500 en set in nulmarkearring fan fjouwer bytes foar elk berjocht dy't gjin ESP is. Ynkapsulearre ESP op deselde poarte begjint ynstee mei in net-nul ESP-SPI, en in NAT-keepalive fan ien byte is in tredde foarm dy't ferskynt as der fierders neat bart.

In filter dat allinnich de poarte oerienkomt mjuksket alle trije, en dêrom beslist "der is ferkear op 4500" sa min. Diel it byld op protokol foar't jo eat oer de fiere kant konkludearje.

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

Stilte beskriuwt it waarnimmingspunt

Fersiken sûnder antwurden fêstigje krekt ien ding: op dat opnamepunt ferskynde gjin antwurd. Filterjen, in rûte dy't it antwurd earne oars hinne stjoert, in ûnberikbere beäntwurder of in beäntwurder dy't it foarstel net lije mei, jouwe allegear itselde lege resultaat, en in algemiene UDP-proef sil se net skiede.

In ICMP-ûnberikberens is bewiis fan in oare soarte. Lês it sitearre pakket deryn en identifisearje hokker apparaat it útstjoerd hat, om't de bestjoerlike ôfwizing fan in router gjin autentisearre flater fan 'e fiere kant is.

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

Korrelaasje deselde besykjen mei logboeken oan 'e serverkant dêr't jo se lêze meie. Kaam it fersyk oan, antwurde de tsjinst, en wêr hold it antwurd op? Dy trije antwurden stjoere jo nei in paadprobleem of nei in beliedsprobleem, en se kostje minder as it fjirde kear rotearjen fan oanmeldgegevens.