Pi som VPN-klient: éin behandlar eller eit eige skript?

Ein Raspberry Pi som berre skal verne sin eigen utgåande trafikk, har to realistiske design: la nettverksbehandlaren eige tunnelen, eller hald eit skript som eig han. Begge kan bere trafikk. Dei sviktar på ulike stader, og svikten du kan diagnostisere eksternt klokka to om natta, er den som er verdt å velje. Samanlikn dei på eigarskap, på kva full tunnel tyder når IPv6 og DNS er involverte, og på kva som skjer i det augneblinken tunnelen fell.

To eigarar for éin tunnel

Design A er ein profil inne i nettverksbehandlaren til systemet: ein importert OpenVPN-profil eller ei innebygd WireGuard-tilkopling, aktivert ved oppstart av den same tenesta som reiser Ethernet og Wi-Fi. Design B er eining di eiga som køyrer klienten direkte, redigerer resolver-konfigurasjonen og installerer sine eigne ruter og brannmurreglar. Begge er legitime design; dei skil seg i kven som har lov til å endre rutetabellen.

Feila er ulike fordi eigarane er ulike. Med A lèt ein profil som ikkje aktiverer grensesnittet oppe og tunnelen nede, og loggane til behandlaren seier kvifor. Med B lèt eit skript som berre delvis lukkast ruter attende som overlever prosessen som laga dei. Å køyre begge er det verste utfallet: to prosessar skriv standardruta, to resolver-endringar kappast ved oppstart, og to sett hemmelegheiter må roterast.

Vel éin eigar per tunnel og deaktiver den andre før du testar noko. To eigarar tyder òg to stader å sjå når tunnelen er oppe og ingenting vert løyst. Den eine regelen hindrar dei fleste av dei forvirrande tilstandane som er skildra i Pi VPN-trådar.

Kva ein import skaper, og kva han ikkje skaper

På Raspberry Pi OS Bookworm og nyare er standardverktøyet for nettverkskonfigurasjon NetworkManager, så ein profil er det naturlege heimen for ein klienttunnel. Importen krev den rette utvidinga installert; utan ho mislukkast importen med ei melding om ein tilkoplingstype som ikkje er støtta, noko som er det ærlege signalet om å stoppe og installere utvidinga.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

Import lagrar ein profil. Det beviser ikkje at den andre sida er tilgjengeleg, og det garanterer ikkje at kvar direktiv i fila overlevde konverteringa. Les den resulterande tilkoplinga tilbake og kontroller delane som ber identitet og tillit: sertifikatet, den eksterne verten og porten, og om det vert spurt etter eit passord eller om det vert lagra.

Aktivering med --ask held ein passfrase ute av skallhistoria på ein delt maskin. For ein Pi utan tilsyn vil du etter kvart at profilen skal kome opp ved oppstart, noko som er ei eiga avgjerd frå å reise han éin gong manuelt.

Full tunnel, samanlikna på tvers av begge design

Ein full tunnel er ein påstand om ruter, ikkje om hensikt, og dei to designa uttrykkjer det ulikt. Profiltilnærminga ber behandlaren installere ei standardrute og resolver-innstillingane sine; skripttilnærminga gjer det skriptet seier, inkludert ingenting. Ingen av designa dekkjer IPv6 med mindre dei får beskjed, og ei urørt IPv6-standardrute vil gjerne bere trafikk utanfor tunnelen medan IPv4 ser perfekt ut.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

Bruk ein dokumentasjonsadresse for ruteoppslaget og byt henne ut med ein vert du har lov til å undersøkje. Den første kommandoen viser kva grensesnitt Pi ville brukt for ein vanleg destinasjon; den andre viser om ei IPv6-standardrute framleis finst; den tredje beviser kva resolver som svara. Les alle tre før du trur på nokon påstand om ein full tunnel.

Viss instruksjonane til leverandøren lovar ein full tunnel, men IPv6-standardruta overlever, lekk Pi-en. Deaktiver IPv6 på oppstraumslenkja eller be profilen om å krevje det, og avgjer medvite i staden for å oppdage det seinare.

Fail-open mot fail-closed

Når tunnelen fell, fell ei rutetabell som mistar standardruta, rett og slett tilbake til den fysiske oppstraumslenkja, og trafikken held fram ope. Det er fail-open, og det er standardåtferda til begge designa med mindre noko hindrar det. Dei fleste oppdagar det veker seinare ved å lese ein brannmurlogg.

Fail-closed kostar deg fjernåtgang når tunnelen er nede, så det treng eit medvite unntak for administrasjonsvegen. Ein måte er ein regel som berre tillèt adressa til VPN-partnaren utanfor tunnelen:

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

Samanlikn driftskostnaden ærleg. Ein profil kan vanlegvis ikkje uttrykkje denne regelen, så fail-closed skyv deg mot skriptdesignet eller mot ei lita eining som installerer regelen uavhengig av tunnelen. Uansett bør du logge avvisingane i ei veke: ei stille avvising ser identisk ut med ei øydelagd teneste, og du vil trenge teljaren når ein brukar rapporterer at eitt nettstad slutta å laste.

Å velje for ein Pi utan skjerm

Viss biletet allereie køyrer NetworkManager, tunnelen ikkje treng noko eksotisk, og du vil at han skal følgje oppstraumslenkja automatisk, ta profilen. Viss du treng policy-ruting, fleire tunnelar valde per destinasjon, eller ein fail-closed-regel som må finnast før tunnelen kjem opp, ta skriptet og eig kvar del av det, inkludert oppstartsrekkjefølgje og opprydding. Å blande dei to designa kostar meir enn kvar av dei åleine.

Migrering mellom dei er mest eit spørsmål om rekkjefølgje: deaktiver den gamle eigaren, stadfest at ingen forelda rute eller resolver-oppføring overlever, aktiver deretter den nye og start på nytt to gonger. Ein einaste omstart kan gøyme eit kapplaup som ein andre avdekkjer. Avslutt med å teste Pi-en i staden for tunnelen: løys opp eit namn, hent noko over IPv4, hent over IPv6 viss du heldt på det, slepp deretter tunnelen og stadfest at åtferda du valde faktisk skjer. Eit grensesnitt i ip link er byrjinga på testen, ikkje slutten.