Как да четем първия обмен на IKEv2 в прехващане на пакети

Прехващанията, започнати в средата на сесията, са обичайната причина следа на IKEv2 да изглежда като шум, защото страните вече подновяват ключове или обменят криптирани товари, когато записът започне. Започнете вместо това с нов опит за свързване, така че първото съобщение във файла да е това, което отваря преговорите. Редът на четене по-долу предполага точно това и отбелязва точката, в която пакетът спира да доказва каквото и да е за отсрещната страна. Именно пропускането на тази стъпка води до това работещ тунел да бъде диагностициран като блокиран порт.

Уверете се, че гледате началния обмен

Преговорите по IKEv2 започват с IKE_SA_INIT, тип на обмена 34, идентификатор на съобщението 0. Инициаторът избира ненулев SPI, а SPI на ответника е нула в тази първа заявка и ненулев в отговора. Тези три факта отделят новия опит от подновяване на ключове или от съобщение IKE_AUTH, което случайно стои в началото на прехващането.

Полетата на заглавката се четат, както и товарите на предложението, обмена на ключове и nonce. Четимостта не е автентикация: нито една страна не е доказала самоличност на този етап, а частната стойност на Diffie-Hellman никога не се появява по линията.

Отпечатайте полетата като таблица, вместо да превъртате панела за декодиране, защото повторните предавания и несъвпадащите SPI стават очевидни в колони.

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

Четете изхода по двойки. Заявка с идентификатор на съобщението 0, последвана от отговор със същия идентификатор и ненулев SPI на ответника, е един обмен, дори когато се появява три пъти, защото заявката е била препредадена. Три еднакви заявки не са три влизания и точно такова отношение води до извода, че клиентът се върти в цикъл, когато всъщност е просто търпелив. Сортирайте по идентификатор на съобщението, после по времева марка, и целият разговор се свива до кратък списък от опити.

Прочетете отказа, преди да прочетете успеха

Отговорът не е автоматично напредък. Ответникът може да отговори с нотификация cookie и да очаква инициаторът да опита отново, или с INVALID_KE_PAYLOAD, който посочва група, която би приел вместо нея. И двете пристигат като коректно оформени IKE съобщения и двете изглеждат като завършен обмен за филтър, който само брои пакети.

Отворете товара на нотификацията и прочетете типа преди всичко друго. Предизвикателството cookie означава, че ответникът се защитава срещу подправени адреси на източника и клиентът трябва да изпрати отново с прикачено cookie. Невалидната група означава, че двете предложения не съвпадат и никакво повторение няма да го промени, докато конфигурацията на една от страните не се промени.

Само IKE_AUTH, вторият обмен, носи криптираната самоличност и товарите за автентикация. Затова завършен IKE_SA_INIT ви казва, че страните са съгласни за алгоритмите и производните ключове, и абсолютно нищо за това дали удостоверенията ще бъдат приети. Очаквайте и там две съобщения и очаквайте двете да са непрозрачни без ключовете на сесията.

Порт 4500 не е един протокол

UDP 500 обикновено носи началния обмен. След като откриването на NAT е изпълнено, IKE преминава към 4500 и поставя пред всяко съобщение четирибайтов нулев маркер за не-ESP. Инкапсулираният ESP на същия порт започва с ненулев SPI на ESP, а еднобайтовият NAT keepalive е трета форма, която се появява, когато нищо друго не се случва.

Филтър, който съпоставя само порта, смесва и трите, поради което "има трафик на 4500" решава толкова малко. Разделете изгледа по протокол, преди да правите изводи за отсрещната страна.

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

Тишината описва точката на наблюдение

Заявките без отговори установяват точно едно нещо: в тази точка на прехващане не се появи отговор. Филтриране, маршрут, който изпраща отговора другаде, недостъпен ответник или ответник, на когото предложението не харесва, всички дават един и същ празен резултат и обща UDP проверка няма да ги раздели.

Недостижимост по ICMP е доказателство от друг вид. Прочетете цитирания пакет вътре в него и определете кое устройство го е изпратило, защото административният отказ на рутера не е автентикирана грешка от отсрещната страна.

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

Свържете същия опит със сървърните журнали там, където ви е разрешено да ги четете. Пристигна ли заявката, отговори ли услугата и къде спря отговорът? Тези три отговора ви насочват към проблем с пътя или към проблем с политика и струват по-малко от четвърто подновяване на удостоверенията.