Ang papalabas na ESP na walang tugon ay hindi ibig sabihin na patay na ang VPN

Nakuhanan mo ng trapiko ang IPsec host, nakita mong lumalabas ang mga ESP packet, wala kang nakitang bumabalik, at napagpasyahan mong sira ang kabilang dulo. Hindi sinusuportahan ng pagkuha ang konklusyong iyon. Pinoprotektahan ng ESP ang isang direksyon ng usapan at wala itong kinukumpirma sa antas ng IP, kaya ang nawawalang pabalik na ESP ay maaaring mangahulugan na wala lang sasabihin ang aplikasyon, kasing-tiyak ng maaaring mangahulugan na patay na ang tunel. Basahin ang panloob na palitan at ang kalagayan ng tumatanggap na panig bago sisihin ang alinmang dulo.

Ang mito: bawat protektadong packet ay nakakakuha ng tugon

Ang ESP ay hindi isang protocol na hiling-tugon. Ine-encrypt at pinapatunayan nito ang anumang pinipili ng patakaran, at ang tumatanggap ay nagpapatunay, nagde-decrypt at naghahatid ng panloob na packet nang hindi gumagawa ng sarili nitong packet. Ang UDP query na binabalewala ng destinasyon, o ang ICMP echo na itinatapon ng papasok na patakaran, ay gumagawa ng katahimikan sa magkabilang direksyon bilang tamang resulta. Ang pagturing sa katahimikang iyon bilang pagkabigo ng transportasyon ay nagpapadala sa iyo upang maghanap ng sira ng network na hindi kailanman naroon.

Ang aktwal na pinatutunayan ng isang-direksyong pagkuha ay nag-encrypt ang stack ng nagpadala ng isang bagay sa puntong iyon ng pagmamasid. Wala tungkol sa pagdating, at wala tungkol sa layuning tumugon. Ang kapaki-pakinabang na tanong ay hindi „bakit walang tugon“ kundi „ano ang dapat na ginawa ng panloob na usapan“.

Dalawang SA, dalawang SPI, isang usapan

Ang mga security association ng IPsec ay isang-direksyon, kaya ang karaniwang protektadong palitan ay nagpapatakbo ng papasok na asosasyon at papalabas na asosasyon na may hiwalay na mga identifier at malayang kalagayan. Ang paghahanap ng pabalik na trapiko para sa SPI ng papalabas na packet ay kaya isang pagkakamali ng kategorya, dahil ang anumang tugon ay naglalakbay sa ilalim ng sariling papalabas na SA ng kapareha na may sariling SPI. Sa halip, itugma ang pares ayon sa mga tagapili ng trapiko at mga address ng kapareha.

Pinapalubha ng muling pagpapalit ng susi ang larawan sa loob ng ilang segundo, dahil maaaring mag-overlap ang luma at kapalit na kalagayan. Kung nagsimula ang sintomas sa paligid ng isang pagpapalit ng susi, kolektahin ang mga identifier ng asosasyon at mga timestamp nang sama-sama at hindi lamang ang pangalan ng koneksyon.

Ano ang dapat gawin ng tumatanggap bago may tumugon

Bawat hilera ay nabibigo nang hiwalay at bawat pagkabigo ay may ibang may-ari, kaya hindi sila matutukoy ng isang pagkuha. Ang papasok na counter ang tanging direktang ebidensya ng pagdating, dahil ang packet na nabigo sa pagpapatunay o sa pagsusuri ng pag-uulit ay itinatapon nang walang anumang tugon. Ang kaparehang hindi gumalaw ang papasok na counter ay wala talagang ibinibigay na impormasyon tungkol sa patakaran nito.

Ang paghahatid ay hiwalay na hakbang sa pagde-decrypt. Maaaring wasto ang kalagayan at itatapon pa rin ang packet mamaya ng papasok na patakaran o ng ruta na hindi kasama ang panloob na destinasyon, kaya tingnan kung nakita ng target na host ang plaintext sa halip na ipagpalagay na ang malinis na counter ay ibig sabihin ay nakarating ang packet sa gusto mong puntahan.

Ang native na ESP ay hindi UDP

Ang native na ESP ay IP protocol 50, na hindi TCP o UDP at walang anumang port. Kaya ang isang patakaran ng firewall na nagpapahintulot ng IKE sa UDP 500 ay walang sinasabi tungkol sa landas ng data, at ang filter na isinulat sa paligid ng mga port ay maaaring payagan ang tunel na makipagnegosasyon at pagkatapos ay itapon ang lahat ng dinadala sa loob nito. Subukan ang landas ng data nang hiwalay, sa mode na aktwal mong naobserbahan.

Sa likod ng NAT nagbabago ang hugis: ang protektadong payload ay naglalakbay sa loob ng UDP, karaniwang sa port 4500, gaya ng tinutukoy ng RFC 3948. Itala ang aktibong mode bago magsulat ng anumang patakaran, dahil ang isang aparato sa landas ay maaaring ituring ang native na ESP at ang ESP na nakabalot sa UDP nang lubos na naiiba, at pinapayagan ng ilang gitnang kahon ang isa habang itinatapon ang isa pa.

Basahin ang mga counter na kabilang sa insidenteng ito

Sa isang strongSwan host, ang swanctl --list-sas ay nag-uulat ng packet at byte counter bawat asosasyon sa parehong direksyon, na sapat upang paghiwalayin ang „hindi kailanman dumating“ sa „dumating at hindi sinagot“. Sa Linux, binibilang ng /proc/net/xfrm_stat ang pinagsama-samang mga pagkabigo tulad ng nawawalang kalagayan, nawawalang patakaran at mga error ng protocol. Ang mga kabuuang iyon ay naiipon mula sa boot at kabilang sa isang network namespace, kaya ang malaking numero ay hindi pagpapatungkol.

Kumuha ng dalawang pagbasa sa paligid ng bintana ng insidente sa tamang namespace at ihambing ang mga delta, kung hindi ay ikakabit mo ang mga error ng nakaraang linggo sa ticket ng hapong ito. Ilagay ang namespace at ang dalawang timestamp sa ticket upang ang susunod na mambabasa ay makagawa muli ng paghahambing sa halip na magtiwala sa isang kabuuan.

Pangalanan ang yugto, hindi ang pinaghihinalaan

Sinasabi ng kapaki-pakinabang na konklusyon kung saan huminto ang packet: hindi kailanman natanggap, natanggap at itinapon, naihatid ngunit walang tugon, o sinagot at nawala sa pagbabalik. Ang bawat isa ay tumuturo sa ibang may-ari at ibang susunod na utos. Ang „Walang tugon mula sa VPN server“ ay pinagsasama-sama ang apat na magkakaibang pagkabigo sa isang pangungusap na hindi kailanman nabigyang-katwiran ng pagkuha.

Panatilihing makitid ang mga pagkuha, at ilayo ang hilaw na kalagayan ng kernel sa mga ticket, dahil maaari itong magdala ng key material na hindi dapat umalis sa host. Ang mga delta ng counter at ang mga timestamp ang mga bahaging sulit ibigay sa susunod na tao.