Slik les du den første IKEv2-utvekslinga i eit pakkeopptak

Opptak midt i ei økt er den vanlege grunnen til at eit IKEv2-spor ser ut som støy, fordi partane alt fornyar nøklar eller byter krypterte nyttelaster når opptaket byrjar. Start i staden med eit ferskt tilkoplingsforsøk, slik at den første meldinga i fila er den som opnar forhandlinga. Leserekkjefølgja nedanfor føreset det og markerer punktet der ei pakke sluttar å prove noko om den fjerne enden. Det er nettopp dette trinnet som blir hoppa over når ein fungerande tunnel blir diagnostisert som ein blokkert port.

Stadfest at du ser på opningsutvekslinga

Ei IKEv2-forhandling byrjar med IKE_SA_INIT, utvekslingstype 34, meldings-ID 0. Initiativtakaren vel ein SPI som ikkje er null, og SPI-en til svararen er null i den første førespurnaden og ikkje-null i svaret. Desse tre fakta skil eit ferskt forsøk frå ei nøkkelfornying eller frå ei IKE_AUTH-melding som tilfeldigvis ligg øvst i eit opptak.

Hovudfelte er lesbare, og det same gjeld forslags-, nøkkelutvekslings- og nonce-nyttelastane. Lesbart er ikkje autentisert: ingen av partane har prova identitet på dette punktet, og den private verdien til Diffie-Hellman dukkar aldri opp på linja.

Skriv ut felta som ein tabell i staden for å rulle gjennom eit avkodingspanel, fordi gjenutsendingar og SPI-ar som ikkje passar blir tydelege i kolonnar.

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

Les utdata i par. Ein førespurnad med meldings-ID 0 etterfølgd av eit svar med same ID og ein svarar-SPI som ikkje er null, er éi utveksling, sjølv når ho dukkar opp tre gonger fordi førespurnaden vart send på nytt. Tre identiske førespurnader er ikkje tre innloggingar, og handsamar ein dei slik, konkluderer ein at ein klient går i løkke medan han berre er tolmodig. Sorter etter meldings-ID og deretter etter tidsstempel, og heile samtalen krympar til ei kort liste over forsøk.

Les eit avslag før du les ein suksess

Eit svar er ikkje automatisk framgang. Svararen kan svare med ei cookie-varsling og vente på at initiativtakaren prøver igjen, eller med INVALID_KE_PAYLOAD som nemner ei gruppe han heller vil godta. Begge kjem inn som velforma IKE-meldingar, og begge ser ut som ei avslutta utveksling for eit filter som berre tel pakkar.

Opne varselnyttelasta og les typen før alt anna. Ei cookie-utfordring betyr at svararen forsvarte seg mot forfalska kjeldeadresser, og klienten må sende på nytt med cookien vedlagt. Ei ugyldig gruppe betyr at dei to forslaga er usamde, noko ingen mengd nye forsøk endrar før konfigurasjonen på den eine sida flyttar seg.

Berre IKE_AUTH, den andre utvekslinga, ber den krypterte identiteten og autentiseringsnyttelastane. Ein fullført IKE_SA_INIT fortel deg derfor at partane er samde om algoritmar og avleidde nøklar, og absolutt ingenting om koreis påloggingsinformasjonen blir godteken. Vent også to meldingar der, og vent at begge er ugjennomsiktige utan øktnøklane.

Port 4500 er ikkje éin protokoll

UDP 500 ber vanlegvis opningsutvekslinga. Når NAT-registreringa har køyrt, flyttar IKE til 4500 og set ein firebyte nullmarkør som ikkje er ESP framfor kvar melding. Innkapsla ESP på same porten byrjar i staden med ein ESP-SPI som ikkje er null, og ein NAT-keepalive på éin byte er ein tredje form som dukkar opp når ingenting anna skjer.

Eit filter som berre matchar porten blandar alle tre, og difor avgjer "det er trafikk på 4500" så lite. Del visninga etter protokoll før du konkluderer noko om den fjerne enden.

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

Stillheit skildrar observasjonspunktet

Førespurnader utan svar fastslår nøyaktig éin ting: på det opptakspunktet dukka det ikkje opp noko svar. Filtrering, ei rute som sender svaret ein annan stad, ein utilgjengeleg svarar eller ein svarar som ikkje likar forslaget gir alle same tome resultat, og ein generisk UDP-test vil ikkje skilje dei.

Ein ICMP-unreachable er prov av ein annan type. Les den siterte pakka inni han og finn ut kva eining som sendte han, fordi ei administrativ avvising frå ein rutar ikkje er ein autentisert feil frå den fjerne enden.

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

Korreler det same forsøket med tenarside-loggar der du har lov til å lese dei. Kom førespurnaden fram, svara tenesta, og kvar stoppa svaret? Dei tre svara sender deg til eit ruteproblem eller eit politikkproblem, og dei kostar mindre enn å rotere påloggingsinformasjon for fjerde gong.