Pi som VPN-klient: én behandler eller et eget skript?

En Raspberry Pi som bare skal beskytte sin egen utgående trafikk, har to realistiske design: la nettverksbehandleren eie tunnelen, eller behold et skript som eier den. Begge kan bære trafikk. De svikter på forskjellige steder, og svikten du kan diagnostisere eksternt klokken to om natten, er den som er verdt å velge. Sammenlign dem på eierskap, på hva full tunnel betyr når IPv6 og DNS er involvert, og på hva som skjer i det øyeblikket tunnelen faller.

To eiere for én tunnel

Design A er en profil inne i systemets nettverksbehandler: en importert OpenVPN-profil eller en innebygd WireGuard-tilkobling, aktivert ved oppstart av den samme tjenesten som reiser Ethernet og Wi-Fi. Design B er en egen enhet som kjører klienten direkte, redigerer resolver-konfigurasjonen og installerer sine egne ruter og brannmurregler. Begge er legitime design; de skiller seg i hvem som har lov til å endre rutetabellen.

Feilene er forskjellige fordi eierne er forskjellige. Med A etterlater en profil som ikke aktiveres, grensesnittet oppe og tunnelen nede, og behandlerens logger sier hvorfor. Med B etterlater et skript som bare delvis lykkes, ruter som overlever prosessen som laget dem. Å kjøre begge er det verste utfallet: to prosesser skriver standardruten, to resolver-endringer konkurrerer ved oppstart, og to sett hemmeligheter må roteres.

Velg én eier per tunnel og deaktiver den andre før du tester noe. To eiere betyr også to steder å se når tunnelen er oppe og ingenting løses. Den ene regelen hindrer de fleste av de forvirrende tilstandene som beskrives i Pi VPN-tråder.

Hva en import skaper, og hva den ikke skaper

På Raspberry Pi OS Bookworm og nyere er standardverktøyet for nettverkskonfigurasjon NetworkManager, så en profil er det naturlige hjemmet for en klienttunnel. Importen krever den riktige utvidelsen installert; uten den mislykkes importen med en melding om en tilkoblingstype som ikke støttes, noe som er det ærlige signalet om å stoppe og installere utvidelsen.

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

Import lagrer en profil. Det beviser ikke at den andre siden er tilgjengelig, og det garanterer ikke at hver direktiv i filen overlevde konverteringen. Les den resulterende tilkoblingen tilbake og kontroller delene som bærer identitet og tillit: sertifikatet, den eksterne verten og porten, og om det spørres etter et passord eller om det lagres.

Aktivering med --ask holder en passfrase ute av skallhistorikken på en delt maskin. For en Pi uten tilsyn vil du etter hvert at profilen skal komme opp ved oppstart, noe som er en egen beslutning fra å reise den én gang manuelt.

Full tunnel, sammenlignet på tvers av begge design

En full tunnel er en påstand om ruter, ikke om hensikt, og de to designene uttrykker det ulikt. Profiltilnærmingen ber behandleren installere en standardrute og resolver-innstillingene sine; skripttilnærmingen gjør det skriptet sier, inkludert ingenting. Ingen av designene dekker IPv6 med mindre de får beskjed, og en urørt IPv6-standardrute vil gjerne bære trafikk utenfor tunnelen mens IPv4 ser perfekt ut.

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

Bruk en dokumentasjonsadresse for ruteoppslaget og bytt den ut med en vert du har lov til å undersøke. Den første kommandoen viser hvilket grensesnitt Pi ville brukt for en vanlig destinasjon; den andre viser om en IPv6-standardrute fortsatt finnes; den tredje beviser hvilken resolver som svarte. Les alle tre før du tror på noen påstand om en full tunnel.

Hvis leverandørens instruksjoner lover en full tunnel, men IPv6-standardruten overlever, lekker Pi-en. Deaktiver IPv6 på oppstrømslenken eller be profilen om å kreve det, og bestem bevisst i stedet for å oppdage det senere.

Fail-open mot fail-closed

Når tunnelen faller, faller en rutetabell som mister standardruten, rett og slett tilbake til den fysiske oppstrømslenken, og trafikken fortsetter åpent. Det er fail-open, og det er standardoppførselen til begge designene med mindre noe hindrer det. De fleste oppdager det uker senere ved å lese en brannmurlogg.

Fail-closed koster deg fjernadgang når tunnelen er nede, så det trenger et bevisst unntak for administrasjonsveien. En måte er en regel som bare tillater VPN-partnerens adresse utenfor 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

Sammenlign driftskostnaden ærlig. En profil kan vanligvis ikke uttrykke denne regelen, så fail-closed skyver deg mot skriptdesignet eller mot en liten enhet som installerer regelen uavhengig av tunnelen. Uansett bør du logge avvisningene i en uke: en stille avvisning ser identisk ut med en ødelagt tjeneste, og du vil trenge telleren når en bruker rapporterer at ett nettsted sluttet å laste.

Å velge for en Pi uten skjerm

Hvis bildet allerede kjører NetworkManager, tunnelen ikke trenger noe eksotisk, og du vil at den skal følge oppstrømslenken automatisk, ta profilen. Hvis du trenger policy-ruting, flere tunneler valgt per destinasjon, eller en fail-closed-regel som må finnes før tunnelen kommer opp, ta skriptet og eie hver del av det, inkludert oppstartsrekkefølge og opprydding. Å blande de to designene koster mer enn hvert av dem alene.

Migrering mellom dem er mest et spørsmål om rekkefølge: deaktiver den gamle eieren, bekreft at ingen foreldet rute eller resolver-oppføring overlever, aktiver deretter den nye og start på nytt to ganger. En enkelt omstart kan skjule et kappløp som en andre avdekker. Avslutt med å teste Pi-en i stedet for tunnelen: løs opp et navn, hent noe over IPv4, hent over IPv6 hvis du beholdt det, slipp deretter tunnelen og bekreft at oppførselen du valgte faktisk skjer. Et grensesnitt i ip link er starten på testen, ikke slutten.