Pi ca client VPN: un singur manager sau un script propriu?

Un Raspberry Pi care trebuie să-și protejeze doar propriul trafic de ieșire are două proiecte realiste: lăsați managerul de rețea să dețină tunelul sau păstrați un script care îl deține. Ambele pot transporta trafic. Ele eșuează în locuri diferite, iar defecțiunea pe care o puteți diagnostica de la distanță la ora două dimineața este cea care merită aleasă. Comparați-le după proprietate, după ce înseamnă tunel complet când intră în joc IPv6 și DNS, și după ce se întâmplă în momentul în care tunelul cade.

Doi proprietari pentru un tunel

Proiectul A este un profil în interiorul managerului de rețea al sistemului: un profil OpenVPN importat sau o conexiune WireGuard nativă, activată la pornire de același serviciu care ridică Ethernet și Wi-Fi. Proiectul B este o unitate proprie care rulează clientul direct, editează configurația resolverului și instalează propriile rute și reguli de firewall. Ambele sunt proiecte legitime; diferă prin cine are voie să modifice tabela de rutare.

Defecțiunile diferă pentru că proprietarii diferă. La A, un profil care nu se activează lasă interfața sus și tunelul jos, iar jurnalele managerului spun de ce. La B, un script care reușește pe jumătate lasă rute care supraviețuiesc procesului care le-a creat. A rula ambele este cel mai rău rezultat: două procese scriu ruta implicită, două editări ale resolverului concurează la pornire și două seturi de secrete trebuie rotite.

Alegeți un singur proprietar pe tunel și dezactivați-l pe celălalt înainte de a testa ceva. Doi proprietari înseamnă și două locuri de verificat când tunelul este sus și nimic nu se rezolvă. Acea singură regulă previne majoritatea stărilor confuze descrise în firele despre Pi VPN.

Ce creează un import și ce nu

Pe Raspberry Pi OS Bookworm și versiunile ulterioare, instrumentul implicit de configurare a rețelei este NetworkManager, așa că un profil este casa naturală pentru un tunel de client. Importul necesită pluginul corespunzător instalat; fără el, importul eșuează cu un mesaj despre un tip de conexiune neacceptat, care este semnalul onest de a vă opri și a instala pluginul.

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

Importul salvează un profil. Nu dovedește că cealaltă parte este accesibilă și nu garantează că fiecare directivă din fișier a supraviețuit conversiei. Recitiți conexiunea rezultată și verificați părțile care poartă identitate și încredere: certificatul, gazda și portul la distanță și dacă parola este cerută sau stocată.

Activarea cu --ask ține fraza de acces în afara istoricului shell-ului pe o mașină partajată. Pentru un Pi nesupravegheat, în cele din urmă veți dori ca profilul să urce la pornire, ceea ce este o decizie separată de a-l ridica o dată manual.

Tunel complet, comparat în ambele proiecte

Un tunel complet este o afirmație despre rute, nu despre intenție, iar cele două proiecte o exprimă diferit. Abordarea cu profil cere managerului să instaleze o rută implicită și setările sale de resolver; abordarea cu script face ce spune scriptul, inclusiv nimic. Niciun proiect nu acoperă IPv6 dacă nu i se spune, iar o rută implicită IPv6 neatinsă va duce bucuros trafic în afara tunelului în timp ce IPv4 pare perfect.

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

Folosiți o adresă de documentație pentru căutarea rutei și înlocuiți-o cu o gazdă pe care aveți voie să o sondați. Prima comandă arată ce interfață ar folosi Pi pentru o destinație obișnuită; a doua arată dacă mai există o rută implicită IPv6; a treia dovedește ce resolver a răspuns. Citiți toate trei înainte de a crede vreo afirmație despre un tunel complet.

Dacă instrucțiunile furnizorului promit un tunel complet dar ruta implicită IPv6 supraviețuiește, Pi curge. Dezactivați IPv6 pe legătura de ieșire sau cereți profilului să o revendice și decideți deliberat în loc să descoperiți asta mai târziu.

Eșec deschis contra eșec închis

Când tunelul cade, o tabelă de rutare care își pierde ruta implicită revine pur și simplu la legătura fizică de ieșire, iar traficul continuă în clar. Acesta este eșecul deschis și este comportamentul implicit al ambelor proiecte dacă nimic nu îl împiedică. Majoritatea oamenilor îl descoperă săptămâni mai târziu citind un jurnal de firewall.

Eșecul închis vă costă accesul la distanță când tunelul este jos, așa că are nevoie de o excepție deliberată pentru calea de administrare. O modalitate este o regulă care permite doar adresa partenerului VPN în afara tunelului:

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

Comparați costul operațional cu onestitate. Un profil nu poate de obicei să exprime această regulă, așa că eșecul închis vă împinge spre proiectul cu script sau spre o unitate mică ce instalează regula independent de tunel. În orice caz, înregistrați respingerile o săptămână: o respingere silențioasă arată identic cu un serviciu stricat, iar contorul vă va trebui când un utilizator raportează că un site a încetat să se încarce.

Alegerea pentru un Pi fără ecran

Dacă imaginea rulează deja NetworkManager, tunelul nu are nevoie de nimic exotic și vreți ca el să urmeze automat legătura de ieșire, luați profilul. Dacă aveți nevoie de rutare pe politici, de mai multe tuneluri alese pe destinație sau de o regulă de eșec închis care trebuie să existe înainte ca tunelul să urce, luați scriptul și stăpâniți fiecare parte a lui, inclusiv ordinea de pornire și curățarea. Amestecarea celor două proiecte costă mai mult decât fiecare în parte.

Migrarea între ele este în principal o chestiune de ordine: dezactivați proprietarul vechi, confirmați că nu supraviețuiește nicio rută sau intrare de resolver învechită, apoi activați-l pe cel nou și reporniți de două ori. O singură repornire poate ascunde o cursă pe care a doua o dezvăluie. Terminați testând Pi-ul, nu tunelul: rezolvați un nume, aduceți ceva prin IPv4, aduceți prin IPv6 dacă l-ați păstrat, apoi coborâți tunelul și confirmați că comportamentul ales chiar se întâmplă. O interfață în ip link este începutul testului, nu sfârșitul.