Как да прочетете нов обмен IKE_SA_INIT в запис

Започнете със запис, който започва преди първия пакет на опита, иначе ще четете средата на разговор. Договаряне, което вече тече, показва шифровани обмени и подновявания на ключове и нито едно от двете не изглежда като началото. Началото е частта, която можете да декодирате без ключове, затова то отговаря толкова добре на въпроси за достижимост. Четири проверки по ред ви водят от чист запис до защитимо твърдение коя страна е спряла да говори.

Първо, потвърдете, че записът започва от началото

Запис, започнал след като тунелът се вдигне, ще съдържа инкапсулирания поток от данни и периодични keepalive и двете са или шифровани, или почти празни. Рестартирайте клиента и запишете самия опит или предизвикайте нарочно ново свързване, докато записът тече. Ако не можете да създадете нов опит, отбележете го в бележките си, защото никакво декодиране не връща начало, което никога не сте записали.

Ограничете записа до двата крайни възела и до UDP 500 и 4500, за да остане файлът достатъчно малък за четене. На натоварен хост нефилтриран запис заравя договарянето под страничен трафик.

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

Пазете файла, когато опитът е интересен, защото същият запис отговаря на двата следващи въпроса: какъв беше обменът и дали нещо се върна. Означете го с началния час и двойката крайни възли, по които сте филтрирали. Запис без тези два факта е безполезен след седмица, когато адресите са се променили и никой не помни кой опит е записал.

Второ, прочетете заглавката преди товарите

Заглавката на IKE носи индексите на параметрите за сигурност, типа обмен и идентификатора на съобщението и при ново договаряне тези стойности са отличителни. Инициаторът измисля ненулев SPI, първоначалната заявка носи нулев SPI на ответника, защото още не е видян отговор, типът обмен е IKE_SA_INIT, а идентификаторът на съобщението е нула. Всичко друго принадлежи на по-късен етап от същото договаряне или на съвсем друг опит.

Предложението, обменът на ключове и nonce товарите в този първи обмен се четат в открит вид. Четимостта не е удостоверяване и на този етап нито една страна не е доказала самоличността си.

Частната стойност на Diffie-Hellman никога не преминава по кабела, затова записът не ви позволява да изведете сесийни ключове. Удостоверяването се случва в следващия обмен, защитено от това, което първият е договорил. Ако някой попита дали отсрещната страна е истинска, този обмен не може да отговори на този въпрос. Той може само да покаже, че двете страни са се съгласили за предложение и са създали споделена тайна, която файлът не съдържа.

Трето, съпоставете заявката с отговора ѝ

Съпоставете по двойката SPI, типа обмен и идентификатора на съобщението, после проверете флага за отговор. Препредаването повтаря идентификатора на съобщението на оригинала и не е втори опит за вход. Броенето на пакети вместо на обмени е начинът, по който здраво договаряне се превръща във фантомен цикъл.

Отговорът може да е и отказ: заявка за бисквитка, известие за неприемлива група или грешка за предложение. Това са законни отговори и означават, че пътят работи, а политиката не. Декодирайте известието, вместо да приемате всеки отговор за успех. Когато известието посочва група или предложение, поправката е от страната на конфигурацията, а не на защитната стена.

Посоката също има значение. Заявка без отговор и отговор, който никога не стига до клиента, са различни повреди и само втората изглежда като изчакване от страна на клиента.

Четвърто, отделете IKE от всичко останало на 4500

Порт 4500 носи три неща, които в обобщен изглед изглеждат еднакво: IKE зад четирибайтов нулев маркер non-ESP, инкапсулиран ESP, в чиято позиция на маркера стои ненулев SPI, и кратки keepalive. Именно маркерът отделя IKE от инкапсулирания ESP, затова прочетете тези байтове, преди да наречете трафика IKE. Етикет на запис, който чете 4500, е номер на порт, а не протокол.

Инкапсулираният ESP е шифрован товар, който не можете да тълкувате без ключове, и присъствието му може да е знак за работещ тунел, а не за повреда.

Наблюдавайте двата порта за един и същ опит, защото IKE може да се премести на 4500 след откриване на NAT, въпреки че е отворен на 500. След, филтриран само по 500, изглежда тих точно когато договарянето е успяло и се е преместило. Разширете филтъра и прочетете отново същия времеви прозорец, преди да правите какъвто и да е извод от липсата.

Какво означава тишината в една точка за наблюдение

Липсата на отговор при клиента доказва само това, което тази точка е наблюдавала. Филтриране, маршрутизация, грешен отдалечен адрес, спряла услуга и несъответствие на протокол дават същия празен след.

Подходящ ICMP unreachable добавя доказателство, но прочетете цитирания пакет в него и отбележете адреса на устройството, което го е изпратило.

Отказът на маршрутизатор е различно събитие от удостоверена грешка, върната от отсрещната страна, и само второто доказва, че услугата е жива. Съпоставете същия опит със сървърни журнали или с одобрено наблюдение, за да научите дали заявката е пристигнала и дали отговор е излязъл. Пазете записите ограничени и поверителни, защото четимите полета на ръкостискането не правят останалата част от файла безвредна. Резултатът, който си струва, е една съпоставена заявка и отговор или една документирана празнина с посочена точка за наблюдение.