IKEv2-deteksjon av død peer tester ikke appen din
En livstest prøver partsforholdet, ikke svartiden til et nettsted. En gateway som svarer kan stå ved siden av en ødelagt applikasjonsrute.
IKEv2-livstest stiller ett spørsmål: svarer den andre parten fortsatt på den beskyttede kontrollrelasjonen. Den måler ikke om en intern applikasjon er frisk, om det finnes en rute bak gatewayen, eller om nettsurfing føles raskt. Testen kan passere mens alt nyttig bak tunnelen svikter.
Les de to slags bevis hver for seg før du endrer en timer.
Hva livstesten egentlig spør om
En livsutveksling sendes innenfor den etablerte IKE-sikkerhetsassosiasjonen og venter et svar innenfor et konfigurert vindu. Suksess betyr at IKE-implementasjonen til parten fortsatt er der og fortsatt villig til å snakke. Den sier ingenting om barneassosiasjonene som bærer trafikk, ingenting om ruting bortenfor gatewayen, og ingenting om tjenesten du åpnet tunnelen for. Det er tre separate spørsmål med tre separate feilmåter.
Den forskjellen avgjør hvor du ser når en sesjon blir stille. En part som fortsetter å svare mens en datavei er ødelagt, peker på policy, ruting eller en tjeneste lenger ned. En part som slutter å svare peker på tilgjengelighet eller på tilstanden til den fjerne enden selv.
Les sikkerhetsassosiasjonene før nettleseren
Kontrolltilstanden og datatilstanden listes hver for seg når du spør daemonen, og tellerne sier om noe i det hele tatt ble forsøkt. En barneassosiasjon som aldri ble installert ser helt annerledes ut enn en som ble installert og så sluttet å slipped pakker gjennom, selv om begge gir samme brukerklage.
ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'
Skriv tilstandsnavnene ordrett i saken, sammen med tellerne i klageøyeblikket. En beskrivelse som tunnel nede skjuler hvilken av de to assosiasjonene som endte, og det er vanligvis det eneste faktumet som er verdt å ha.
En rutefeil ser nøyaktig ut som en død part
Gatewayen kan svare på kontrollutvekslinger mens en privat server er frakoblet, en videresendt rute mangler, eller intern navneoppslag svikter helt. Fra klientens side ser hver av disse ut som en sesjon som er oppe og en destinasjon som ikke er det. Kontroller returveien like nøye som veien fram, fordi asymmetrisk ruting på den fjerne siden lager stillhet bare i én retning.
Test den tiltenkte applikasjonen direkte og nevn adressen den prøvde, i stedet for å teste om tunnelen er oppe. En ping til gatewayen beviser at gatewayen svarer; det har aldri bevist at applikasjonen gjorde det. Skriv ned den nøyaktige adressen applikasjonen prøvde. Den strengen snevrer inn søket senere, og det er det eneste faktumet saken vanligvis utelater.
Hold timere utenfor diagnosen
Avkorting av et deteksjonsintervall er ikke en ytelsesendring og legger ikke til kapasitet. Ved pakketap endrer det hvor raskt en feil blir kjent, noe som kan få et symptom til å se annerledes ut uten å gjøre noe bedre. Skriv først ned den virkelige tiden for feilen, og avgjør så om toleransen er gal for sambandet du faktisk har.
NAT-mapping-fornyelser hører i samme kategori. De holder en oversatt vei brukbar, og de er ikke bevis for at den fjerne applikasjonen virker.
En fullstendig gjenopprettingspolicy sier hva klienten skal gjøre når en part erklæres død: starte på nytt, lukke eller holde, og hva annen trafikk kan gjøre mens det skjer. Uten det blir samme hendelse diagnostisert på nytt fra bunnen av hvert kvartal.