Пакет хураалтад эхний 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

Мөн оролдлогыг серверийн талын бүртгэлтэй унших зөвшөөрөлтэй газарт харьцуул. Хүсэлт ирсэн үү, үйлчилгээ хариулсан уу, хариу хаана зогссон бэ? Тэр гурван хариулт таныг замын асуудал эсвэл бодлогын асуудал руу илгээдэг бөгөөд тэд итгэмжлэлийг дөрөв дэх удаа солихоос хямд.