AH o ESP? Magpasya batay sa dapat protektahan ng packet

Dalawang panukalang IPsec ang maaaring magbanggit ng parehong algorithm ng integridad na nakabatay sa SHA at humingi pa rin ng magkaibang protocol ng proteksyon; ang AH at ESP ay hindi dalawang baybay ng isang setting ng pagpapatunay. Basahin muna ang protocol, pagkatapos ang mga algorithm nito, pagkatapos ang mode nito, at mawawala ang karamihan ng kalabuan. Sinusuri ng AH ang packet, kasama ang mga field ng header ng IP na hindi nagbabago sa paglalakbay, habang ine-encrypt at pinapatunayan ng ESP ang ipinapaloob nito at hinahayaang tahimik ang panlabas na header. Ang pagkakaibang iyon ang nagpapasya sa mas maraming deployment kaysa alinmang pangalan ng hash.

Ano ang sinasaklaw ng AH na hindi ng ESP

Nagbibigay ang AH ng integridad, pagpapatunay ng pinagmulan ng datos at ang serbisyong laban sa pag-uulit na siya mismo ang tumutukoy, at walang pagiging lihim. Kasama sa saklaw nito ang datos ng itaas na layer at ang mga field ng header ng IP na itinuturing na hindi nagbabago ng mga tuntunin nito, eksaktong bahaging iniiwan ng ESP sa labas sa mode ng transportasyon. Kapag sinabi ng pangangailangan na ang header ng IP mismo ang dapat patunayan, ang AH ang protocol na tumutugon.

Ang saklaw na ito rin ang dahilan kung bakit marupok ang AH sa praktika. Ang mga field na nagbabago tulad ng TTL, checksum ng header at ilang opsyon ay hindi mapapatunayan dahil maaaring isulat muli ng mga router, kaya itinatakda ng protocol ang mga ito sa sero bago kalkulahin ang tseke. Kaya ang anumang nagsusulat muli ng mga address ay sumisira sa kalkulasyon, hindi lamang sa patakaran.

Ginagawang hadlang ng NAT ang pagpili

Isinusulat muli ng pagsasalin ng address ang pinagmulan o destinasyon sa header ng IP na pinatunayan lang ng AH, kaya nabigo ang tseke ng integridad sa kabilang dulo, at nabigo ito bilang error ng protocol at hindi bilang nababasang mensahe. Hindi pinapatunayan ng ESP ang panlabas na header, kaya gumagana ang ESP na may pagdaan sa NAT samantalang ang AH sa likod ng NAT ay hindi. Ang tunnel na ang dalawang dulo ay nasa likod ng ordinaryong router ang eksaktong lugar kung saan ito unang lumilitaw. Kaya ang unang tanong ay hindi kung aling protocol ang mas malakas, kundi kung may tagasalin sa pagitan ng mga dulo.

Kung mayroon, wala ang AH, at lumilipat ang usapan sa ESP at sa mga pagpili nito ng algorithm. Ito ay hadlang at hindi kagustuhan, kaya nasa simula ito ng desisyon at hindi sa dulo.

Pinaparami ng mode ang tanong

Pinoprotektahan ng ESP sa mode ng transportasyon ang payload ng itaas na layer at hinahayaang tahimik ang header ng IP; sa mode ng tunnel, ipinapaloob nito ang buong panloob na packet, kasama ang panloob na header ng IP, at pinoprotektahan ito. May parehong dalawang mode rin ang AH, kaya ang AH o ESP ay talagang apat na kombinasyon bago pumili ng anumang algorithm.

Inaayos naman ng mga algorithm ng ESP sa pinagsamang mode ang integridad nang walang ikalawang protocol. Ang AES-GCM at ChaCha20-Poly1305 ay nagpapatunay at nag-e-encrypt sa isang konstruksyon, kaya walang nabibili ang pagdaragdag ng AH sa itaas ngunit gumagastos ito ng isa pang header at isa pang negosasyon. Pinapayagan ng arkitektura ang AH at ESP nang magkasama, at ang praktikal na tanong ay kung sinusuportahan ng iyong gateway at release ang kombinasyon at kung may makakapagpanatili nito pagkatapos.

Ang tapat na kapalit para sa AH lamang

Pinapanatili ng variant ng ESP na integridad lamang ang algorithm at binibitawan ang pag-aangkin ng pag-encrypt sa halip na pekeng ito, at lumalampas ito sa NAT. Kung gumamit ang lumang disenyo ng AH dahil kailangan ang pagpapatunay na walang pagiging lihim, ang variant na iyon ang direktang salin, hindi isang naka-encrypt na tunnel na may kalakip na tala.

Ang makita ang ESP sa isang panukala ay hindi rin patunay ng pag-encrypt. Basahin ang algorithm ng pag-encrypt: ang entry na NULL ay integridad lamang, at ang entry sa pinagsamang mode ay pareho.

Magpasya sa tatlong tanong

Itanong kung kailangan ang pagiging lihim, kung may tagasalin sa landas, at aling mga field ng header ang dapat patunayan. Ang tatlong sagot na iyon ay tumuturo sa isang protocol at isang mode, at ang pagsulat sa mga ito ay kumukuha ng mas kaunting oras kaysa sa muling pagbasa ng RFC mamaya.

Pagkatapos ay i-verify ang tinanggap at hindi ang iminungkahi. Ipinapakita ng ip xfrm state ang protocol, mode at mga algorithm ng naka-install na asosasyon, at ang hindi pagkakatugma ay walang ini-install, na isang mas malinis na pagkabigo kaysa sa tunnel na bumabangon nang walang sinadyang proteksyon.

Ihiwalay ang mga kabiguan ng pagpapatunay, saklaw ng mga selector at mga error sa pagruruta mula sa pagpiling ito. Nagbibigay sila ng magkaibang sintomas, at ang pagsisisi sa protocol para sa problema ng selector ay isang tiyak na paraan upang gumugol ng isang araw sa pagpapalit ng hash nang walang dahilan.