Hoe je de eerste IKEv2-uitwisseling in een pakketopname leest

Opnames midden in een sessie zijn de gebruikelijke reden dat een IKEv2-spoor als ruis oogt, omdat de peers al sleutels vernieuwen of versleutelde payloads uitwisselen wanneer de opname begint. Begin in plaats daarvan met een nieuwe verbindingspoging, zodat het eerste bericht in het bestand het bericht is dat de onderhandeling opent. De leesorde hieronder gaat daarvan uit en markeert het punt waarop een pakket niets meer over de verre kant bewijst. Juist die stap overslaan zorgt ervoor dat een werkende tunnel als geblokkeerde poort wordt gediagnosticeerd.

Bevestig dat je naar de openingsuitwisseling kijkt

Een IKEv2-onderhandeling begint met IKE_SA_INIT, uitwisselingstype 34, bericht-ID 0. De initiator kiest een SPI die niet nul is, en de SPI van de responder is nul in dat eerste verzoek en niet-nul in het antwoord. Die drie feiten scheiden een verse poging van een sleutelvernieuwing of van een IKE_AUTH-bericht dat toevallig bovenaan een opname staat.

Headervelden zijn leesbaar, en dat geldt ook voor de proposal-, sleuteluitwisselings- en nonce-payloads. Leesbaar is niet geauthenticeerd: geen van beide peers heeft op dit punt identiteit bewezen, en de privéwaarde van Diffie-Hellman verschijnt nooit op de lijn.

Druk de velden af als een tabel in plaats van door een decodeerpaneel te scrollen, want hertransmissies en niet-passende SPI's worden in kolommen zichtbaar.

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

Lees de uitvoer in paren. Een verzoek met bericht-ID 0 gevolgd door een antwoord met hetzelfde ID en een niet-nul responder-SPI is één uitwisseling, ook wanneer die drie keer verschijnt omdat het verzoek opnieuw is verzonden. Drie identieke verzoeken zijn geen drie logins, en ze zo behandelen is hoe mensen concluderen dat een client in een lus zit terwijl hij alleen geduldig is. Sorteer op bericht-ID en daarna op tijdstempel, en het hele gesprek krimpt tot een korte lijst pogingen.

Lees een afwijzing voordat je een succes leest

Een antwoord is niet automatisch vooruitgang. De responder kan antwoorden met een cookie-notificatie en verwachten dat de initiator het opnieuw probeert, of met INVALID_KE_PAYLOAD dat een groep noemt die hij liever zou accepteren. Beide komen binnen als goed gevormde IKE-berichten, en beide lijken op een afgeronde uitwisseling voor een filter dat alleen pakketten telt.

Open de notify-payload en lees het type vóór al het andere. Een cookie-uitdaging betekent dat de responder zich verdedigt tegen vervalste bronadressen, en de client moet opnieuw verzenden met de cookie erbij. Een ongeldige groep betekent dat de twee voorstellen het oneens zijn, wat geen enkele herhaling verandert tot de configuratie van één kant verschuift.

Alleen IKE_AUTH, de tweede uitwisseling, draagt de versleutelde identiteit en de authenticatie-payloads. Een voltooide IKE_SA_INIT vertelt je dus dat de peers het eens zijn over algoritmes en afgeleide sleutels, en helemaal niets over of de inloggegevens worden geaccepteerd. Verwacht daar ook twee berichten, en verwacht dat beide ondoorzichtig zijn zonder de sessiesleutels.

Poort 4500 is niet één protocol

UDP 500 draagt meestal de openingsuitwisseling. Zodra NAT-detectie is uitgevoerd, verhuist IKE naar 4500 en zet een nulmarkering van vier bytes die geen ESP is vóór elk bericht. Ingekapselde ESP op dezelfde poort begint juist met een niet-nul ESP-SPI, en een NAT-keepalive van één byte is een derde vorm die opduikt wanneer er verder niets gebeurt.

Een filter dat alleen de poort matcht mengt alle drie, en daarom beslist "er is verkeer op 4500" zo weinig. Splits de weergave op protocol voordat je iets over de verre kant concludeert.

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

Stilte beschrijft het observatiepunt

Verzoeken zonder antwoorden stellen precies één ding vast: op dat opnamepunt verscheen geen antwoord. Filtering, een route die het antwoord elders heen stuurt, een onbereikbare responder of een responder die het voorstel niet bevalt, leveren allemaal hetzelfde lege resultaat op, en een generieke UDP-test zal ze niet scheiden.

Een ICMP-unreachable is bewijs van een andere soort. Lees het geciteerde pakket erin en identificeer welk apparaat het heeft uitgezonden, want de administratieve afwijzing van een router is geen geauthenticeerde fout van de verre kant.

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

Correleer dezelfde poging met logs aan de serverkant waar je ze mag lezen. Kwam het verzoek aan, antwoordde de dienst, en waar stopte het antwoord? Die drie antwoorden sturen je naar een padprobleem of naar een beleidsprobleem, en ze kosten minder dan de inloggegevens een vierde keer roteren.