Å installere Linux-appen høyrest ut som éin instruksjon på ein Pi utan skjerm, og det skjuler eit val mellom to utrullingsvegar med ulike støttegrenser. Den eine er den offisielle appen til leverandøren, som har eigne krav til distribusjon og arkitektur. Den andre er ei manuell konfigurasjonsfil som blir brukt av ein standardklient som operativsystemet allereie pakkar. Begge når same tenesta, og dei er ikkje utskiftbare når det gjeld vedlikehald.

Arkitekturspørsmålet kjem først, fordi eit 64-bits kort kan køyre eit 32-bits brukarrom, og appen blir berre levert med eitt av dei.

To støttegrenser, ikkje to installasjonsprogram

Les den gjeldande installasjonssida til leverandøren for appen du vil bruke, og samanlikn ho med kortet: distribusjonsutgåve, pakkearkitektur og eventuelle krav til skrivebord eller økt. At ein Pi støttar 64-bits drift, seier ikkje kva brukarrom som er installert no, og det er verdien pakkehandsamaren kontrollerer. dpkg --print-architecture og uname -m svarar på det med kvar si linje. Viss utgåva eller arkitekturen ligg utanfor det dokumenterte settet, blir appen ikkje støtta der, sjølv når han blir installert.

Støtta varierer òg etter pakkemetode. Ei avgrensing som er dokumentert for eitt pakkeformat, gjeld ikkje automatisk for ein bygg frå eit lager, og ein Debian-avleidd distribusjon er ikkje automatisk eit støtta miljø. Fellesskapspakkar og gamle installasjonsoppskrifter har sin eigen vedlikehaldsmodell, som du kan godta med vilje, men ikkje bør overta ved eit uhell.

Kva appen gir deg som ein profil ikkje gir

Den offisielle appen er meir enn ei tilkopling: han har vanlegvis naudstoppen til leverandøren, DNS-handtering og funksjonsbrytarar, og leverandøren støttar desse åtferdene som eitt sett. Ein manuell profil som blir gitt til ein standardklient, arvar ingenting av dette. Standardklienten eig livssyklusen til tilkoplinga og den lokale feilpolitikken, noko som er greitt når du konfigurerer dei sjølv og overraskande når du går ut frå at dei følgde med. Begge alternativa når dei same tenarane; berre eitt inkluderer logikken rundt.

Viss ein funksjon betyr noko, til dømes å blokkere trafikk utanfor tunnelen, må han finnast i konfigurasjonen din og ikkje i appen til leverandøren.

WireGuard manuelt: trinna som betyr noko

Leverandøren dokumenterer generering av ein WireGuard-konfigurasjon for ein standardkompatibel klient og tilrår den vegen for manuelle oppsett, medan OpenVPN blir halden for eldre einingar. Generer profilen i kontodashbordet, ta han med til Pi-en og legg han der berre eigaren kan lese han. Lim aldri fila inn i ein støttetråd, for eit venleg filnamn gjer ikkje den innebygde private nøkkelen publiserbar. Test deretter tunnelen med éin førespurnad før du koplar noko anna til han.

Utfasing av tenarar er ein driftsdetalj folk gløymer. Eit manuelt valt endepunkt kan bli trekt tilbake, og leverandøren nemner at ein erstatningskonfigurasjon kan vere nødvendig. Noter kva endepunkt profilen brukar, slik at ein seinare feil kan diagnostiserast.

Avgjer om Pi-en òg er ein gateway

Ein tunnel som dei eigne applikasjonane til Pi-en brukar, blir ikkje automatisk ein gateway for einingar bak han. Videresending, returruting, eigarskap til resolvaren og kvar ei politikk som hindrar trafikk i å sleppe ut utanfor tunnelen, er eit eige design med eigne feilmodus. Viss andre einingar er i omfanget, vurder dei som si eiga sak i staden for å gå ut frå at tilkoplinga til Pi-en dekkjer dei. Denne separasjonen er det som held ein liten utrulling vedlikehaldbar.

Godta deretter livssyklusen: ein fersk førespurnad frå Pi-en, namneoppslag gjennom den tiltenkte resolvaren og oppstarts- eller gjenoppkoplingsåtferda du planla. Stadfest kvar av dei i staden for å gå ut frå at appen eller profilen leverer dei.

Myten det er verdt å sleppe, er at eit Linux-installasjonsprogram og ei WireGuard-fil representerer den same avgjerda. Dei er to driftsmodellar med to ulike eigarar.

Relaterte artiklar