Sådan læser du den første IKEv2-udveksling i en pakkeoptagelse

Optagelser midt i en session er den sædvanlige grund til, at et IKEv2-spor ligner støj, fordi parterne allerede fornyer nøgler eller udveksler krypterede nyttelaster, når optagelsen begynder. Begynd i stedet med et frisk forbindelsesforsøg, så den første besked i filen er den, der åbner forhandlingen. Læserækkefølgen nedenfor forudsætter det og markerer det punkt, hvor en pakke holder op med at bevise noget om den fjerne ende. Springes det trin over, er det sådan en fungerende tunnel bliver diagnosticeret som en blokeret port.

Bekræft, at du ser på den indledende udveksling

En IKEv2-forhandling begynder med IKE_SA_INIT, udvekslingstype 34, besked-ID 0. Initiativtageren vælger en SPI, der ikke er nul, og svarerens SPI er nul i den første anmodning og ikke-nul i svaret. De tre kendsgerninger adskiller et friskt forsøg fra en nøglefornyelse eller fra en IKE_AUTH-besked, der tilfældigvis ligger øverst i en optagelse.

Headerfelterne kan læses, og det kan forslags-, nøgleudvekslings- og nonce-nyttelasterne også. Læsbar er ikke det samme som autentificeret: ingen af parterne har bevist identitet på dette punkt, og Diffie-Hellmans private værdi optræder aldrig på ledningen.

Udskriv felterne som en tabel i stedet for at rulle gennem et afkodningspanel, fordi gensendinger og uoverensstemmende SPI'er bliver 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

Læs outputtet i par. En anmodning med besked-ID 0 efterfulgt af et svar med samme ID og en svarer-SPI, der ikke er nul, er én udveksling, selv når den optræder tre gange, fordi anmodningen blev gensendt. Tre identiske anmodninger er ikke tre logins, og behandler man dem sådan, konkluderer man, at en klient kører i ring, når den bare er tålmodig. Sortér efter besked-ID og derefter efter tidsstempel, og hele samtalen skrumper ind til en kort liste af forsøg.

Læs en afvisning, før du læser en succes

Et svar er ikke automatisk fremskridt. Svareren kan svare med en cookie-notifikation og forvente, at initiativtageren prøver igen, eller med INVALID_KE_PAYLOAD, der navngiver en gruppe, den hellere vil acceptere. Begge ankommer som velformede IKE-beskeder, og begge ser ud som en afsluttet udveksling for et filter, der kun tæller pakker.

Åbn notifikations-nyttelasten, og læs typen før alt andet. En cookie-udfordring betyder, at svareren forsvarer sig mod forfalskede kildeadresser, og klienten skal sende igen med cookien vedhæftet. En ugyldig gruppe betyder, at de to forslag er uenige, hvilket ingen mængde genforsøg ændrer, før den ene sides konfiguration flytter sig.

Kun IKE_AUTH, den anden udveksling, bærer den krypterede identitet og autentificerings-nyttelasterne. En gennemført IKE_SA_INIT fortæller dig derfor, at parterne er enige om algoritmer og afledte nøgler, og intet som helst om, hvorvidt legitimationsoplysningerne accepteres. Forvent også to beskeder der, og forvent at begge er uigennemsigtige uden sessionsnøglerne.

Port 4500 er ikke én protokol

UDP 500 bærer normalt den indledende udveksling. Når NAT-registreringen har kørt, flytter IKE til 4500 og sætter en firebyte nulmarkør, der ikke er ESP, foran hver besked. Indkapslet ESP på samme port begynder i stedet med en ESP-SPI, der ikke er nul, og en NAT-keepalive på én byte er en tredje form, der dukker op, når intet andet sker.

Et filter, der kun matcher porten, blander alle tre, og derfor afgør "der er trafik på 4500" så lidt. Del visningen op efter protokol, før du konkluderer noget om den fjerne ende.

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

Stilhed beskriver observationspunktet

Anmodninger uden svar fastslår præcis én ting: på det optagelsespunkt dukkede intet svar op. Filtrering, en rute, der sender svaret et andet sted hen, en uopnåelig svarer eller en svarer, der ikke kan lide forslaget, giver alle det samme tomme resultat, og en generisk UDP-test vil ikke skelne dem.

En ICMP-unreachable er bevis af en anden slags. Læs den citerede pakke indeni, og find ud af, hvilken enhed der udsendte den, fordi en routers administrative afvisning ikke er en autentificeret fejl fra den fjerne ende.

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

Korrelér det samme forsøg med server-side-logfiler, hvor du har lov til at læse dem. Ankom anmodningen, svarede tjenesten, og hvor stoppede svaret? De tre svar sender dig til et ruteproblem eller til et politikproblem, og de koster mindre end at rotere legitimationsoplysninger en fjerde gang.