Proton VPN ne ekrano Pi: programėlė ar WireGuard failas?
Pi be ekrano paverčia Linux programėlės klausimą pasirinkimu: palaikoma programėlė ar rankinis WireGuard profilis. Pirmiausia suderinkite architektūrą, tada funkcijas.
Linux programėlės diegimas skamba kaip viena instrukcija Pi be ekrano, tačiau slepia pasirinkimą tarp dviejų diegimo kelių su skirtingomis palaikymo ribomis. Vienas yra oficiali teikėjo programėlė, turinti savo platinimo ir architektūros reikalavimus. Kitas yra rankiniu būdu sukurtas konfigūracijos failas, kurį naudoja standartinis klientas, jau supakuotas operacinės sistemos. Abu pasiekia tą pačią paslaugą, ir priežiūros požiūriu jie nėra keičiami.
Architektūros klausimas kyla pirmas, nes 64 bitų plokštė gali vykdyti 32 bitų vartotojo erdvę, o programėlė tiekiama tik su viena iš jų.
Dvi palaikymo ribos, o ne du diegėjai
Perskaitykite dabartinį teikėjo diegimo puslapį programėlei, kurią ketinate naudoti, ir palyginkite jį su plokšte: platinimo leidimas, paketo architektūra ir bet kokie darbalaukio ar sesijos reikalavimai. Tai, kad Pi palaiko 64 bitų veikimą, nepasako, kuri vartotojo erdvė dabar įdiegta, ir būtent tą reikšmę tikrina paketų tvarkyklė. dpkg --print-architecture ir uname -m atsako į tai po vieną eilutę. Jei leidimas ar architektūra yra už dokumentuoto rinkinio ribų, programėlė ten nepalaikoma, net jei įdiegiama.
Palaikymas taip pat priklauso nuo pakavimo būdo. Vienam paketo formatui dokumentuotas apribojimas automatiškai netaikomas saugyklos rinkiniui, o iš Debian kilęs platinimas nėra automatiškai palaikoma aplinka. Bendruomenės paketai ir seni diegimo receptai atsineša savo priežiūros modelį, kurį galite sąmoningai priimti, bet neturėtumėte perimti atsitiktinai.
Ką duoda programėlė, o profilis ne
Oficiali programėlė yra daugiau nei ryšys: ji paprastai turi teikėjo avarinį jungiklį, DNS tvarkymą ir funkcijų jungiklius, o teikėjas šiuos elgesius palaiko kaip visumą. Standartiniam klientui perduotas rankinis profilis nieko iš to nepaveldi. Rankinis klientas valdo ryšio gyvavimo ciklą ir vietinę gedimų politiką, kas gerai, kai juos konfigūruojate patys, ir netikėta, kai manote, kad jie atėjo kartu. Abi parinktys pasiekia tuos pačius serverius; tik viena apima aplinkinę logiką.
Jei kuri nors funkcija svarbi, pavyzdžiui, srauto už tunelio blokavimas, ji turi būti jūsų konfigūracijoje, o ne teikėjo programėlėje.
WireGuard rankiniu būdu: svarbūs žingsniai
Teikėjas dokumentuoja WireGuard konfigūracijos kūrimą standartą atitinkančiam klientui ir rekomenduoja šį kelią rankiniam diegimui, palikdamas OpenVPN senesniems įrenginiams. Sukurkite profilį paskyros skydelyje, atneškite jį į Pi ir padėkite ten, kur tik savininkas gali jį perskaityti. Niekada neįklijuokite failo į palaikymo temą, nes draugiškas failo pavadinimas nepadaro įterpto privataus rakto skelbiamu. Tada išbandykite tunelį viena užklausa prieš prijungdami ką nors kita.
Serverių išėmimas iš naudojimo yra operacinė detalė, kurią žmonės pamiršta. Rankiniu būdu pasirinktas galinis taškas gali būti atšauktas, o teikėjas pažymi, kad gali prireikti pakeitimo konfigūracijos. Užrašykite, kurį galinį tašką naudoja profilis, kad vėlesnis gedimas būtų diagnozuojamas.
Nuspręskite, ar Pi taip pat yra tinklo vartai
Tunelis, kurį naudoja pačios Pi programėlės, automatiškai netampa tinklo vartais įrenginiams už jo. Persiuntimas, grįžtamasis maršrutizavimas, sprendėjo nuosavybė ir bet kokia politika, neleidžianti srautui ištrūkti už tunelio, yra atskiras dizainas su savo gedimų režimais. Jei kiti įrenginiai patenka į apimtį, vertinkite juos kaip atskirą atvejį, o ne manykite, kad Pi ryšys juos apima. Būtent šis atskyrimas išlaiko mažą diegimą prižiūrimą.
Tada priimkite gyvavimo ciklą: nauja užklausa iš Pi, vardų sprendimas per numatytą sprendėją ir jūsų suplanuotas paleidimo arba prisijungimo iš naujo elgesys. Patikrinkite kiekvieną, o ne manykite, kad programėlė ar profilis tai suteikia.
Mitas, kurio verta atsisakyti, yra tas, kad Linux diegėjas ir WireGuard failas reiškia tą patį sprendimą. Tai du veikimo modeliai su dviem skirtingais savininkais.