Monitorizarea unei interfețe de tunel IPsec: ce merită citit

Un design IPsec bazat pe rute instalează o interfață virtuală, iar acea interfață oferă monitorizării un obiect concret: ceva cu un nume, contoare și o rută atașată de el. Nu este, de unul singur, un semnal de sănătate. Interfața poate exista în timp ce nu este instalată nicio asociere utilizabilă, iar o asociere poate fi sănătoasă în timp ce nicio rută nu îi trimite traficul de interes. Citirea împreună a patru stări este ceea ce transformă un contor de pachete într-un diagnostic.

Parcurge-le în ordine și oprește-te la primul care eșuează.

Ce adaugă interfața la tablou

Într-un design bazat pe politici, selecția stă în tabelul de politici IPsec, iar nucleul decide ce este protejat pe baza selectorilor de trafic. Un design bazat pe rute adaugă o interfață și o rută, astfel încât tcpdump și contoarele interfeței văd o singură graniță în locul unui set de selectori. Este un câștig real pentru diagnostic și pentru protocoalele de rutare care au nevoie de o interfață peste care să facă peering.

Câștigul este administrativ, nu criptografic. Interfața raportează traficul pe care îl transportă și nu spune nimic despre dacă protecția peerului este utilizabilă în acest moment.

Citește cele patru stări înainte de a da vina pe tunel

Începe cu interfața și ruta, apoi cu asocierea, apoi cu aplicația. Fiecare are propria comandă și propria semnătură de eșec. Un rezultat curat la un nivel nu este un rezultat curat la următorul. Rulează toate patru înainte de a trage o concluzie. O singură linie verde rareori lămurește ceva.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

O interfață cu un contor care crește, dar fără o intrare de stare corespunzătoare, descrie trafic care intră pe o cale pe care nimic nu îl protejează, ceea ce este mai rău decât un tunel pur și simplu căzut. O intrare de stare fără o rută care să selecteze interfața înseamnă că criptografia este gata și nefolosită.

Testul aplicației vine ultimul și intenționat: un ping reușit către cealaltă parte a tunelului nu dovedește că serviciul din spate acceptă conexiuni.

Compară contoarele interioare cu cele exterioare

Contoarele de pe interfața de tunel măsoară traficul interior; contoarele și capturile de pe interfața fizică arată schimbul încapsulat. Cele două nu se vor potrivi unu la unu, pentru că încapsularea adaugă antete, retransmisiile dublează unele pachete, iar contabilitatea implementării urmează reguli proprii. Așteaptă-te la un raport, nu la o egalitate.

Amplasarea capturii decide și ce date private colectezi, așa că folosește filtre înguste și o adresă de test inofensivă în locul unei capturi complete a traficului de producție.

Dacă numărătorile interioare cresc, iar cele exterioare nu, pasul lipsă este de obicei ruta sau politica ce trimite pachetele în tunel, nu tunelul în sine.

Urmărește-l prin rekey și failover

Observă un rekey, un eveniment de detectare a peerului mort și un failover de legătură în timp ce urmărești aceleași patru stări. O interfață poate rămâne prezentă în timpul unui rekey care nu se finalizează niciodată, iar un failover poate lăsa o intrare de stare îndreptată spre o adresă de peer care nu mai este accesibilă.

Alertează pe calea de serviciu de care depinzi de fapt, cu starea asocierii ca context, în locul unui singur indicator sus sau jos. Păstrează numele interfeței, adresa peerului și ruta în payload-ul alertei, ca cel care răspunde să nu le reconstruiască.

strongSwan își documentează propriul model de interfață XFRM, iar alte platforme numesc și implementează diferit obiectul echivalent. Citește comparația bazată pe rute pentru dispozitivul din fața ta înainte de a transfera presupuneri dintr-o altă implementare. Un șablon de monitorizare potrivit contoarelor unui furnizor va induce în eroare în liniște la altul.