Як чытаць першы абмен 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

Супстаўце тую ж спробу з журналамі на баку сервера там, дзе вам дазволена іх чытаць. Ці прыйшоў запыт, ці адказала служба і дзе адказ спыніўся? Гэтыя тры адказы накіруюць вас да праблемы шляху або да праблемы палітыкі, і яны каштуюць менш, чым чацвёртая змена ўліковых даных.