Kaip skaityti pirmąjį IKEv2 mainą paketų fiksavime

Įrašai, padaryti sesijos viduryje, yra įprasta priežastis, kodėl IKEv2 pėdsakas atrodo kaip triukšmas, nes šalys jau atnaujina raktus arba keičiasi šifruotomis apkrovomis, kai prasideda įrašymas. Verčiau pradėkite nuo naujo prisijungimo bandymo, kad pirmasis pranešimas byloje būtų tas, kuris atveria derybas. Toliau pateikta skaitymo tvarka tai numato ir pažymi tašką, kuriame paketas nustoja ką nors įrodyti apie tolimąjį galą. Būtent šio žingsnio praleidimas lemia, kad veikiantis tunelis diagnozuojamas kaip užblokuotas prievadas.

Įsitikinkite, kad matote pradinį mainą

IKEv2 derybos prasideda IKE_SA_INIT, mainų tipu 34, pranešimo ID 0. Iniciatorius pasirenka ne nulinį SPI, o atsakiklio SPI tame pirmame prašyme yra nulis, o atsakyme – ne nulis. Šie trys faktai atskiria naują bandymą nuo raktų atnaujinimo arba nuo IKE_AUTH pranešimo, kuris atsitiktinai yra fiksavimo viršuje.

Antraštės laukai yra skaitomi, kaip ir pasiūlymo, raktų mainų bei nonce apkrovos. Skaitoma nereiškia autentifikuota: nė viena šalis šiuo metu neįrodė tapatybės, o privati Diffie-Hellman reikšmė niekada nepasireiškia linijoje.

Spausdinkite laukus kaip lentelę, o ne slinkite dekodavimo sritimi, nes pakartotiniai siuntimai ir nesutampantys SPI tampa akivaizdūs stulpeliuose.

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

Skaitykite išvestį poromis. Prašymas su pranešimo ID 0, po kurio eina atsakymas su tuo pačiu ID ir ne nuliniu atsakiklio SPI, yra vienas mainas, net jei jis pasirodo tris kartus, nes prašymas buvo persiųstas. Trys vienodi prašymai nėra trys prisijungimai, ir būtent taip traktuojant daroma išvada, kad klientas sukasi cikle, kai jis tik kantrus. Rikiuokite pagal pranešimo ID, paskui pagal laiko žymą, ir visas pokalbis susitraukia į trumpą bandymų sąrašą.

Perskaitykite atmetimą anksčiau nei sėkmę

Atsakymas nėra automatiškai pažanga. Atsakiklis gali atsakyti cookie pranešimu ir tikėtis, kad iniciatorius bandys dar kartą, arba INVALID_KE_PAYLOAD, nurodydamas grupę, kurią mieliau priimtų. Abu atkeliauja kaip taisyklingi IKE pranešimai, ir abu atrodo kaip baigtas mainas filtrui, kuris tik skaičiuoja paketus.

Atidarykite pranešimo apkrovą ir visų pirma perskaitykite tipą. Cookie iššūkis reiškia, kad atsakiklis ginasi nuo suklastotų šaltinio adresų, ir klientas turi siųsti iš naujo pridėjęs cookie. Negaliojanti grupė reiškia, kad du pasiūlymai nesutampa, ir to nepakeis joks pakartojimų skaičius, kol nepasislinks vienos pusės konfigūracija.

Tik IKE_AUTH, antrasis mainas, neša šifruotą tapatybę ir autentifikavimo apkrovas. Taigi baigtas IKE_SA_INIT pasako, kad šalys sutaria dėl algoritmų ir išvestinių raktų, ir visiškai nieko apie tai, ar kredencialai bus priimti. Tikėkitės ir ten dviejų pranešimų, ir tikėkitės, kad abu bus nepermatomi be sesijos raktų.

Prievadas 4500 nėra vienas protokolas

Pradinį mainą paprastai neša UDP 500. Kai įvyksta NAT aptikimas, IKE persikelia į 4500 ir prieš kiekvieną pranešimą įterpia keturių baitų nulinį ne ESP žymeklį. Inkapsuliuotas ESP tame pačiame prievade prasideda ne nuliniu ESP SPI, o vieno baito NAT keepalive yra trečioji forma, pasirodanti, kai nieko kito nevyksta.

Filtras, kuris atitinka tik prievadą, sumaišo visus tris, todėl "4500 prievade yra srauto" nusprendžia taip mažai. Atskirkite vaizdą pagal protokolą, prieš darydami išvadas apie tolimąjį galą.

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

Tyka apibūdina stebėjimo tašką

Prašymai be atsakymų nustato lygiai vieną dalyką: tame fiksavimo taške joks atsakymas nepasirodė. Filtravimas, maršrutas, siunčiantis atsakymą kitur, nepasiekiamas atsakiklis arba atsakiklis, kuriam nepatinka pasiūlymas, duoda tą patį tuščią rezultatą, ir bendra UDP patikra jų neatskirs.

ICMP nepasiekiamumas yra kitokio pobūdžio įrodymas. Perskaitykite jame cituojamą paketą ir nustatykite, kuris įrenginys jį išleido, nes maršrutizatoriaus administracinis atmetimas nėra autentifikuota tolimojo galo klaida.

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

Susiekite tą patį bandymą su serverio pusės žurnalais ten, kur jums leidžiama juos skaityti. Ar prašymas atėjo, ar paslauga atsakė ir kur atsakymas sustojo? Tie trys atsakymai nukreipia jus į maršruto problemą arba į politikos problemą, ir jie kainuoja mažiau nei ketvirtas kredencialų keitimas.