IKEv2-registrering af død peer tester ikke din app

Livstjek i IKEv2 stiller ét spørgsmål: svarer den anden peer stadig på den beskyttede kontrolforbindelse. Det måler ikke, om en intern applikation er sund, om der findes en rute bag gatewayen, eller om browsing føles hurtigt. Tjekket kan bestå, mens alt nyttigt bag tunnelen fejler.

Læs de to slags beviser hver for sig, før du ændrer en timer.

Hvad livstjekket egentlig spørger om

En livsudveksling sendes inde i den etablerede IKE-sikkerhedsassociation og forventer et svar inden for et konfigureret vindue. Succes betyder, at peerens IKE-implementering stadig er der og stadig villig til at tale. Det siger intet om de underordnede sikkerhedsassociationer, der bærer trafik, intet om routing ud over gatewayen og intet om den tjeneste, du åbnede tunnelen for. Det er tre separate spørgsmål med tre separate fejltilstande.

Den forskel afgør, hvor du kigger hen, når en session bliver tavs. En peer, der bliver ved med at svare, mens en datasti er brudt, peger på politik, routing eller en tjeneste længere nede. En peer, der holder op med at svare, peger på nåbarhed eller på den fjerne ends egen tilstand.

Læs sikkerhedsassociationerne før browseren

Kontroltilstanden og datatilstanden listes hver for sig, når du spørger dæmonen, og tællerne fortæller, om der overhovedet blev forsøgt noget. En underordnet association, der aldrig blev installeret, ligner slet ikke en, der blev installeret og derefter holdt op med at sende pakker, selvom begge giver den samme brugerklage.

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

Skriv tilstandsnavnene ordret i billetten sammen med tællerne på klagetidspunktet. En beskrivelse som tunnel nede skjuler, hvilken af de to associationer der sluttede, og det er som regel den eneste kendsgerning, der er værd at have.

En rute-fejl ligner præcis en død peer

Gatewayen kan svare på kontroludvekslinger, mens en privat server er offline, en videresendt rute mangler, eller intern navneopløsning fejler helt. Fra klienten fremstår hver af dem som en session, der er oppe, og en destination, der ikke er. Tjek returvejen lige så omhyggeligt som vejen frem, fordi asymmetrisk routing på den fjerne side kun giver tavshed i én retning.

Test den tilsigtede applikation direkte, og navngiv den adresse, den forsøgte, i stedet for at teste, om tunnelen er oppe. Et ping til gatewayen beviser, at gatewayen svarer; det har aldrig bevist, at applikationen gjorde. Notér den præcise adresse, applikationen forsøgte. Den streng indsnævrer søgningen senere, og det er den ene kendsgerning, billetten som regel udelader.

Hold timere ude af diagnosen

At forkorte et registreringsinterval er ikke en ydelsesændring og tilføjer ikke kapacitet. Ved pakketab ændrer det, hvor hurtigt en fejl genkendes, hvilket kan få et symptom til at se anderledes ud uden at gøre noget bedre. Notér først det reelle fejltidspunkt, og afgør derefter, om tolerancen er forkert for det link, du faktisk har.

Opdateringer af NAT-mapping hører i samme kategori. De holder en oversat sti brugbar, og de er ikke bevis på, at den fjerne applikation virker.

En fuldstændig genopretningspolitik siger, hvad klienten skal gøre, når en peer erklæres død: genstarte, lukke eller holde, og hvad anden trafik må gøre, mens det sker. Uden det bliver den samme hændelse diagnosticeret forfra hvert kvartal.