Како да ја читате првата IKEv2 размена во снимање пакети

Снимките направени во средина на сесија се вообичаена причина IKEv2 трагот да изгледа како шум, бидејќи страните веќе ги обновуваат клучевите или разменуваат шифрирани товари кога започнува снимањето. Наместо тоа започнете со нов обид за поврзување, така што првата порака во датотеката е онаа што ја отвора преговарањето. Редоследот на читање подолу го претпоставува тоа и ја означува точката во која пакетот престанува да докажува нешто за далечниот крај. Токму прескокнувањето на тој чекор води до тоа работен тунел да биде дијагностициран како блокиран порт.

Потврдете дека гледате во почетната размена

IKEv2 преговарањето започнува со IKE_SA_INIT, тип на размена 34, ID на порака 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

Читајте го излезот по парови. Барање со ID на порака 0 по кое следи одговор со истиот ID и SPI на одговорниот различен од нула е една размена, дури и кога се појавува три пати бидејќи барањето е повторно испратено. Три идентични барања не се три најави, и токму таквото третирање води до заклучок дека клиентот се врти во циклус кога е само трпелив. Подредете по ID на порака, потоа по временска ознака, и целиот разговор се собира во краток список обиди.

Прочитајте го одбивањето пред да прочитате успех

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

Отворете го товарот на известувањето и најпрво прочитајте го типот. Cookie предизвикот значи дека одговорниот се брани од лажни изворни адреси, и клиентот мора да испрати повторно со прикачен cookie. Неважечката група значи дека двата предлога не се совпаѓаат, што ниту едно повторување нема да го промени додека не се помести конфигурацијата на едната страна.

Само IKE_AUTH, втората размена, го носи шифрираниот идентитет и товарите за автентикација. Затоа завршен IKE_SA_INIT ви кажува дека страните се согласни за алгоритмите и изведените клучеви, и апсолутно ништо за тоа дали акредитивите ќе бидат прифатени. Очекувајте и таму две пораки, и очекувајте двете да бидат непробни без клучевите на сесијата.

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

Почетната размена обично ја носи UDP 500. Откако ќе се изврши откривањето на NAT, IKE преминува на 4500 и пред секоја порака става четирибајтен нулти маркер што не е ESP. Инкапсулираниот ESP на истата порта започнува со ESP SPI различен од нула, а еднобајтниот 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

Поврзете го истиот обид со дневниците на страната на серверот таму каде што ви е дозволено да ги читате. Дали барањето пристигна, дали услугата одговори и каде запре одговорот? Тие три одговори ве упатуваат на проблем со патека или на проблем со политика, и чинат помалку од четврта промена на акредитивите.