Kiel legi la unuan IKEv2-interŝanĝon en paketa kaptaĵo

Kaptaĵoj faritaj meze de sesio estas la kutima kaŭzo, ke IKEv2-spuro aspektas kiel bruo, ĉar la flankoj jam ŝanĝas ŝlosilojn aŭ interŝanĝas ĉifritajn ŝarĝojn, kiam la registrado komenciĝas. Komencu anstataŭe per nova konekta provo, por ke la unua mesaĝo en la dosiero estu tiu, kiu malfermas la intertraktadon. La legordo sube supozas tion, kaj ĝi markas la punkton, kie paketo ĉesas pruvi ion ajn pri la malproksima flanko. Preterlasi tiun paŝon estas kiel funkcianta tunelo diagnoziĝas kiel blokita pordo.

Konfirmu, ke vi rigardas la malferman interŝanĝon

IKEv2-intertraktado komenciĝas per IKE_SA_INIT, interŝanĝa tipo 34, mesaĝa identigilo 0. La iniciatinto elektas ne-nulan SPI, kaj la SPI de la respondanto estas nulo en tiu unua peto kaj ne-nulo en la respondo. Tiuj tri faktoj apartigas novan provon de ŝlosila renovigo aŭ de IKE_AUTH-mesaĝo, kiu hazarde staras ĉe la supro de kaptaĵo.

La kampoj de la kaplinio estas legeblaj, kaj ankaŭ la ŝarĝoj de propono, ŝlosila interŝanĝo kaj nonce. Legebla ne signifas aŭtentikigita: neniu el la flankoj pruvis identecon ĉe tiu punkto, kaj la privata valoro de Diffie-Hellman neniam aperas sur la drato.

Presu la kampojn kiel tabelon anstataŭ rulumi tra malkoda panelo, ĉar retransmetoj kaj malkongruaj SPI-oj fariĝas evidentaj en kolumnoj.

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

Legu la eligon laŭ paroj. Peto kun mesaĝa identigilo 0, sekvata de respondo kun la sama identigilo kaj ne-nula respondanta SPI, estas unu interŝanĝo, eĉ kiam ĝi aperas tri fojojn ĉar la peto estis retransmetita. Tri identaj petoj ne estas tri ensalutoj, kaj trakti ilin tiel estas kiel homoj konkludas, ke kliento rondiras, kiam ĝi nur estas pacienca. Ordigi laŭ mesaĝa identigilo, poste laŭ tempindiko, kaj la tuta konversacio kunfalas en mallongan liston de provoj.

Legu malakcepton antaŭ ol legi sukceson

Respondo ne estas aŭtomate progreso. La respondanto povas respondi per cookie-sciigo kaj atendi, ke la iniciatinto reprovu, aŭ per INVALID_KE_PAYLOAD nomante grupon, kiun ĝi akceptus anstataŭe. Ambaŭ alvenas kiel bone formitaj IKE-mesaĝoj, kaj ambaŭ aspektas kiel finita interŝanĝo por filtrilo, kiu nur kalkulas pakojn.

Malfermu la sciigan ŝarĝon kaj legu la tipon antaŭ ĉio alia. Cookie-defio signifas, ke la respondanto defendas sin kontraŭ falsitaj fontadresoj, kaj la kliento devas resendi kun la cookie alkroĉita. Nevalida grupo signifas, ke la du proponoj malkongruas, kion neniu kvanto da reprovoj ŝanĝos, ĝis la agordo de unu flanko moviĝos.

Nur IKE_AUTH, la dua interŝanĝo, portas la ĉifritan identecon kaj la aŭtentikigajn ŝarĝojn. Kompletigita IKE_SA_INIT do diras al vi, ke la flankoj konsentas pri algoritmoj kaj derivitaj ŝlosiloj, kaj tute nenion pri tio, ĉu la legitimiloj estos akceptitaj. Atendu ankaŭ du mesaĝojn tie, kaj atendu, ke ambaŭ estos maldiafanaj sen la sesiaj ŝlosiloj.

Pordo 4500 ne estas unu protokolo

UDP 500 kutime portas la malferman interŝanĝon. Post kiam NAT-detekto rulis, IKE transiras al 4500 kaj antaŭmetas al ĉiu mesaĝo kvar-bajtan nulan markilon, kiu ne estas ESP. Enkapsuligita ESP sur la sama pordo komenciĝas anstataŭe per ne-nula ESP-SPI, kaj unu-bajta NAT-keepalive estas tria formo, kiu aperas, kiam nenio alia okazas.

Filtrilo, kiu kongruas nur la pordon, miksas ĉiujn tri, kaj tial "estas trafiko ĉe 4500" decidas tiel malmulte. Dividu la vidon laŭ protokolo antaŭ ol konkludi ion pri la malproksima flanko.

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

Silento priskribas la observan punkton

Peto sen respondo starigas precize unu aferon: ĉe tiu kapta punkto ne aperis respondo. Filtrado, itinero, kiu sendas la respondon aliloken, neatingebla respondanto aŭ respondanto, kiu malŝatas la proponon, ĉiuj produktas la saman malplenan rezulton, kaj ĝenerala UDP-sondo ne disigos ilin.

ICMP-neatingeblo estas pruvo de alia speco. Legu la cititan paketon ene de ĝi kaj identigu, kiu aparato ĝin elsendis, ĉar administra malakcepto de enkursigilo ne estas aŭtentikigita eraro de la malproksima flanko.

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

Kunrilatu la saman provon kun servilflankaj protokoloj, kie vi rajtas legi ilin. Ĉu la peto alvenis, ĉu la servo respondis, kaj kie la respondo haltis? Tiuj tri respondoj sendas vin al voja problemo aŭ al politika problemo, kaj ili kostas malpli ol rotacii legitimilojn kvaran fojon.