It opspoaren fan in deade peer yn IKEv2 testet jo applikaasje net

De libbenskrêftkontrôle yn IKEv2 stelt ien fraach: antwurdet de oare peer noch op 'e beskerme kontrôlerelaasje. It mjit net oft in ynterne applikaasje sûn is, oft der in rûte efter de gateway bestiet, of oft browsen fluch oanfielt. De kontrôle kin slagje wylst alles nuttich efter de tunnel mislearret.

Lês de twa soarten bewiis apart foardat jo in timer feroarje.

Wat de libbenskrêftkontrôle eins freget

In libbenskrêftútwikseling wurdt binnen de oprjochte IKE-feiligensassosjaasje stjoerd en ferwachtet in antwurd binnen in konfigurearre finster. Sukses betsjut dat de IKE-ymplemintaasje fan 'e peer der noch is en noch ree om te praten. It seit neat oer de bern-feiligensassosjaasjes dy't ferkear drage, neat oer rûteleasing foarby de gateway en neat oer de tsjinst wêrfoar jo de tunnel iepenen. Dat binne trije aparte fragen mei trije aparte flaters.

Dat ûnderskied bepaalt wêr't jo sjogge as in sesje stil wurdt. In peer dy't trochgiet mei antwurdzjen wylst in gegevenspaad brutsen is, wiist op belied, rûteleasing of in tsjinst streamôf. In peer dy't ophâldt mei antwurdzjen wiist op berikberens of op 'e eigen steat fan 'e fiere kant.

Lês de feiligensassosjaasjes foar de browser

De kontrôlesteat en de gegevenssteat wurde apart neamd sadree't jo de daemon freegje, en de tellers fertelle oft der oait eat besocht is. In bern-assosjaasje dy't nea ynstallearre is, liket hielendal net op ien dy't ynstallearre is en doe ophold mei it trochjaan fan pakketten, ek al jouwe beide deselde klacht fan 'e brûker.

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

Skriuw de steatsnammen wurdlik yn it ticket, tegearre mei de tellers op it momint fan 'e klacht. In beskriuwing lykas tunnel del ferberget hokker fan 'e twa assosjaasjes einige, en dat is meastentiids it iennige feit dat it wurdich is om te hawwen.

In rûteflater liket krekt op in deade peer

De gateway kin antwurdzje op kontrôle-útwikselings wylst in partikuliere tsjinner offline is, in trochstjoerde rûte ûntbrekt of ynterne namme-oplossing hielendal mislearret. Fan 'e klant ôf liket elk dêrfan as in sesje dy't oan is en in bestimming dy't net oan is. Kontrolearje it werompaad like soarchfâldich as it hinnewei, want asymmetrysk rûteleasing oan 'e fiere kant produsearret stilte mar yn ien rjochting.

Test de bedoelde applikaasje direkt en neam it adres dat it besocht hat, ynstee fan te testen oft de tunnel oan is. In ping nei de gateway bewiist dat de gateway antwurdet; it hat nea bewiisd dat de applikaasje dat die. Registrearje it krekte adres dat de applikaasje besocht. Dy tekenrige ferfynt it sykjen letter, en it is it iene feit dat it ticket meastentiids weilitten.

Hâld timers bûten de diagnoaze

It koarter meitsjen fan in deteksje-ynterval is gjin prestaasjeferoaring en foeget gjin kapasiteit ta. By pakketferlies feroaret it hoe fluch in flater werkend wurdt, wat in symptoom oars lykje litte kin sûnder eat better te meitsjen. Registrearje earst de wiere tiid fan 'e flater, en beslute dan oft de tolerânsje ferkeard is foar de ferbining dy't jo eins hawwe.

NAT-mappingferfrissings hearre yn deselde kategory. Se hâlde in oerset paad brûkber, en se binne gjin bewiis dat de fiere applikaasje wurket.

In folslein herstbelied seit wat de klant dwaan moat as in peer dea ferklearre wurdt: werstarte, slute of hâlde, en wat oar ferkear dwaan mei wylst dat bart. Sûnder dat wurdt itselde ynsidint elk kwartaal fanôf nul op 'e nij diagnostisearre.