Så läser du det första IKEv2-utbytet i en paketfångst

Fångster som tas mitt i en session är den vanliga orsaken till att ett IKEv2-spår ser ut som brus, eftersom parterna redan förnyar nycklar eller utbyter krypterade nyttolaster när inspelningen börjar. Börja i stället med ett färskt anslutningsförsök, så att det första meddelandet i filen är det som öppnar förhandlingen. Läsvinstordningen nedan förutsätter det och markerar punkten där ett paket slutar bevisa något om den bortre änden. Att hoppa över det steget är hur en fungerande tunnel diagnosticeras som en blockerad port.

Bekräfta att du tittar på öppningsutbytet

En IKEv2-förhandling börjar med IKE_SA_INIT, utbytestyp 34, meddelande-ID 0. Initiativtagaren väljer en SPI som inte är noll, och svararens SPI är noll i den första begäran och inte noll i svaret. Dessa tre fakta skiljer ett färskt försök från en nyckelförnyelse eller från ett IKE_AUTH-meddelande som råkar ligga högst upp i en fångst.

Huvudfälten är läsbara, och detsamma gäller förslags-, nyckelutbytes- och nonce-nyttolasterna. Läsbart är inte autentiserat: ingen av parterna har bevisat identitet vid denna punkt, och Diffie-Hellmans privata värde dyker aldrig upp på ledningen.

Skriv ut fälten som en tabell i stället för att rulla genom en avkodningspanel, eftersom omsändningar och SPI:er som inte stämmer blir tydliga i kolumner.

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 utdata i par. En begäran med meddelande-ID 0 följd av ett svar med samma ID och en svarar-SPI som inte är noll är ett utbyte, även när det dyker upp tre gånger eftersom begäran sändes om. Tre identiska begäranden är inte tre inloggningar, och att behandla dem så är hur man drar slutsatsen att en klient går i loop när den bara är tålmodig. Sortera efter meddelande-ID och sedan efter tidsstämpel, och hela samtalet krymper till en kort lista över försök.

Läs en avvisning innan du läser en framgång

Ett svar är inte automatiskt framsteg. Svararen kan svara med en cookie-avisering och förvänta sig att initiativtagaren försöker igen, eller med INVALID_KE_PAYLOAD som namnger en grupp den hellre skulle acceptera. Båda anländer som välformade IKE-meddelanden, och båda ser ut som ett avslutat utbyte för ett filter som bara räknar paket.

Öppna aviseringsnyttolasten och läs typen före allt annat. En cookie-utmaning betyder att svararen försvarar sig mot förfalskade källadresser, och klienten måste skicka igen med cookien bifogad. En ogiltig grupp betyder att de två förslagen inte stämmer överens, vilket inget antal nya försök ändrar förrän konfigurationen på ena sidan flyttar sig.

Bara IKE_AUTH, det andra utbytet, bär den krypterade identiteten och autentiseringsnyttolasterna. En slutförd IKE_SA_INIT säger därför att parterna är överens om algoritmer och härledda nycklar, och absolut ingenting om huruvida inloggningsuppgifterna accepteras. Förvänta dig också två meddelanden där, och förvänta dig att båda är ogenomträngliga utan sessionsnycklarna.

Port 4500 är inte ett enda protokoll

UDP 500 bär vanligtvis öppningsutbytet. När NAT-upptäckten har körts flyttar IKE till 4500 och sätter en nollmarkör på fyra byte som inte är ESP framför varje meddelande. Inkapslad ESP på samma port börjar i stället med en ESP-SPI som inte är noll, och en NAT-keepalive på en byte är en tredje form som dyker upp när ingenting annat händer.

Ett filter som bara matchar porten blandar alla tre, och därför avgör "det finns trafik på 4500" så lite. Dela upp vyn efter protokoll innan du drar någon slutsats om den bortre änden.

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

Tystnad beskriver observationspunkten

Begäranden utan svar fastställer exakt en sak: vid den fångstpunkten dök inget svar upp. Filtrering, en rutt som skickar svaret någon annanstans, en oåtkomlig svarare eller en svarare som inte gillar förslaget ger alla samma tomma resultat, och en generisk UDP-test skiljer dem inte åt.

En ICMP-unreachable är bevis av ett annat slag. Läs det citerade paketet inuti det och identifiera vilken enhet som skickade det, eftersom en routers administrativa avvisning inte är ett autentiserat fel från den bortre änden.

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

Korrelera samma försök med loggar på serversidan där du har tillåtelse att läsa dem. Kom begäran fram, svarade tjänsten, och var stoppade svaret? De tre svaren skickar dig till ett ruttproblem eller ett policyproblem, och de kostar mindre än att rotera inloggningsuppgifterna en fjärde gång.