Slik leser du den første IKEv2-utvekslingen i en pakkeopptak

Opptak midt i en økt er den vanlige grunnen til at et IKEv2-spor ser ut som støy, fordi partene allerede fornyer nøkler eller utveksler krypterte nyttelaster når opptaket begynner. Start i stedet med et ferskt tilkoblingsforsøk, slik at den første meldingen i filen er den som åpner forhandlingen. Leserekkefølgen nedenfor forutsetter det og markerer punktet der en pakke slutter å bevise noe om den fjerne enden. Det er nettopp dette trinnet som hoppes over når en fungerende tunnel diagnostiseres som en blokkert port.

Bekreft at du ser på åpningsutvekslingen

En IKEv2-forhandling begynner med IKE_SA_INIT, utvekslingstype 34, meldings-ID 0. Initiativtakeren velger en SPI som ikke er null, og svarerens SPI er null i den første forespørselen og ikke-null i svaret. Disse tre fakta skiller et ferskt forsøk fra en nøkkelfornyelse eller fra en IKE_AUTH-melding som tilfeldigvis ligger øverst i et opptak.

Hodefeltene er lesbare, og det samme er forslags-, nøkkelutvekslings- og nonce-nyttelastene. Lesbart er ikke autentisert: ingen av partene har bevist identitet på dette punktet, og Diffie-Hellmans private verdi dukker aldri opp på ledningen.

Skriv ut feltene som en tabell i stedet for å rulle gjennom et avkodingspanel, fordi gjentatte sendinger og SPI-er som ikke stemmer blir tydelige i kolonner.

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. En forespørsel med meldings-ID 0 etterfulgt av et svar med samme ID og en svarer-SPI som ikke er null, er én utveksling, selv når den dukker opp tre ganger fordi forespørselen ble sendt på nytt. Tre identiske forespørsler er ikke tre innlogginger, og behandler man dem slik, konkluderer man at en klient går i løkke mens den bare er tålmodig. Sorter etter meldings-ID og deretter etter tidsstempel, og hele samtalen krymper til en kort liste over forsøk.

Les en avvisning før du leser en suksess

Et svar er ikke automatisk fremgang. Svareren kan svare med en cookie-varsling og forvente at initiativtakeren prøver igjen, eller med INVALID_KE_PAYLOAD som navngir en gruppe den heller vil godta. Begge ankommer som velformede IKE-meldinger, og begge ser ut som en avsluttet utveksling for et filter som bare teller pakker.

Åpne varselnyttelasten og les typen før alt annet. En cookie-utfordring betyr at svareren forsvarer seg mot forfalskede kildeadresser, og klienten må sende på nytt med cookien vedlagt. En ugyldig gruppe betyr at de to forslagene er uenige, noe ingen mengde nye forsøk endrer før konfigurasjonen på den ene siden flytter seg.

Bare IKE_AUTH, den andre utvekslingen, bærer den krypterte identiteten og autentiseringsnyttelastene. En fullført IKE_SA_INIT forteller deg derfor at partene er enige om algoritmer og avledede nøkler, og absolutt ingenting om hvorvidt påloggingsinformasjonen blir godtatt. Forvent også to meldinger der, og forvent at begge er ugjennomsiktige uten øktnøklene.

Port 4500 er ikke én protokoll

UDP 500 bærer vanligvis åpningsutvekslingen. Når NAT-registreringen har kjørt, flytter IKE til 4500 og setter en firebyte nullmarkør som ikke er ESP foran hver melding. Innkapslet ESP på samme port begynner i stedet med en ESP-SPI som ikke er null, og en NAT-keepalive på én byte er en tredje form som dukker opp når ingenting annet skjer.

Et filter som bare matcher porten blander alle tre, og derfor avgjør "det er trafikk på 4500" så lite. Del visningen etter protokoll før du konkluderer noe 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

Stillhet beskriver observasjonspunktet

Forespørsler uten svar fastslår nøyaktig én ting: på det opptakspunktet dukket det ikke opp noe svar. Filtrering, en rute som sender svaret et annet sted, en utilgjengelig svarer eller en svarer som ikke liker forslaget gir alle samme tomme resultat, og en generisk UDP-test vil ikke skille dem.

En ICMP-unreachable er bevis av en annen art. Les den siterte pakken inni den og finn ut hvilken enhet som sendte den, fordi en rutermaskins administrative avvisning ikke er en autentisert feil fra den fjerne enden.

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

Korreler det samme forsøket med tjenerside-logger der du har lov til å lese dem. Kom forespørselen fram, svarte tjenesten, og hvor stoppet svaret? De tre svarene sender deg til et ruteproblem eller et policyproblem, og de koster mindre enn å rotere påloggingsinformasjon for fjerde gang.