Å installere Linux-appen høres ut som én instruksjon på en Pi uten skjerm, og den skjuler et valg mellom to utrullingsveier med ulike støttegrenser. Den ene er leverandørens offisielle app, som har egne krav til distribusjon og arkitektur. Den andre er en manuell konfigurasjonsfil som brukes av en standardklient som operativsystemet allerede pakker. Begge når samme tjeneste, og de er ikke utskiftbare når det gjelder vedlikehold.

Arkitekturspørsmålet kommer først, fordi et 64-bits kort kan kjøre et 32-bits brukerrom, og appen leveres bare med ett av dem.

To støttegrenser, ikke to installasjonsprogrammer

Les leverandørens gjeldende installasjonsside for appen du vil bruke, og sammenlign den med kortet: distribusjonsutgave, pakkearkitektur og eventuelle krav til skrivebord eller økt. At en Pi støtter 64-bits drift, sier ikke hvilket brukerrom som er installert nå, og det er verdien pakkebehandleren kontrollerer. dpkg --print-architecture og uname -m svarer på det med hver sin linje. Hvis utgaven eller arkitekturen ligger utenfor det dokumenterte settet, støttes ikke appen der, selv når den installeres.

Støtten varierer også etter pakkemetode. En begrensning som er dokumentert for ett pakkeformat, gjelder ikke automatisk for en bygging fra et lager, og en Debian-avledet distribusjon er ikke automatisk et støttet miljø. Fellesskapspakker og gamle installasjonsoppskrifter har sin egen vedlikeholdsmodell, som du kan godta bevisst, men ikke bør overta ved et uhell.

Hva appen gir deg som en profil ikke gir

Den offisielle appen er mer enn en tilkobling: den har vanligvis leverandørens nødstopp, DNS-håndtering og funksjonsbrytere, og leverandøren støtter disse oppførslene som et sett. En manuell profil som gis til en standardklient, arver ingenting av dette. Standardklienten eier livssyklusen til tilkoblingen og den lokale feilpolitikken, noe som er greit når du konfigurerer dem selv og overraskende når du antar at de fulgte med. Begge alternativene når de samme serverne; bare ett inkluderer logikken rundt.

Hvis en funksjon betyr noe, for eksempel å blokkere trafikk utenfor tunnelen, må den finnes i konfigurasjonen din og ikke i leverandørens app.

WireGuard manuelt: trinnene som betyr noe

Leverandøren dokumenterer generering av en WireGuard-konfigurasjon for en standardkompatibel klient og anbefaler den veien for manuelle oppsett, mens OpenVPN beholdes for eldre enheter. Generer profilen i kontodashbordet, ta den med til Pi-en og legg den der bare eieren kan lese den. Lim aldri filen inn i en støttetråd, for et vennlig filnavn gjør ikke den innebygde private nøkkelen publiserbar. Test deretter tunnelen med én forespørsel før du kobler noe annet til den.

Utfasing av servere er en driftsdetalj folk glemmer. Et manuelt valgt endepunkt kan trekkes tilbake, og leverandøren bemerker at en erstatningskonfigurasjon kan være nødvendig. Noter hvilket endepunkt profilen bruker, slik at en senere feil kan diagnostiseres.

Avgjør om Pi-en også er en gateway

En tunnel som Pi-ens egne applikasjoner bruker, blir ikke automatisk en gateway for enheter bak den. Videresending, returruting, eierskap til resolveren og enhver policy som hindrer trafikk i å slippe ut utenfor tunnelen, er et eget design med egne feilmoduser. Hvis andre enheter er i omfanget, vurder dem som sin egen sak i stedet for å anta at Pi-ens tilkobling dekker dem. Denne separasjonen er det som holder en liten utrulling vedlikeholdbar.

Godta deretter livssyklusen: en fersk forespørsel fra Pi-en, navneoppslag gjennom den tiltenkte resolveren og oppstarts- eller gjenoppkoblingsatferden du planla. Verifiser hver av dem i stedet for å anta at appen eller profilen leverer dem.

Myten det er verdt å slippe, er at et Linux-installasjonsprogram og en WireGuard-fil representerer den samme beslutningen. De er to driftsmodeller med to forskjellige eiere.

Relaterte artikler