De Linux-app ynstallearje klinkt op in Pi sûnder skerm as ien opdracht, en it ferberget in kar tusken twa ynsetpaden mei ferskillende stipegrinzen. Ien is de offisjele app fan de oanbieder, dy’t syn eigen easken foar distribúsje en arsjitektuer hat. De oare is in hânmjittich konfiguraasjebestân dat brûkt wurdt troch in standertklient dy’t it bestjoeringssysteem al ferpakt. Beide berikke deselde tsjinst, en se binne net útwikselber as it om ûnderhâld giet.

De fraach oer de arsjitektuer komt earst, want in 64-bits buordsje kin in 32-bits brûkersromte draaie en de app leveret mar ien fan beide.

Twa stipegrinzen, net twa ynstallearders

Lês de aktuele ynstallaazjeside fan de oanbieder foar de app dy’t jo brûke wolle en fergelykje dy mei it buordsje: distribúsjeferzje, pakketarsjitektuer en elke eask oan buro of sesje. Dat in Pi 64-bits wurkjen stipet, seit net hokker brûkersromte no ynstallearre is, en dat is de wearde dy’t de pakketbehearder kontrolearret. dpkg --print-architecture en uname -m beantwurdzje dat elk yn ien regel. As de ferzje of de arsjitektuer bûten de dokumintearre set falt, wurdt de app dêr net stipe, sels as er ynstallearret.

Stipe ferskilt ek per ferpakkingsmetoade. In beheining dy’t foar ien pakketformaat dokumintearre is, jildt net automatysk foar in bou út in repository, en in distribúsje ôflaat fan Debian is net automatysk in stipe omjouwing. Mienskipspakketten en âlde ynstallaazjerezepten bringe har eigen ûnderhâldsmodel mei, dat jo bewust akseptearje kinne mar net by ûngelok oernimme moatte.

Wat de app jo jout en in profyl net

De offisjele app is mear as in ferbining: hy draacht meastentiids de needstop fan de oanbieder, DNS-ôfhanneling en funksjeskeakels, en de oanbieder stipet dy gedragingen as in set. In hânmjittich profyl dat oan in standertklient jûn wurdt, erft dêr neat fan. De hânmjittige klient hat de libbenssyklus fan de ferbining en it pleatslike flaterbelied, wat goed is as jo se sels konfigurearje en ferrasse as jo oannimme dat se meikamen. Beide opsjes berikke deselde servers; mar ien befettet de logika deromhinne.

As in funksje fan belang is, bygelyks it blokkearjen fan ferkear bûten de tunnel, moat dy yn jo konfiguraasje bestean en net yn de app fan de oanbieder.

WireGuard hânmjittich: de stappen dy’t der ta dogge

De oanbieder dokumintearret it meitsjen fan in WireGuard-konfiguraasje foar in standertkompatibele klient en advisearret dat paad foar hânmjittige opset, wylst OpenVPN foar âldere apparaten bewarre bliuwt. Meitsje it profyl yn it akkountpaniel, bring it nei de Pi en set it dêr del wêr’t allinne de eigner it lêze kin. Plak it bestân nea yn in stipetried, want in freonlike bestânsnamme makket de ynboude privekaai net publisearber. Test dan de tunnel mei ien oanfraach foardat jo der eat oars oan ferbine.

It út tsjinst nimmen fan servers is in operasjoneel detail dat minsken ferjitte. In hânmjittich keazen einpunt kin weromlutsen wurde, en de oanbieder merkt op dat in ferfangende konfiguraasje nedich wêze kin. Skriuw op hokker einpunt it profyl brûkt, sadat in lettere flater diagnoazearber is.

Beslis of de Pi ek in gateway is

In tunnel dy’t troch de eigen apps fan de Pi brûkt wurdt, wurdt net fansels in gateway foar apparaten efter him. Trochstjoering, weromrûting, eigendom fan de resolver en elk belied dat ferkear behinderet om bûten de tunnel te ûntsnappen binne in apart ûntwerp mei eigen flatermodi. As oare apparaten yn it berik binne, beoardielje se as har eigen gefal ynstee fan oan te nimmen dat de ferbining fan de Pi se dekt. Dy skieding hâldt in lytse ynset ûnderhâldber.

Akseptearje dan de libbenssyklus: in nije oanfraach fan de Pi, it oplossen fan nammen troch de bedoelde resolver en it opstart- of werferbiningsgedrach dat jo pland hiene. Ferifiearje elk dêrfan ynstee fan oan te nimmen dat de app of it profyl it leveret.

De myte dy’t it wurdich is los te litten, is dat in Linux-ynstallearder en in WireGuard-bestân deselde beslissing fertsjinwurdigje. It binne twa wurkmodellen mei twa ferskillende eigners.

Relatearre artikelen