Pi as VPN-kliënt: een bestuurder of 'n eie skrip?

’n Raspberry Pi wat net sy eie uitgaande verkeer moet beskerm, het twee realistiese ontwerpe: laat die netwerkbestuurder die tonnel besit, of hou ’n skrip wat dit besit. Albei kan verkeer dra. Hulle faal op verskillende plekke, en die fout wat jy om twee in die oggend op afstand kan diagnoseer, is die een werd om te kies. Vergelyk hulle op eienaarskap, op wat volle tonnel beteken sodra IPv6 en DNS betrokke is, en op wat gebeur die oomblik wanneer die tonnel val.

Twee eienaars vir een tonnel

Ontwerp A is ’n profiel binne die stelsel se netwerkbestuurder: ’n ingevoerde OpenVPN-profiel of ’n native WireGuard-verbinding, by die boot geaktiveer deur dieselfde diens wat Ethernet en Wi-Fi opbring. Ontwerp B is ’n eenheid van jou eie wat die kliënt direk bestuur, die resolver-konfigurasie wysig en sy eie roetes en vuurmuurreëls installeer. Albei is geldige ontwerpe; hulle verskil in wie toegelaat word om die roetekaart te verander.

Die foute verskil omdat die eienaars verskil. By A laat ’n profiel wat nie aktiveer nie die koppelvlak op en die tonnel af, en die bestuurder se logs sê waarom. By B laat ’n skrip wat half slaag roetes agter wat die proses wat hulle geskep het, oorleef. Om albei te laat loop is die slegste uitkoms: twee prosesse wat die verstekroete skryf, twee resolver-wysigings wat by die boot jaag, en twee stelle geheime om te roteer.

Kies een eienaar per tonnel en skakel die ander een af voordat jy enigiets toets. Twee eienaars beteken ook twee plekke om te kyk wanneer die tonnel op is en niks resolveer nie. Daardie enkele reël verhoed die meeste van die verwarrende toestande wat in Pi VPN-drade beskryf word.

Wat ’n invoer skep, en wat dit nie doen nie

Op Raspberry Pi OS Bookworm en later is die verstek netwerkkonfigurasienutsgoed NetworkManager, so ’n profiel is die natuurlike tuiste vir ’n kliënttonnel. Invoer vereis dat die gepaste inprop geïnstalleer is; sonder dit misluk die invoer met ’n boodskap oor ’n onondersteunde verbindingstipe, wat die eerlike teken is om te stop en die inprop te installeer.

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

Invoer stoor ’n profiel. Dit bewys nie dat die ander kant bereikbaar is nie, en dit waarborg nie dat elke richtlijn in die lêer die omskakeling oorleef het nie. Lees die resulterende verbinding terug en kontroleer die dele wat identiteit en vertroue dra: die sertifikaat, die afgeleë gasheer en poort, en of ’n wagwoord gevra of gestoor word.

Aktivering met --ask hou ’n wagfrase uit die dopgeskiedenis op ’n gedeelde masjien. Vir ’n onbewaakte Pi wil jy uiteindelik hê die profiel moet by die boot opkom, wat ’n aparte besluit is van om dit een keer met die hand op te kry.

Volle tonnel, vergelyk oor albei ontwerpe

’n Volle tonnel is ’n bewering oor roetes, nie oor bedoeling nie, en die twee ontwerpe druk dit anders uit. Die profielbenadering vra die bestuurder om ’n verstekroete en sy resolver-instellings te installeer; die skripbenadering doen wat die skrip sê, insluitend niks. Nie een van die ontwerpe dek IPv6 tensy dit opdrag kry nie, en ’n onaangeraakte IPv6-verstekroete sal vrolik verkeer buite die tonnel dra terwyl IPv4 volmaak lyk.

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

Gebruik ’n dokumentasie-adres vir die roete-opsoek en vervang ’n gasheer wat jy mag ondersoek. Die eerste opdrag wys watter koppelvlak die Pi vir ’n gewone bestemming sou gebruik; die tweede wys of ’n IPv6-verstek nog bestaan; die derde bewys watter resolver geantwoord het. Lees al drie voordat jy enige bewering oor ’n volle tonnel glo.

As die verskaffer se instruksies ’n volle tonnel belowe maar die IPv6-verstek oorleef, lek die Pi. Skakel IPv6 op die opdraad af of vra die profiel om dit te eis, en besluit doelbewus eerder as om dit later te ontdek.

Faal-oop teenoor faal-toe

Wanneer die tonnel val, val ’n roetekaart wat sy verstekroete verloor eenvoudig terug na die fisiese opdraad, en verkeer gaan in die ope verder. Dit is faal-oop, en dit is die verstekgedrag van albei ontwerpe tensy iets dit verhoed. Die meeste mense ontdek dit weke later deur ’n vuurmuurlog te lees.

Faal-toe kos jou afstandtoegang wanneer die tonnel af is, so dit benodig ’n doelbewuste uitsondering vir die bestuurspad. Een manier is ’n reël wat net die VPN-portuur se adres buite die tonnel toelaat:

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

Vergelyk die operasionele koste eerlik. ’n Profiel kan gewoonlik nie hierdie reël uitdruk nie, so faal-toe stoot jou na die skripontwerp of na ’n klein eenheid wat die reël onafhanklik van die tonnel installeer. In elk geval, teken die verwerpe vir ’n week aan: ’n stille verwerping lyk identies aan ’n stukkende diens, en jy sal die teller wil hê wanneer ’n gebruiker rapporteer dat een webwerf opgehou laai het.

Kies vir ’n Pi sonder skerm

As die beeld reeds NetworkManager loop, die tonnel niks eksoties nodig het nie, en jy wil hê dit moet die opdraad outomaties volg, neem die profiel. As jy beleidsroetering nodig het, verskeie tonnele per bestemming gekies, of ’n faal-toe-reël wat moet bestaan voordat die tonnel opkom, neem die skrip en besit elke deel daarvan, insluitend bootorde en opruiming. Om die twee ontwerpe te meng kos meer as enigeen alleen.

Migreer tussen hulle is meestal ’n kwessie van orde: skakel die ou eienaar af, bevestig dat geen verouderde roete of resolver-inskrywing oorleef nie, aktiveer dan die nuwe een en herbegin twee keer. ’n Enkele herbegin kan ’n resies verberg wat ’n tweede een blootlê. Eindig deur die Pi te toets eerder as die tonnel: resolveer ’n naam, haal iets oor IPv4, haal oor IPv6 as jy dit gehou het, laat val dan die tonnel en bevestig dat die gedrag wat jy gekies het werklik gebeur. ’n Koppelvlak in ip link is die begin van die toets, nie die einde nie.