Overvågning af en IPsec-tunnelinterface: hvad du skal læse

Et rutebaseret IPsec-design installerer en virtuel grænseflade, og den grænseflade giver overvågningen et konkret objekt: noget med et navn, tællere og en rute knyttet til sig. Det er ikke i sig selv et sundhedssignal. Grænsefladen kan eksistere, mens der ikke er installeret nogen brugbar association, og en association kan være sund, mens ingen rute sender den interessante trafik dens vej. Det er at læse fire tilstande sammen, der gør en pakketæller til en diagnose.

Gå dem igennem i rækkefølge, og stop ved den første, der fejler.

Hvad grænsefladen tilføjer til billedet

Med et politikbaseret design bor udvælgelsen i IPsec-politiktabellen, og kernen afgør, hvad der beskyttes ud fra trafikvælgere. Et rutebaseret design tilføjer en grænseflade og en rute, så tcpdump og grænsefladetællere ser én grænse i stedet for et sæt vælgere. Det er en reel gevinst for diagnostikken og for routingprotokoller, der har brug for en grænseflade at peere over.

Gevinsten er administrativ, ikke kryptografisk. Grænsefladen rapporterer den trafik, den bærer, og siger intet om, hvorvidt peerens beskyttelse er brugbar i øjeblikket.

Læs de fire tilstande, før du bebrejder tunnelen

Start med grænsefladen og ruten, derefter associationen, derefter applikationen. Hver har sin egen kommando og sin egen fejlsignatur. Et rent resultat på ét lag er ikke et rent resultat på det næste. Kør alle fire, før du drager en konklusion. Én grøn linje afgør sjældent noget.

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

En grænseflade med en stigende tæller, men uden en matchende tilstandspost, beskriver trafik, der går ind på en vej, hvor intet beskytter den, hvilket er værre end en tunnel, der blot er nede. En tilstandspost uden en rute, der vælger grænsefladen, betyder, at kryptografien er klar og ubrugt.

Applikationstesten kommer sidst og med vilje: en vellykket ping til den anden side af tunnelen beviser ikke, at tjenesten bagved accepterer forbindelser.

Sammenlign indre tællere med ydre tællere

Tællere på tunnelgrænsefladen måler indre trafik; tællere og optagelser på den fysiske grænseflade viser den indkapslede udveksling. De to vil ikke matche en til en, fordi indkapsling tilføjer headere, gensendinger duplikerer nogle pakker, og implementeringens bogføring følger sine egne regler. Forvent et forhold, ikke lighed.

Optagelsens placering afgør også, hvilke private data du indsamler, så brug snævre filtre og en uskadelig testadresse i stedet for en fuld optagelse af produktionstrafik.

Hvis de indre tællere stiger, og de ydre ikke gør, er det manglende trin normalt ruten eller politikken, der sender pakker ind i tunnelen, ikke tunnelen selv.

Følg det gennem rekey og failover

Observer en rekey, en begivenhed med registrering af død peer og en link-failover, mens du holder øje med de samme fire tilstande. En grænseflade kan forblive til stede gennem en rekey, der aldrig fuldføres, og en failover kan efterlade en tilstandspost, der peger på en peeradresse, som ikke længere kan nås.

Alarmér på den tjenestesti, du faktisk afhænger af, med associationens tilstand som kontekst, i stedet for på et enkelt op- eller ned-flag. Behold grænsefladenavnet, peeradressen og ruten i alarmens nyttelast, så den, der reagerer, ikke skal rekonstruere dem.

strongSwan dokumenterer sin egen XFRM-grænseflademodel, og andre platforme navngiver og implementerer det tilsvarende objekt anderledes. Læs den rutebaserede sammenligning for den enhed, du har foran dig, før du overfører antagelser fra en anden implementering. En overvågningsskabelon, der passer til én leverandørs tællere, vil stille vildlede på en anden.