Zbulimi i peer-it të vdekur në IKEv2 nuk teston aplikacionin tuaj

Kontrolli i gjallërisë së IKEv2 bën një pyetje: a po përgjigjet ende peer-i tjetër në marrëdhënien e kontrollit të mbrojtur. Nuk mat nëse një aplikacion i brendshëm është i shëndetshëm, nëse ekziston një rrugë pas gateway-it, apo nëse shfletimi duket i shpejtë. Kontrolli mund të kalojë ndërsa çdo gjë e dobishme pas tunelit dështon.

Lexoni dy llojet e provave veçmas përpara se të ndryshoni një timer.

Çfarë pyet në të vërtetë kontrolli i gjallërisë

Një shkëmbim gjallërie dërgohet brenda asociacionit të sigurisë IKE të vendosur dhe pret një përgjigje brenda një dritareje të konfiguruar. Suksesi do të thotë që implementimi IKE i peer-it është ende aty dhe ende i gatshëm të flasë. Nuk thotë asgjë për asociacionet e sigurisë fëmijë që mbajnë trafikun, asgjë për rrugëtimin përtej gateway-it dhe asgjë për shërbimin për të cilin hapët tunelin. Këto janë tre pyetje të veçanta me tre mënyra të veçanta dështimi.

Ky dallim vendos ku të shikoni kur sesioni hesht. Një peer që vazhdon të përgjigjet ndërsa rruga e të dhënave është e prishur tregon politikë, rrugëtim ose një shërbim në rrjedhën e poshtme. Një peer që ndalon së përgjigjuri tregon arritshmërinë ose gjendjen e skajit të largët.

Lexoni asociacionet e sigurisë përpara shfletuesit

Gjendja e kontrollit dhe gjendja e të dhënave listohen veçmas kur pyesni daemon-in, dhe numëruesit tregojnë nëse u provua diçka fare. Një asociacion fëmijë që nuk u instalua kurrë duket krejt ndryshe nga një që u instalua dhe pastaj ndaloi kalimin e paketave, edhe pse të dyja prodhojnë të njëjtin ankesë të përdoruesit.

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

Shkruani emrat e gjendjeve fjalë për fjalë në ticket, së bashku me numëruesit në momentin e ankesës. Një përshkrim si tunel poshtë fsheh cili nga dy asociacionet përfundoi, dhe zakonisht ky është fakti i vetëm që ia vlen të mbahet.

Një dështim rruge duket saktësisht si një peer i vdekur

Gateway-i mund t'u përgjigjet shkëmbimeve të kontrollit ndërsa një server privat është jashtë linje, një rrugë e përçuar mungon ose zgjidhja e emrave të brendshëm dështon plotësisht. Nga këndvështrimi i klientit, secili prej tyre shfaqet si një sesion që është lart dhe një destinacion që nuk është. Kontrolloni rrugën e kthimit po aq me kujdes sa rrugën e shkuarjes, sepse rrugëtimi asimetrik në anën e largët prodhon heshtje vetëm në një drejtim.

Testoni aplikacionin e synuar drejtpërdrejt dhe emërtoni adresën që provoi, në vend që të testoni nëse tuneli është lart. Një ping drejt gateway-it provon që gateway-i përgjigjet; nuk ka provuar kurrë që aplikacioni u përgjigj. Regjistroni adresën e saktë që provoi aplikacioni. Ai varg ngushton kërkimin më vonë, dhe është fakti i vetëm që ticket-i zakonisht e lë jashtë.

Mbajini timer-ët jashtë diagnozës

Shkurtimi i intervalit të zbulimit nuk është ndryshim performance dhe nuk shton kapacitet. Nën humbje paketash ndryshon sa shpejt njihet një dështim, gjë që mund ta bëjë një simptomë të duket ndryshe pa përmirësuar asgjë. Regjistroni së pari kohën reale të dështimit, pastaj vendosni nëse toleranca është e gabuar për lidhjen që keni vërtet.

Rifreskimet e hartëzimit NAT i përkasin të njëjtës kategori. Ato e mbajnë një rrugë të përkthyer të përdorshme, dhe nuk janë provë që aplikacioni i largët funksionon.

Një politikë e plotë rikuperimi thotë çfarë duhet të bëjë klienti kur një peer shpallet i vdekur: rinisje, mbyllje ose mbajtje, dhe çfarë mund të bëjë trafiku tjetër ndërsa kjo ndodh. Pa të, i njëjti incident ridiagnostikohet nga e para çdo tremujor.