Kuidas lugeda esimest IKEv2-vahetust paketikogumikus

Sessiooni keskel tehtud kokkuvõtted on tavaline põhjus, miks IKEv2 jälg mürana tundub, sest pooled juba uuendavad võtmeid või vahetavad krüpteeritud kasulikku koormust, kui salvestamine algab. Alustage selle asemel värskest ühenduskatsest, et faili esimene sõnum oleks see, mis läbirääkimised avab. Alljärgnev lugemisjärjekord eeldab seda ja märgib punkti, kus pakett lakkab kaugema poole kohta midagi tõestamast. Just selle sammu vahelejätmine viib selleni, et töötav tunnel diagnoositakse blokeeritud pordina.

Kinnitage, et vaatate avavahetust

IKEv2 läbirääkimine algab IKE_SA_INIT-iga, vahetuse tüüp 34, sõnumi ID 0. Algataja valib nullist erineva SPI ning vastaja SPI on selles esimeses päringus null ja vastuses nullist erinev. Need kolm fakti eristavad värsket katset võtmeuuendusest või IKE_AUTH sõnumist, mis juhtub olema kokkuvõtte tipus.

Päise väljad on loetavad, samuti pakkumise, võtmevahetuse ja nonce'i koormused. Loetav ei tähenda autenditud: kumbki pool ei ole selles punktis identiteeti tõestanud ning Diffie-Hellmani privaatväärtus ei ilmu kunagi juhtmel.

Printige väljad tabelina, mitte kerige dekodeerimispaneelis, sest kordussaadetised ja sobimatud SPI-d muutuvad veergudes ilmselgeks.

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

Lugege väljundit paarikaupa. Päring sõnumi ID-ga 0, millele järgneb vastus sama ID ja nullist erineva vastaja SPI-ga, on üks vahetus, isegi kui see ilmub kolm korda, sest päring saadeti uuesti. Kolm identset päringut ei ole kolm sisselogimist, ja nii koheldes jõutakse järeldusele, et klient keerleb tsüklis, kuigi ta on lihtsalt kannatlik. Sortige sõnumi ID, seejärel ajatempli järgi ja kogu vestlus taandub lühikeseks katsete loendiks.

Lugege keeldumist enne, kui loete õnnestumist

Vastus ei ole automaatselt edasiminek. Vastaja võib vastata cookie-teatega ja oodata, et algataja proovib uuesti, või INVALID_KE_PAYLOAD-iga, mis nimetab grupi, mille ta selle asemel vastu võtaks. Mõlemad saabuvad korrektselt vormindatud IKE sõnumitena ja mõlemad näivad lõpetatud vahetusena filtril, mis loeb ainult pakette.

Avage teate koormus ja lugege tüüpi enne kõike muud. Cookie-väljakutse tähendab, et vastaja kaitseb end võltsitud lähteaadresside eest ning klient peab saatma uuesti cookie'ga. Kehtetu grupp tähendab, et kaks pakkumist ei ühti, mida ei muuda ükski korduskatsete arv enne, kui ühe poole konfiguratsioon liigub.

Ainult IKE_AUTH, teine vahetus, kannab krüpteeritud identiteedi ja autentimiskoormused. Lõpetatud IKE_SA_INIT ütleb seega, et pooled on algoritmides ja tuletatud võtmetes ühel meelel, ja mitte midagi selle kohta, kas volitused vastu võetakse. Oodake ka seal kahte sõnumit ja oodake, et mõlemad on ilma sessioonivõtmeteta läbipaistmatud.

Port 4500 ei ole üks protokoll

Avavahetust kannab tavaliselt UDP 500. Kui NAT-tuvastus on käivitunud, liigub IKE pordile 4500 ja paneb iga sõnumi ette neljabaidise null-markeriga, mis ei ole ESP. Kapseldatud ESP samal pordil algab seevastu nullist erineva ESP SPI-ga ning ühebaidine NAT-keepalive on kolmas kuju, mis ilmub siis, kui midagi muud ei toimu.

Ainult porti sobiv filter segab kõik kolm, mistõttu "pordil 4500 on liiklust" otsustab nii vähe. Jagage vaade protokolli järgi enne, kui kaugema poole kohta midagi järeldate.

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

Vaikus kirjeldab vaatluspunkti

Vastusteta päringud tõestavad täpselt ühte: selles kokkuvõtte punktis ei ilmunud ühtki vastust. Filtreerimine, vastuse mujale saatmine, kättesaamatu vastaja või vastaja, kellele pakkumine ei meeldi, annavad kõik sama tühja tulemuse ning üldine UDP-proov neid ei erista.

ICMP kättesaamatus on teist liiki tõend. Lugege selle sees tsiteeritud paketti ja tehke kindlaks, milline seade selle väljastas, sest ruuteri administratiivne keeldumine ei ole kaugemalt poolelt tulnud autenditud viga.

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

Korreleerige sama katse serveripoolsete logidega seal, kus teil on lubatud neid lugeda. Kas päring saabus, kas teenus vastas ja kuhu vastus lõppes? Need kolm vastust suunavad teid tee- või poliitikaprobleemi juurde ning need maksavad vähem kui volituste neljas vahetus.