Korleis sjekke om ein Linux VPN-tunnel verkeleg er oppe

Cron startar ein heilt frisk VPN på nytt kvart tiande minutt, og same jobben lèt ein daud køyre i ei veke. Begge feila kjem av å handsame «oppe» som eitt faktum når det er minst fire. Ei eining kan vere administrativt aktivert, rett ruta, fullt kryptert og likevel ikkje frakte noko nyttig. Skil observasjonane først, og kontrollen skriv seg nesten sjølv.

Koplingsflagg skildrar eininga, ikkje vegen

Kontrollen alle kopierer, leitar etter ei maskinvareadresse av berre nullar. Det trikset skil eit ekte grensesnitt frå ein plasshaldar i nokre drivarar og provar ingenting i resten, fordi ei tun-eining ikkje har nokon MAC å rapportere i det heile. ip -brief link show tun0 gir i staden flagg: UP tyder at ein administrator aktiverte eininga, og LOWER_UP tyder at drivaren reknar koplinga som brukbar. Lesne saman seier dei at eininga finst og ikkje er administrativt nede. Ingen av dei seier at ein pakke har nokon stad å gå.

OpenVPN lagar tun-eininga si før ruter blir installerte, så flagga kan sjå perfekte ut medan ingenting er ruta. Handsame dei som ein føresetnad, aldri som svaret.

Spør kvar ein pakke ville gå

Ruteoppslaget svarar på spørsmålet flagga ikkje kan. ip route get 10.8.0.1 from 10.8.0.2 namngir grensesnittet, kjeldeadressa og tabellen kjernen ville bruke, og det er nøyaktig det ein delt tunnel må kontrollerast mot. Utan kjeldeadressa spør du om noko anna, og med policy-ruting kan svaret variere per kjelde. Dette er den billegaste ærlege testen, fordi han rådfører seg med dei same reglane som trafikken din vil bruke.

For WireGuard, legg til handtrykket. wg show skriv ut eit tidsstempel for siste handtrykk per peer, og eit tidsstempel som har slutta å flytte seg framover tyder at peeren er borte, uansett kva grensesnittflagga seier. Eit konfigurert grensesnitt utan nyleg handtrykk er ein av dei vanlegaste falske positiva i heimelaga overvaking.

Tabell 220 fortel historia til IPsec

strongSwan installerer ruter for forhandla selektorar i tabell 220 når ruteinstallasjon er aktivert. ip route list table 220 skil difor forhandla frå ruta: ein tom tabell ved sida av ei lasta tilkopling tyder at IKE- og CHILD-SA-ane kom opp medan ingen trafikk blir leia inn i dei. Sjekk ip xfrm state ved sida av, sidan ho listar dei installerte tryggingsassosiasjonane og endepunkta deira.

Ein fellepolitikk er tilfellet ein bør vere merksam på. Han ventar på interessant trafikk i staden for å rute han, så tabellen blir verande tom til noko utløyser tunnelen.

Handsamingstilstand og daemontilstand er ulike lister

NetworkManager listar berre tilkoplingane han eig. nmcli -t -f NAME,TYPE connection show --active returnerer ingenting for ein tunnel starta direkte av wg-quick eller av ein OpenVPN-daemon.

Den skilnaden tyder noko når eit skript må avgjere kva av to handsamarar det skal spørje. Vel den som faktisk eig tunnelen på denne verten, og ignorer stilla til den andre. Viss begge finst, avgjer kven som er autoritativ og deaktiver den andre, fordi to handsamarar som skriv om ruter på eitt grensesnitt lagar feil ingen kan gjenskape. Ei manglande oppføring er informasjon om handsamaren, ikkje om tunnelen.

Gjer neste steg avhengig av kontrollen det treng

Å polle ein UDP-port provar ingenting om beredskap, fordi UDP ikkje har noko handtrykk, og nc -u lukkast så snart pakken forlèt maskinen. Undersøk kva neste steg faktisk brukar: ei TCP-tilkopling til den videresende porten, ein førespurnad til ein vert inne i tunnelen, eit namn som berre blir løyst der. Avgrens ventinga med ein timeout og eit tal forsøk, og feil høgt når det går ut.

Hooks slår polling når klienten tilbyr dei. Skripta til OpenVPN --up og --down køyrer etter at grensesnittet endrar tilstand, noko som fjernar kappløpet heilt, men dei køyrer med privilegia daemonen har behalde. Viss OpenVPN har falle til ein uprivilegert konto gjennom user og group, køyrer hooken som den kontoen. Å starte ein systemteneste på nytt krev då sudo for å tillate nøyaktig den kommandoen. Gi nytt forsøk til tenestebehandsamaren i staden for ei cron-løkke: ein avgrensa omstartspolicy med startgrense avdekkjer ein øydelagd tunnel, medan ei uavgrensa løkke skjuler han på ubestemt tid.