Maayos ang pag-decrypt ng ESP at ang panloob na packet ay hindi pa rin umaabot kahit saan

Tumataas ang receive counter ng ESP, nananatiling buhay ang tunnel, at hindi kailanman nakikita ng application ang packet. Naganap ang decryption, pumasa ang integrity check, at pagkatapos ay kailangang magpasya ng receiver kung ano talaga ang protektadong payload. Sa huling hakbang na iyon lumilitaw ang hindi pagkakatugma ng format, at mula sa labas ay parang hindi ito problema sa firewall.

Ano ang nakikita mo kapag nagsisinungaling ang label

Walang anuman sa log ng client ang nagtatangi nito sa isang black hole ng routing. Kapwa nagdudulot ang mga ito ng timeout ng application sa tabi ng malusog na tunnel, kaya ang mga counter ang unang sinisisi.

Ang tumataas na receive counter ay tunay na mabuting balita: dumarating ang mga packet at napapatotohanan. Ngunit hindi ito patunay na may saysay ang panloob na packet para sa anumang bagay sa itaas ng crypto layer.

Nakatira ang uri sa trailer

Sa karaniwang IPsec tunnel mode, ang payload na protektado ng ESP ay naglalaman ng kumpletong panloob na IP packet. Tinutukoy ng field ng susunod na header sa trailer kung ano ang payload na iyon, at hindi ito TCP port, hindi numero ng protocol sa panlabas na header, at hindi bahagi ng inisyal na SPI at sequence number field. RFC 4303 seksyon 2.6 tinutukoy ito bilang field ng uri ng payload, na tumpak na pangalan para sa tumpak na gawain.

Maliliit ang mga value na makikita mo at sulit tandaan: ang IPv4 ay 4 (0x04) at ang IPv6 ay 41 (0x29).

Nagmumula ang mga numerong iyon sa mga paglalaan ng protocol number ng IANA at hindi sa lokal na kaugalian. Ang nagpapadala na nagdedeklara ng IPv4 habang bumabalot ng IPv6 packet ay lumikha ng hindi pagkakatugma ng format, at walang tuntunin ng firewall ang nag-aayos ng mga byte na sumasalungat sa sarili nilang label.

Paano ito ihiwalay sa mga karaniwang pinaghihinalaan

Karamihan sa mga nawawalang packet ay hindi depekto sa pag-encode. Suriin muna ang mga selector, dahil ang selector ng trapiko na nagbubukod sa IPv6 prefix ay nagtatapon ng trapiko bago pa man ma-encapsulate ang anuman. Pagkatapos ay suriin ang routing, at pagkatapos ang lokal na pag-filter sa tumatanggap na host. Kapag naibukod na iyon, saka pa lamang nagiging kapani-paniwalang paliwanag ang hindi pagkakatugma ng format ng payload.

Hindi ito malulutas ng naka-encrypt na capture, dahil ang protektadong susunod na header ay nasa loob ng naka-encrypt na payload. Kailangan mo ng diagnostics ng implementasyon o ng sinusuportahang na-decrypt na observation point, at kapwa nangangailangan ng pahintulot bago gamitin.

Kung walang makapagbibigay ng ebidensyang iyon, wala kang bug sa format. Mayroon kang teorya, at ang mga selector pa rin ang mas mabuting taya.

Ano ang hindi ang pag-aayos

Huwag patayin ang mga integrity check para makadaan ang trapiko. Huwag muling isulat ang naka-encrypt na packet sa intermediate na router, dahil hindi iyon maaaring gumana at masisira nito ang daloy habang mukhang nakakatulong sa isang capture. Huwag magbukas ng mas malawak na tuntunin ng firewall ng application sa teoryang naka-block ang isang port. Wala sa mga iyon ang dumadapo sa hindi pagkakatugma ng label.

Kung ang kumpirmadong hindi pagkakatugma ay nagmumula sa implementasyon ng kapareha, itago ang pinakamaliit na nalinis na reproduksyon at dalhin ito sa sinusuportahang channel ng implementasyong iyon.

I-verify ang daloy, hindi ang counter

Pagkatapos ng pagwawasto, subukan ang aktwal na daloy ng IPv6 mula simula hanggang wakas: isang kahilingan ng application sa tunnel, ang sagot nito, at ang pares ng address na namamasid sa bawat panig. Ang tumataas na ESP counter ay nagpapatunay lamang na ang mga packet ay tinatanggap at napapatotohanan. Wala itong sinasabi tungkol sa kung ang panloob na packet ay magagamit.

Itala ang parehong resulta sa ticket. Ang paggalaw ng counter kasama ng gumaganang daloy ay pag-aayos; ang paggalaw ng counter lamang ay eksaktong mayroon ka bago ka magsimula.