Jak číst novou výměnu IKE_SA_INIT v záznamu

Začněte záznamem, který začíná před prvním paketem pokusu, jinak budete číst střed rozhovoru. Vyjednávání, které už běží, ukazuje šifrované výměny a obnovy klíčů a ani jedno nevypadá jako začátek. Začátek je část, kterou lze dekódovat bez klíčů, a proto tak dobře odpovídá na otázky dostupnosti. Čtyři kontroly v pořadí vás zavedou od čerstvého záznamu k obhajitelnému tvrzení o tom, která strana přestala mluvit.

Nejprve ověřte, že záznam začíná na začátku

Záznam spuštěný po navázání tunelu bude obsahovat zapouzdřený datový tok a periodické keepalive a obojí je buď šifrované, nebo téměř prázdné. Restartujte klienta a zaznamenejte samotný pokus, nebo během záznamu záměrně vyvolejte nové spojení. Pokud nemůžete vytvořit čerstvý pokus, napište to do poznámek, protože žádné dekódování nevrátí začátek, který jste nikdy nezaznamenali.

Omezte záznam na dva koncové body a na UDP 500 a 4500, aby soubor zůstal dost malý na čtení. Na vytíženém hostiteli nefiltrovaný záznam zahrabe vyjednávání pod nesouvisející provoz.

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

Soubor si nechte, když je pokus zajímavý, protože stejný záznam odpovídá na obě následující otázky: co výměna byla a zda se něco vrátilo. Označte ho časem začátku a dvojicí koncových bodů, na kterou jste filtrovali. Záznam bez těchto dvou faktů je za týden k ničemu, když se adresy změní a nikdo si nepamatuje, který pokus zachytil.

Za druhé, čtěte hlavičku dřív než užitečné zatížení

Hlavička IKE nese indexy bezpečnostních parametrů, typ výměny a ID zprávy a při novém vyjednávání jsou tyto hodnoty charakteristické. Iniciátor vymýšlí nenulové SPI, počáteční požadavek nese nulové SPI odpovídající strany, protože odpověď ještě nebyla vidět, typ výměny je IKE_SA_INIT a ID zprávy je nula. Všechno ostatní patří pozdější fázi téhož vyjednávání nebo úplně jinému pokusu.

Návrh, výměna klíčů a nonce v této první výměně jsou čitelné v otevřené podobě. Čitelnost není ověření a v tomto okamžiku žádná strana neprokázala svou totožnost.

Soukromá hodnota Diffie-Hellman nikdy nepřekročí drát, takže ze záznamu nelze odvodit relace klíčů. Ověření probíhá v následující výměně, chráněné tím, na čem se první výměna dohodla. Když se někdo zeptá, zda je protistrana pravá, tato výměna na to nedokáže odpovědět. Může jen ukázat, že se obě strany shodly na návrhu a vytvořily sdílené tajemství, které soubor neobsahuje.

Za třetí, spárujte požadavek s jeho odpovědí

Párujte podle dvojice SPI, typu výměny a ID zprávy, pak zkontrolujte příznak odpovědi. Opakované odeslání opakuje ID zprávy originálu a není druhým pokusem o přihlášení. Počítání paketů místo výměn je způsob, jak se zdravé vyjednávání změní ve fantomovou smyčku.

Odpověď může být i odmítnutí: požadavek na cookie, oznámení o nepřijatelné skupině nebo chyba týkající se návrhu. To jsou legitimní odpovědi a znamenají, že cesta funguje, zatímco politika ne. Dekódujte oznámení, místo abyste každou odpověď považovali za úspěch. Když oznámení pojmenuje skupinu nebo návrh, oprava je na straně konfigurace, ne na firewallu.

Směr je také důležitý. Požadavek bez odpovědi a odpověď, která se nikdy nedostane ke klientovi, jsou různé závady a jen druhá vypadá jako časový limit na straně klienta.

Za čtvrté, oddělte IKE od všeho ostatního na 4500

Port 4500 nese tři věci, které v souhrnném pohledu vypadají stejně: IKE za čtyřbajtovým nulovým non-ESP markerem, zapouzdřené ESP, jehož pozice markeru drží nenulové SPI, a krátké keepalive. Právě marker odděluje IKE od zapouzdřeného ESP, takže ty bajty přečtěte, než provoz nazvete IKE. Štítek záznamu, který čte 4500, je číslo portu, ne protokol.

Zapouzdřené ESP je šifrované užitečné zatížení, které bez klíčů nevyložíte, a jeho přítomnost může být známkou fungujícího tunelu, ne závady.

Sledujte oba porty pro tentýž pokus, protože IKE se po detekci NAT může přesunout na 4500, i když se otevřel na 500. Stopa filtrovaná jen na 500 vypadá němě právě tehdy, když vyjednávání uspělo a přesunulo se. Rozšiřte filtr a znovu přečtěte stejné časové okno, než z nepřítomnosti vyvodíte jakýkoli závěr.

Co znamená ticho v jednom pozorovacím bodě

Žádná odpověď u klienta dokazuje jen to, co tento bod pozoroval. Filtrování, směrování, špatná vzdálená adresa, neběžící služba a neshoda protokolu dávají stejnou prázdnou stopu.

Příslušná ICMP unreachable přidává důkaz, ale přečtěte citovaný paket uvnitř ní a poznamenejte adresu zařízení, které ji odeslalo.

Odmítnutí routerem je jiná událost než ověřená chyba vrácená protistranou a jen druhá dokazuje, že služba žije. Spárujte tentýž pokus se serverovými záznamy nebo schváleným pozorováním, abyste zjistili, zda požadavek dorazil a zda odpověď odešla. Držte záznamy omezené a soukromé, protože čitelná pole handshake nedělají zbytek souboru neškodným. Výsledek, který stojí za to, je jedna spárovaná dvojice požadavku a odpovědi nebo jedna zdokumentovaná mezera s pojmenovaným pozorovacím bodem.