Pi som VPN-klient: én administrator eller et eget script?

En Raspberry Pi, der kun skal beskytte sin egen udgående trafik, har to realistiske design: lad netværksadministratoren eje tunnelen, eller behold et script, der ejer den. Begge kan bære trafik. De fejler forskellige steder, og den fejl, du kan diagnosticere eksternt klokken to om natten, er den, der er værd at vælge. Sammenlign dem på ejerskab, på hvad fuld tunnel betyder, når IPv6 og DNS er involveret, og på hvad der sker i det øjeblik, tunnelen falder.

To ejere til én tunnel

Design A er en profil inde i systemets netværksadministrator: en importeret OpenVPN-profil eller en indbygget WireGuard-forbindelse, aktiveret ved opstart af den samme tjeneste, der rejser Ethernet og Wi-Fi. Design B er en enhed af din egen, der kører klienten direkte, redigerer resolver-konfigurationen og installerer sine egne ruter og firewallregler. Begge er legitime design; de adskiller sig i, hvem der må ændre rutetabellen.

Fejlene er forskellige, fordi ejerne er forskellige. Med A efterlader en profil, der ikke aktiveres, grænsefladen oppe og tunnelen nede, og administratorens logfiler siger hvorfor. Med B efterlader et script, der kun delvist lykkes, ruter tilbage, som overlever den proces, der skabte dem. At køre begge er det værste udfald: to processer skriver standardruten, to resolver-redigeringer kappes ved opstart, og to sæt hemmeligheder skal roteres.

Vælg én ejer pr. tunnel, og deaktiver den anden, før du tester noget. To ejere betyder også to steder at kigge, når tunnelen er oppe, og intet opløses. Den ene regel forhindrer de fleste af de forvirrende tilstande, der beskrives i Pi VPN-tråde.

Hvad en import skaber, og hvad den ikke skaber

På Raspberry Pi OS Bookworm og senere er standardværktøjet til netværkskonfiguration NetworkManager, så en profil er det naturlige hjem for en klienttunnel. Import kræver det matchende plugin installeret; uden det fejler importen med en besked om en ikke-understøttet forbindelsestype, hvilket er det ærlige signal om at stoppe og installere pluginet.

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

Import gemmer en profil. Det beviser ikke, at den anden side kan nås, og det garanterer ikke, at hver direktiv i filen overlevede konverteringen. Læs den resulterende forbindelse tilbage, og kontroller de dele, der bærer identitet og tillid: certifikatet, den eksterne vært og port, og om der spørges efter en adgangskode, eller om den gemmes.

Aktivering med --ask holder en adgangsfrase ude af shell-historikken på en delt maskine. Til en Pi uden opsyn vil du på et tidspunkt have profilen til at rejse sig ved opstart, hvilket er en beslutning for sig fra at rejse den én gang manuelt.

Fuld tunnel sammenlignet på tværs af begge design

En fuld tunnel er en påstand om ruter, ikke om hensigt, og de to design udtrykker det forskelligt. Profiltilgangen beder administratoren installere en standardrute og dens resolver-indstillinger; scripttilgangen gør, hvad scriptet siger, inklusive ingenting. Ingen af designene dækker IPv6, medmindre de får besked på det, og en urørt IPv6-standardrute vil gladeligt bære trafik uden for tunnelen, mens IPv4 ser perfekt ud.

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

Brug en dokumentationsadresse til ruteopslaget, og indsæt en vært, du har lov til at undersøge. Den første kommando viser, hvilken grænseflade Pi'en ville bruge til en almindelig destination; den anden viser, om en IPv6-standardrute stadig findes; den tredje beviser, hvilken resolver der svarede. Læs alle tre, før du tror på nogen påstand om en fuld tunnel.

Hvis udbyderens instruktioner lover en fuld tunnel, men IPv6-standardruten overlever, lækker Pi'en. Deaktiver IPv6 på uplink, eller bed profilen om at kræve det, og beslut det bevidst i stedet for at opdage det senere.

Fail-open mod fail-closed

Når tunnelen falder, falder en rutetabel, der mister sin standardrute, simpelthen tilbage til det fysiske uplink, og trafikken fortsætter i det åbne. Det er fail-open, og det er standardadfærden for begge design, medmindre noget forhindrer det. De fleste opdager det uger senere ved at læse en firewalllog.

Fail-closed koster dig fjernadgang, når tunnelen er nede, så det kræver en bevidst undtagelse for administrationsvejen. En måde er en regel, der kun tillader VPN-peerens adresse uden for 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 den operationelle pris ærligt. En profil kan normalt ikke udtrykke denne regel, så fail-closed skubber dig mod scriptdesignet eller mod en lille enhed, der installerer reglen uafhængigt af tunnelen. Under alle omstændigheder bør du logge afvisningerne i en uge: en tavs afvisning ligner en brudt tjeneste, og du vil have tælleren, når en bruger rapporterer, at et websted holdt op med at indlæse.

At vælge til en Pi uden skærm

Hvis imaget allerede kører NetworkManager, tunnelen ikke kræver noget eksotisk, og du vil have den til at følge uplink automatisk, tag profilen. Hvis du har brug for policy routing, flere tunneler valgt pr. destination eller en fail-closed-regel, der skal findes, før tunnelen rejser sig, tag scriptet og ej hver del af det, inklusive opstartsrækkefølge og oprydning. At blande de to design koster mere end hvert af dem alene.

At migrere mellem dem er mest et spørgsmål om rækkefølge: deaktiver den gamle ejer, bekræft, at ingen forældet rute eller resolver-post overlever, aktivér derefter den nye og genstart to gange. En enkelt genstart kan skjule et kapløb, som en anden afslører. Slut af med at teste Pi'en i stedet for tunnelen: opløs et navn, hent noget over IPv4, hent over IPv6, hvis du beholdt det, slip derefter tunnelen og bekræft, at den adfærd, du valgte, faktisk sker. En grænseflade i ip link er starten på testen, ikke slutningen.