Provjera živosti u IKEv2 postavlja jedno pitanje: odgovara li drugi partner još uvijek na zaštićenoj kontrolnoj vezi. Ona ne mjeri je li unutrašnja aplikacija zdrava, postoji li ruta iza pristupnika i izgleda li pregledanje brzo. Provjera može proći dok sve korisno iza tunela ne uspijeva.

Pročitajte dvije vrste dokaza odvojeno prije nego promijenite tajmer.

Šta provjera živosti zapravo pita

Razmjena živosti šalje se unutar uspostavljene IKE sigurnosne asocijacije i očekuje odgovor u zadanom prozoru. Uspjeh znači da IKE implementacija partnera još uvijek postoji i još uvijek je spremna razgovarati. To ne govori ništa o podređenim sigurnosnim asocijacijama koje nose promet, ništa o usmjeravanju iza pristupnika i ništa o usluzi zbog koje ste otvorili tunel. To su tri odvojena pitanja s tri odvojena načina neuspjeha.

Ta razlika odlučuje gdje ćete gledati kada sesija utihne. Partner koji nastavlja odgovarati dok je putanja podataka pokvarena upućuje na politiku, usmjeravanje ili uslugu nizvodno. Partner koji prestane odgovarati upućuje na dostupnost ili na vlastito stanje udaljenog kraja.

Pročitajte sigurnosne asocijacije prije preglednika

Kontrolno stanje i stanje podataka navode se odvojeno čim upitate demona, a brojači kažu je li se uopće nešto pokušalo. Podređena asocijacija koja nikad nije instalirana ne izgleda nimalo kao ona koja se instalirala i zatim prestala propuštati pakete, iako obje daju istu korisničku žalbu.

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

Zapišite nazive stanja doslovno u tiketu, zajedno s brojačima u trenutku žalbe. Opis poput tunel pao skriva koja je od dvije asocijacije završila, a to je obično jedina činjenica koju vrijedi imati.

Neuspjeh rute izgleda isto kao mrtav partner

Pristupnik može odgovarati na kontrolne razmjene dok je privatni poslužitelj izvan mreže, proslijeđena ruta nedostaje ili unutrašnje razrješavanje imena potpuno ne uspijeva. S klijentske strane svako od toga izgleda kao sesija koja radi i odredište koje ne radi. Provjerite povratnu putanju jednako pažljivo kao putanju naprijed, jer asimetrično usmjeravanje na udaljenoj strani stvara tišinu samo u jednom smjeru.

Testirajte namjeravanu aplikaciju izravno i navedite adresu koju je pokušala, umjesto da testirate je li tunel podignut. Ping prema pristupniku dokazuje da pristupnik odgovara; nikad nije dokazao da je aplikacija odgovorila. Zabilježite točnu adresu koju je aplikacija pokušala. Taj niz kasnije sužava pretragu i to je jedina činjenica koju tiket obično izostavlja.

Držite tajmere izvan dijagnoze

Skraćivanje intervala otkrivanja nije promjena performansi i ne dodaje kapacitet. Pri gubitku paketa mijenja koliko se brzo kvar prepoznaje, što simptom može učiniti drugačijim bez da išta poboljša. Prvo zabilježite stvarno vrijeme kvara, zatim odlučite je li tolerancija pogrešna za vezu koju stvarno imate.

Osvježavanja NAT mapiranja pripadaju istoj kategoriji. Ona održavaju prevedenu putanju upotrebljivom i nisu dokaz da udaljena aplikacija radi.

Potpuna politika oporavka kaže šta klijent treba učiniti kada se partner proglasi mrtvim: ponovno pokrenuti, zatvoriti ili zadržati, i šta smije raditi drugi promet dok se to događa. Bez toga se isti incident iznova dijagnosticira od nule svako tromjesečje.

Povezani članci