Overvaking av eit IPsec-tunellgrensesnitt: kva du bør lese

Eit rutebasert IPsec-design installerer eit virtuelt grensesnitt, og det grensesnittet gir overvakinga eit konkret objekt: noko med eit namn, teljarar og ei rute knytt til seg. Det er ikkje eit helsesignal i seg sjølv. Grensesnittet kan finnast medan ingen brukbar assosiasjon er installert, og ein assosiasjon kan vere sunn medan inga rute sender den interessante trafikken dit. Det er å lese fire tilstandar saman som gjer ein pakketeljar til ein diagnose.

Gå gjennom dei i rekkefølgje og stopp ved den første som feilar.

Kva grensesnittet tilfører biletet

Med eit policybasert design bur utvalet i IPsec-policytabellen, og kjernen avgjer kva som blir verna ut frå trafikkveljarar. Eit rutebasert design legg til eit grensesnitt og ei rute, slik at tcpdump og grensesnittteljarar ser éin grense i staden for eit sett veljarar. Det er ein reell vinst for diagnostikk og for rutingsprotokollar som treng eit grensesnitt å peere over.

Vinsten er administrativ, ikkje kryptografisk. Grensesnittet rapporterer trafikken det ber, og seier ingenting om korvidt vernet til motparten er brukbart akkurat no.

Les dei fire tilstandane før du klandrar tunnelen

Start med grensesnittet og ruta, deretter assosiasjonen, deretter applikasjonen. Kvar har sin eigen kommando og sin eigen feilsignatur. Eit reint resultat på eitt lag er ikkje eit reint resultat på det neste. Køyr alle fire før du dreg ein konklusjon. Éi grøn linje avgjer sjeldan noko.

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

Eit grensesnitt med ein stigande teljar, men utan ei samsvarande tilstandsoppføring, skildrar trafikk som kjem inn på ein veg der ingenting vernar han, noko som er verre enn ein tunnel som rett og slett er nede. Ei tilstandsoppføring utan ei rute som vel grensesnittet, betyr at kryptografien er klar og ubrukt.

Applikasjonstesten kjem sist og med vilje: ein vellukka ping til den andre sida av tunnelen beviser ikkje at tenesta bak tek imot tilkoplingar.

Samanlikn indre teljarar med ytre teljarar

Teljarar på tunellgrensesnittet måler indre trafikk; teljarar og opptak på det fysiske grensesnittet viser den innkapsla utvekslinga. Dei to vil ikkje samsvare ein til ein, fordi innkapsling legg til hovud, omsendingar dupliserer nokre pakkar, og rekneskapen til implementasjonen følgjer sine eigne reglar. Vent eit forhold, ikkje likskap.

Plasseringa av opptaket avgjer òg kva private data du samlar inn, så bruk smale filter og ei ufarleg testadresse i staden for eit fullstendig opptak av produksjonstrafikk.

Viss dei indre teljarane stig og dei ytre ikkje, er det manglande steget vanlegvis ruta eller policyen som sender pakkar inn i tunnelen, ikkje tunnelen sjølv.

Følg det gjennom rekey og failover

Observer ein rekey, ei hending med oppdaging av død motpart og ein lenkefailover medan du held auga med dei same fire tilstandane. Eit grensesnitt kan bli verande til stades gjennom ein rekey som aldri blir fullført, og ein failover kan etterlate ei tilstandsoppføring som peikar på ei motpartsadresse som ikkje lenger er nåbar.

Varsle på tenestestien du faktisk er avhengig av, med tilstanden til assosiasjonen som kontekst, i staden for på eit enkelt opp- eller ned-flagg. Hald grensesnittnamnet, motpartsadressa og ruta i nyttelasta til varselet, slik at den som reagerer, ikkje må byggje dei opp att.

strongSwan dokumenterer sin eigen XFRM-grensesnittmodell, og andre plattformer namngir og implementerer det tilsvarande objektet annleis. Les den rutebaserte samanlikninga for eininga framfor deg før du overfører antakingar frå ein annan implementasjon. Ein overvakingsmal som passar teljarane til éin leverandør, vil stille villede på ein annan.