Slik sjekker du om en Linux VPN-tunnel virkelig er oppe

Cron starter en helt frisk VPN på nytt hvert tiende minutt, og samme jobb lar en død kjøre i en uke. Begge feilene kommer av å behandle «oppe» som ett faktum når det er minst fire. En enhet kan være administrativt aktivert, riktig rutet, fullt kryptert og likevel ikke frakte noe nyttig. Skill observasjonene først, og kontrollen skriver seg nesten selv.

Koblingsflagg beskriver enheten, ikke veien

Kontrollen alle kopierer, leter etter en maskinvareadresse av bare nuller. Det trikset skiller et ekte grensesnitt fra en plassholder i noen drivere og beviser ingenting i resten, fordi en tun-enhet ikke har noen MAC å rapportere i det hele tatt. ip -brief link show tun0 gir i stedet flagg: UP betyr at en administrator aktiverte enheten, og LOWER_UP betyr at driveren anser koblingen som brukbar. Lest sammen sier de at enheten finnes og ikke er administrativt nede. Ingen av dem sier at en pakke har noe sted å gå.

OpenVPN lager tun-enheten sin før ruter installeres, så flaggene kan se perfekte ut mens ingenting er rutet. Behandle dem som en forutsetning, aldri som svaret.

Spør hvor en pakke ville gå

Ruteoppslaget svarer på spørsmålet flaggene ikke kan. ip route get 10.8.0.1 from 10.8.0.2 navngir grensesnittet, kildeadressen og tabellen kjernen ville brukt, og det er nøyaktig det en splittet tunnel må kontrolleres mot. Uten kildeadressen spør du om noe annet, og med policy-routing kan svaret variere per kilde. Dette er den billigste ærlige testen, fordi den konsulterer de samme reglene som trafikken din vil bruke.

For WireGuard, legg til håndtrykket. wg show skriver ut et tidsstempel for siste håndtrykk per peer, og et tidsstempel som har sluttet å bevege seg fremover betyr at peeren er borte, uansett hva grensesnittflaggene sier. Et konfigurert grensesnitt uten nylig håndtrykk er en av de vanligste falske positivene i hjemmelaget overvåking.

Tabell 220 forteller IPsecs historie

strongSwan installerer ruter for forhandlede selektorer i tabell 220 når ruteinstallasjon er aktivert. ip route list table 220 skiller derfor forhandlet fra rutet: en tom tabell ved siden av en lastet tilkobling betyr at IKE- og CHILD-SA-ene kom opp mens ingen trafikk ledes inn i dem. Sjekk ip xfrm state ved siden av, siden den lister de installerte sikkerhetsassosiasjonene og endepunktene deres.

En fellepolitikk er tilfellet man bør være oppmerksom på. Den venter på interessant trafikk i stedet for å rute den, så tabellen forblir tom til noe utløser tunnelen.

Behandlertilstand og daemontilstand er forskjellige lister

NetworkManager lister bare tilkoblingene den eier. nmcli -t -f NAME,TYPE connection show --active returnerer ingenting for en tunnel startet direkte av wg-quick eller av en OpenVPN-daemon.

Den forskjellen betyr noe når et skript må avgjøre hvilken av to behandlere det skal spørre. Velg den som faktisk eier tunnelen på denne verten, og ignorer stillheten til den andre. Hvis begge finnes, avgjør hvilken som er autoritativ og deaktiver den andre, fordi to behandlere som skriver om ruter på ett grensesnitt produserer feil ingen kan gjenskape. En manglende oppføring er informasjon om behandleren, ikke om tunnelen.

Gjør neste steg avhengig av kontrollen det trenger

Å polle en UDP-port beviser ingenting om beredskap, fordi UDP ikke har noe håndtrykk, og nc -u lykkes så snart pakken forlater maskinen. Undersøk hva neste steg faktisk forbruker: en TCP-tilkobling til den videresendte porten, en forespørsel til en vert inne i tunnelen, et navn som bare løses der. Begrens ventingen med en timeout og et antall forsøk, og feil høylytt når den går ut.

Hooks slår polling når klienten tilbyr dem. OpenVPNs --up og --down skript kjøres etter at grensesnittet endrer tilstand, noe som fjerner kappløpet helt, men de kjører med privilegiene daemonen har beholdt. Hvis OpenVPN har falt til en uprivilegert konto gjennom user og group, kjører hooken som den kontoen. Å starte en systemtjeneste på nytt krever da sudo for å tillate nøyaktig den kommandoen. Gi nytt forsøk til tjenestebehandleren i stedet for en cron-løkke: en begrenset omstartspolicy med startgrense avdekker en ødelagt tunnel, mens en ubegrenset løkke skjuler den på ubestemt tid.