IKEv2:s detektering av död peer testar inte din app

IKEv2-livskontrollen ställer en fråga: svarar den andra peeren fortfarande på den skyddade kontrollrelationen. Den mäter inte om en intern applikation är frisk, om det finns en rutt bakom gatewayen, eller om surfandet känns snabbt. Kontrollen kan passera medan allt nyttigt bakom tunneln misslyckas.

Läs de två typerna av bevis separat innan du ändrar en timer.

Vad livskontrollen faktiskt frågar om

Ett livsutbyte skickas inom den etablerade IKE-säkerhetsassociationen och väntar på ett svar inom ett konfigurerat fönster. Framgång betyder att peerns IKE-implementering fortfarande finns där och fortfarande villig att prata. Den säger ingenting om barnsäkerhetsassociationerna som bär trafik, ingenting om routning bortom gatewayen och ingenting om tjänsten du öppnade tunneln för. Det är tre separata frågor med tre separata fellägen.

Den skillnaden avgör var du tittar när en session blir tyst. En peer som fortsätter svara medan en dataväg är trasig pekar på policy, routning eller en tjänst längre ned. En peer som slutar svara pekar på nåbarhet eller på det bortre ändens eget tillstånd.

Läs säkerhetsassociationerna före webbläsaren

Kontrolltillståndet och datatillståndet listas separat när du frågar daemonen, och räknarna säger om något alls försöktes. En barnassociation som aldrig installerades ser helt annorlunda ut än en som installerades och sedan slutade släppa igenom paket, även om båda ger samma användarklagomål.

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

Skriv tillståndsnamnen ordagrant i ärendet, tillsammans med räknarna i klagomålsögonblicket. En beskrivning som tunnel nere döljer vilken av de två associationerna som avslutades, och det är oftast det enda faktum som är värt att ha.

Ett ruttfel ser exakt ut som en död peer

Gatewayen kan svara på kontrollutbyten medan en privat server är offline, en vidarebefordrad rutt saknas eller intern namnmatchning misslyckas helt. Från klientens sida ser var och en av dessa ut som en session som är uppe och en destination som inte är det. Kontrollera returvägen lika noggrant som vägen framåt, eftersom asymmetrisk routning på den bortre sidan bara skapar tystnad i en riktning.

Testa den avsedda applikationen direkt och namnge adressen den försökte, i stället för att testa om tunneln är uppe. En ping till gatewayen bevisar att gatewayen svarar; det har aldrig bevisat att applikationen gjorde det. Anteckna den exakta adressen som applikationen försökte. Den strängen smalnar av sökningen senare, och det är det enda faktum som ärendet oftast utelämnar.

Håll timers utanför diagnosen

Att förkorta ett detektionsintervall är ingen prestandaförändring och ökar ingen kapacitet. Vid paketförlust ändrar det hur snabbt ett fel upptäcks, vilket kan få ett symtom att se annorlunda ut utan att göra något bättre. Anteckna först felets verkliga tid, besluta sedan om toleransen är fel för den länk du faktiskt har.

NAT-mappningsuppdateringar hör till samma kategori. De håller en översatt väg användbar, och de är inget bevis för att den fjärran applikationen fungerar.

En fullständig återställningspolicy säger vad klienten ska göra när en peer förklaras död: starta om, stänga eller hålla kvar, och vad annan trafik får göra medan det sker. Utan det diagnostiseras samma incident om från början varje kvartal.