Hindi sinusubok ng IKEv2 dead peer detection ang iyong app

Isang tanong lang ang tinatanong ng IKEv2 liveness check: sumasagot pa ba ang kabilang peer sa protektadong control relationship. Hindi nito sinusukat kung malusog ang isang panloob na aplikasyon, kung may ruta sa likod ng gateway, o kung mabilis ang pakiramdam sa pagba-browse. Maaaring pumasa ang check habang bumabagsak ang lahat ng kapaki-pakinabang sa likod ng tunnel.

Basahin nang hiwalay ang dalawang uri ng ebidensya bago baguhin ang isang timer.

Ano ba talaga ang tinatanong ng liveness check

Ang liveness exchange ay ipinapadala sa loob ng naitatag na IKE security association at umaasa ng sagot sa loob ng naka-configure na window. Ang tagumpay ay nangangahulugang nandiyan pa rin ang IKE implementation ng peer at handa pa ring makipag-usap. Wala itong sinasabi tungkol sa mga child security association na nagdadala ng trapiko, wala tungkol sa routing sa kabila ng gateway, at wala tungkol sa serbisyo kung saan mo binuksan ang tunnel. Tatlong magkakaibang tanong ito na may tatlong magkakaibang paraan ng pagpalya.

Ang pagkakaibang iyon ang nagtatakda kung saan titingin kapag tumahimik ang session. Ang peer na patuloy na sumasagot habang sira ang data path ay tumutukoy sa patakaran, routing, o isang serbisyong nasa ibaba. Ang peer na tumigil sa pagsagot ay tumutukoy sa maabot o sa sariling kalagayan ng malayong dulo.

Basahin ang security associations bago ang browser

Hiwalay na nakalista ang control state at data state kapag tinanong mo ang daemon, at sinasabi ng mga counter kung may sinubukan man. Ang child association na hindi kailanman na-install ay ibang-iba sa tiningnan kaysa sa na-install at pagkatapos ay tumigil sa pagpapadaan ng mga packet, kahit pareho silang gumagawa ng parehong reklamo ng user.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Isulat ang mga pangalan ng estado nang eksakto sa ticket, kasama ang mga counter sa sandali ng reklamo. Ang paglalarawang tulad ng tunnel down ay nagtatago kung alin sa dalawang association ang natapos, at iyon ang karaniwang tanging katotohanang sulit itago.

Ang pagkabigo ng ruta ay mukhang eksaktong patay na peer

Maaaring sumagot ang gateway sa mga control exchange habang offline ang isang pribadong server, kulang ang isang forwarded route, o tuluyang nabigo ang panloob na name resolution. Mula sa pananaw ng client, ang bawat isa sa mga ito ay lumilitaw na session na bukas at destinasyong hindi bukas. Suriin ang return path nang kasing-ingat ng forward path, dahil ang asymmetric routing sa malayong panig ay gumagawa ng katahimikan sa isang direksyon lamang.

Subukan nang direkta ang nilalayong aplikasyon at pangalanan ang address na sinubukan nito, sa halip na subukan kung bukas ang tunnel. Ang ping sa gateway ay nagpapatunay na sumasagot ang gateway; hindi kailanman napatunayan nito na sumagot ang aplikasyon. Itala ang eksaktong address na sinubukan ng aplikasyon. Ang string na iyon ay nagpapaliit ng paghahanap mamaya, at iyon ang tanging katotohanang karaniwang iniiwan ng ticket.

Ilayo ang mga timer sa diagnosis

Ang pagpapaikli ng detection interval ay hindi pagbabago ng performance at hindi nagdadagdag ng kapasidad. Sa packet loss, binabago nito kung gaano kabilis makilala ang pagkabigo, na maaaring gawing iba ang hitsura ng sintomas nang walang pinapabuti. Itala muna ang tunay na oras ng pagkabigo, pagkatapos ay magpasya kung mali ang tolerance para sa link na talagang mayroon ka.

Ang mga NAT mapping refresh ay kabilang sa parehong kategorya. Pinapanatili nilang magagamit ang isang naisaling ruta, at hindi sila patunay na gumagana ang malayong aplikasyon.

Ang kumpletong recovery policy ay nagsasabi kung ano ang dapat gawin ng client kapag ang isang peer ay idineklarang patay: i-restart, isara, o hawakan, at ano ang maaaring gawin ng ibang trapiko habang nangyayari iyon. Kung wala iyon, ang parehong insidente ay muling sinusuri mula sa simula tuwing quarter.