Detectarea peer-ului mort la IKEv2 nu testează aplicația ta

Verificarea de vitalitate IKEv2 pune o singură întrebare: mai răspunde celălalt peer pe relația de control protejată. Nu măsoară dacă o aplicație internă este sănătoasă, dacă există o rută în spatele gateway-ului sau dacă navigarea pare rapidă. Verificarea poate trece în timp ce tot ce este util în spatele tunelului eșuează.

Citește cele două tipuri de dovezi separat înainte de a schimba un timer.

Ce întreabă de fapt verificarea de vitalitate

Un schimb de vitalitate este trimis în asociația de securitate IKE stabilită și așteaptă un răspuns într-o fereastră configurată. Succesul înseamnă că implementarea IKE a peer-ului este încă acolo și încă dispusă să vorbească. Nu spune nimic despre asociațiile de securitate copil care transportă trafic, nimic despre rutarea dincolo de gateway și nimic despre serviciul pentru care ai deschis tunelul. Sunt trei întrebări separate cu trei moduri separate de eșec.

Acea distincție decide unde te uiți când o sesiune devine tăcută. Un peer care continuă să răspundă în timp ce o cale de date este stricată indică politica, rutarea sau un serviciu din aval. Un peer care nu mai răspunde indică accesibilitatea sau starea capătului îndepărtat.

Citește asociațiile de securitate înainte de browser

Starea de control și starea de date sunt listate separat când întrebi daemonul, iar contoarele spun dacă s-a încercat ceva. O asociație copil care nu a fost niciodată instalată nu arată deloc ca una care a fost instalată și apoi a încetat să mai treacă pachete, deși ambele produc aceeași reclamație a utilizatorului.

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

Notează numele stărilor exact în tichet, împreună cu contoarele din momentul reclamației. O descriere de tipul tunel căzut ascunde care dintre cele două asociații s-a terminat, iar acesta este de obicei singurul fapt care merită păstrat.

O defecțiune de rută arată exact ca un peer mort

Gateway-ul poate răspunde la schimburile de control în timp ce un server privat este offline, o rută redirecționată lipsește sau rezolvarea internă a numelor eșuează complet. Din perspectiva clientului, fiecare dintre acestea apare ca o sesiune activă și o destinație inactivă. Verifică calea de întoarcere la fel de atent ca calea directă, pentru că rutarea asimetrică de pe partea îndepărtată produce tăcere doar într-o singură direcție.

Testează direct aplicația vizată și numește adresa pe care a încercat-o, în loc să testezi dacă tunelul este activ. Un ping către gateway dovedește că gateway-ul răspunde; nu a dovedit niciodată că a răspuns aplicația. Înregistrează adresa exactă pe care a încercat-o aplicația. Acel șir îngustează căutarea mai târziu și este singurul fapt pe care tichetul îl omite de obicei.

Ține timerele în afara diagnosticului

Scurtarea unui interval de detecție nu este o schimbare de performanță și nu adaugă capacitate. La pierdere de pachete, schimbă cât de repede este recunoscută o defecțiune, ceea ce poate face un simptom să pară diferit fără să îmbunătățească nimic. Înregistrează mai întâi momentul real al defecțiunii, apoi decide dacă toleranța este greșită pentru legătura pe care o ai cu adevărat.

Reîmprospătările mapării NAT fac parte din aceeași categorie. Ele mențin o cale tradusă utilizabilă și nu sunt dovada că aplicația de la distanță funcționează.

O politică completă de recuperare spune ce trebuie să facă clientul când un peer este declarat mort: repornire, închidere sau menținere, și ce poate face alt trafic în timpul acesta. Fără ea, același incident este diagnosticat de la zero în fiecare trimestru.