Пакет ұстаудағы бірінші 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

Сол әрекетті сервер жағындағы журналдармен оларды оқуға рұқсат бар жерде салыстырыңыз. Сұрау жетті ме, қызмет жауап берді ме және жауап қай жерде тоқтады? Бұл үш жауап сізді жол мәселесіне немесе саясат мәселесіне жібереді және тіркелгі деректерін төртінші рет ауыстырудан арзан.