Overvåking av et IPsec-tunellgrensesnitt: hva du bør lese

Et rutebasert IPsec-design installerer et virtuelt grensesnitt, og det grensesnittet gir overvåkingen et konkret objekt: noe med et navn, tellere og en rute knyttet til seg. Det er ikke et helsesignal i seg selv. Grensesnittet kan finnes mens ingen brukbar assosiasjon er installert, og en assosiasjon kan være sunn mens ingen rute sender den interessante trafikken dit. Det er å lese fire tilstander sammen som gjør en pakketeller til en diagnose.

Gå gjennom dem i rekkefølge og stopp ved den første som feiler.

Hva grensesnittet tilfører bildet

Med et policybasert design bor utvalget i IPsec-policytabellen, og kjernen avgjør hva som beskyttes ut fra trafikkvelgere. Et rutebasert design legger til et grensesnitt og en rute, slik at tcpdump og grensesnitttellere ser én grense i stedet for et sett velgere. Det er en reell gevinst for diagnostikk og for rutingsprotokoller som trenger et grensesnitt å peere over.

Gevinsten er administrativ, ikke kryptografisk. Grensesnittet rapporterer trafikken det bærer, og sier ingenting om hvorvidt motpartens beskyttelse er brukbar akkurat nå.

Les de fire tilstandene før du klandrer tunnelen

Start med grensesnittet og ruten, deretter assosiasjonen, deretter applikasjonen. Hver har sin egen kommando og sin egen feilsignatur. Et rent resultat på ett lag er ikke et rent resultat på det neste. Kjør alle fire før du trekker en konklusjon. Én grønn linje avgjør sjelden noe.

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

Et grensesnitt med en stigende teller, men uten en samsvarende tilstandsoppføring, beskriver trafikk som kommer inn på en vei der ingenting beskytter den, noe som er verre enn en tunnel som rett og slett er nede. En tilstandsoppføring uten en rute som velger grensesnittet, betyr at kryptografien er klar og ubrukt.

Applikasjonstesten kommer sist og med vilje: en vellykket ping til den andre siden av tunnelen beviser ikke at tjenesten bak aksepterer tilkoblinger.

Sammenlign indre tellere med ytre tellere

Tellere på tunellgrensesnittet måler indre trafikk; tellere og opptak på det fysiske grensesnittet viser den innkapslede utvekslingen. De to vil ikke samsvare en til en, fordi innkapsling legger til headere, retransmisjoner dupliserer noen pakker, og implementeringens regnskap følger sine egne regler. Forvent et forhold, ikke likhet.

Plasseringen av opptaket avgjør også hvilke private data du samler inn, så bruk smale filtre og en ufarlig testadresse i stedet for et fullstendig opptak av produksjonstrafikk.

Hvis de indre tellerne stiger og de ytre ikke, er det manglende trinnet vanligvis ruten eller policyen som sender pakker inn i tunnelen, ikke tunnelen selv.

Følg det gjennom rekey og failover

Observer en rekey, en hendelse med oppdagelse av død motpart og en lenkefailover mens du holder øye med de samme fire tilstandene. Et grensesnitt kan forbli til stede gjennom en rekey som aldri fullføres, og en failover kan etterlate en tilstandsoppføring som peker på en motpartsadresse som ikke lenger er nåbar.

Varsle på tjenestestien du faktisk er avhengig av, med assosiasjonens tilstand som kontekst, i stedet for på et enkelt opp- eller ned-flagg. Behold grensesnittnavnet, motpartsadressen og ruten i varslets nyttelast, slik at den som reagerer, ikke må gjenoppbygge dem.

strongSwan dokumenterer sin egen XFRM-grensesnittmodell, og andre plattformer navngir og implementerer det tilsvarende objektet annerledes. Les den rutebaserte sammenligningen for enheten foran deg før du overfører antakelser fra en annen implementering. En overvåkingsmal som passer én leverandørs tellere, vil stille villede på en annen.