Sådan læser du en frisk IKE_SA_INIT-udveksling i en optagelse

Start med en optagelse, der begynder før forsøgets første pakke, ellers læser du midten af en samtale. En forhandling, der allerede kører, viser krypterede udvekslinger og nøglefornyelser, og ingen af dem ligner åbningen. Åbningen er den del, du kan afkode uden nøgler, og derfor svarer den så godt på tilgængelighedsspørgsmål. Fire kontroller i rækkefølge fører dig fra en frisk optagelse til en holdbar udtalelse om, hvilken side der holdt op med at tale.

Først: bekræft, at optagelsen starter ved begyndelsen

En optagelse startet efter, at tunnelen kom op, vil indeholde den indkapslede datastrøm og periodiske keepalives, og begge er enten krypterede eller næsten tomme. Genstart klienten og optag selve forsøget, eller udløs bevidst en ny forbindelse, mens optagelsen kører. Hvis du ikke kan frembringe et frisk forsøg, så skriv det i dine noter, for ingen mængde afkodning genskaber en åbning, du aldrig optog.

Afgræns optagelsen til de to endepunkter og til UDP 500 og 4500, så filen forbliver lille nok til at læse. På en travl vært begraver en ufiltreret optagelse forhandlingen under uvedkommende trafik.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Gem filen, når forsøget er interessant, for den samme optagelse besvarer begge de følgende spørgsmål: hvad udvekslingen var, og om der kom noget tilbage. Mærk den med starttidspunktet og det endepunktspar, du filtrerede på. En optagelse uden de to fakta er ubrugelig en uge senere, når adresserne er ændret, og ingen husker, hvilket forsøg den optog.

Dernæst: læs headeren før nyttelasterne

IKE-headeren bærer sikkerhedsparameterindeksene, udvekslingstypen og besked-ID'en, og ved en ny forhandling er disse værdier karakteristiske. Initiativtageren opfinder en SPI forskellig fra nul, den indledende anmodning bærer en responder-SPI på nul, fordi der endnu ikke er set et svar, udvekslingstypen er IKE_SA_INIT, og besked-ID'en er nul. Alt andet hører til et senere trin i samme forhandling eller til et helt andet forsøg.

Forslags-, nøgleudvekslings- og nonce-nyttelasterne i denne første udveksling er læsbare i klartekst. Læsbar er ikke det samme som godkendt, og på dette tidspunkt har ingen af parterne bevist sin identitet.

Den private Diffie-Hellman-værdi krydser aldrig ledningen, så optagelsen lader dig ikke udlede sessionsnøgler. Godkendelsen sker i den næste udveksling, beskyttet af det, den første forhandlede sig frem til. Hvis nogen spørger, om en part er ægte, kan denne udveksling ikke svare på det spørgsmål. Den kan kun vise, at begge sider blev enige om et forslag og frembragte en fælles hemmelighed, som filen ikke indeholder.

Tredje: kobl anmodningen til dens svar

Kobl på SPI-parret, udvekslingstypen og besked-ID'en, og kontroller derefter svarflaget. En retransmission gentager den oprindelige besked-ID og er ikke et andet loginforsøg. At tælle pakker i stedet for udvekslinger er, hvordan en sund forhandling bliver til en fantomløkke.

Et svar kan også være en afvisning: en cookie-anmodning, en meddelelse om en uacceptabel gruppe eller en fejl om et forslag. Det er legitime svar, og de betyder, at vejen virker, mens politikken ikke gør. Afkod meddelelsen i stedet for at behandle hvert svar som en succes. Når meddelelsen nævner en gruppe eller et forslag, er rettelsen på konfigurationssiden og ikke ved firewallen.

Retningen betyder også noget. En anmodning uden svar og et svar, der aldrig når klienten, er forskellige fejl, og kun den anden ligner en timeout på klientsiden.

Fjerde: skel IKE fra alt andet på 4500

Port 4500 bærer tre ting, der ligner hinanden i en oversigt: IKE bag en fire-byte nul-non-ESP-markør, indkapslet ESP, hvis markørposition rummer en SPI forskellig fra nul, og korte keepalives. Det er den markør, der adskiller IKE fra indkapslet ESP, så læs de bytes, før du kalder trafikken IKE. En optagelsesetiket, der læser 4500, er et portnummer, ikke en protokol.

Indkapslet ESP er krypteret nyttelast, som du ikke kan fortolke uden nøgler, og dets tilstedeværelse kan være tegnet på en fungerende tunnel snarere end på en fejl.

Hold øje med begge porte for det samme forsøg, for IKE kan flytte til 4500 efter NAT-registrering, selvom det åbnede på 500. Et spor filtreret kun på 500 ser tavst ud netop, når forhandlingen lykkedes og flyttede sig. Udvid filteret, og læs det samme tidsvindue igen, før du drager nogen konklusion ud fra fravær.

Hvad tavshed på et observationspunkt betyder

Intet svar hos klienten beviser kun det, som det punkt observerede. Filtrering, routing, den forkerte fjernadresse, en tjeneste, der er nede, og en protokol-uoverensstemmelse giver alle det samme tomme spor.

En relevant ICMP unreachable tilføjer bevis, men læs den citerede pakke inde i den, og noter adressen på den enhed, der sendte den.

En routers afvisning er en anden hændelse end en godkendt fejl returneret af parten, og kun den anden beviser, at tjenesten er i live. Korrelér det samme forsøg med serverlogfiler eller en godkendt observation for at få at vide, om anmodningen ankom, og om et svar forlod stedet. Hold optagelser afgrænsede og private, for læsbare handshake-felter gør ikke resten af filen uskadelig. Det resultat, der er værd at have, er én parret anmodning og svar eller ét dokumenteret hul med et navngivet observationspunkt.