Proton VPN på en Pi utan skärm: app eller WireGuard-fil?

Att installera Linux-appen låter som en enda instruktion på en Pi utan skärm, och det döljer ett val mellan två driftsättningsvägar med olika stödgränser. Den ena är leverantörens officiella app, som bär sina egna krav på distribution och arkitektur. Den andra är en manuell konfigurationsfil som används av en standardklient som operativsystemet redan paketerar. Båda når samma tjänst, och de är inte utbytbara när det gäller underhåll.

Arkitekturfrågan kommer först, eftersom ett 64-bitarskort kan köra ett 32-bitars användarutrymme och appen bara levereras med ett av dem.

Två stödgränser, inte två installationsprogram

Läs leverantörens aktuella installationssida för appen du tänker använda och jämför den med kortet: distributionsutgåva, paketarkitektur och eventuella krav på skrivbord eller session. Att en Pi stöder 64-bitars drift säger inte vilket användarutrymme som är installerat nu, och det är det värdet pakethanteraren kontrollerar. dpkg --print-architecture och uname -m svarar på det med en rad var. Om utgåvan eller arkitekturen ligger utanför den dokumenterade mängden stöds inte appen där, även när den installeras.

Stödet varierar också med paketeringsmetoden. En begränsning som dokumenterats för ett paketformat gäller inte automatiskt för en byggnad från ett förråd, och en Debian-baserad distribution är inte automatiskt en miljö som stöds. Gemenskapspaket och gamla installationsrecept har sin egen underhållsmodell, som du kan acceptera medvetet men inte bör ta över av misstag.

Vad appen ger som en profil inte ger

Den officiella appen är mer än en anslutning: den brukar bära leverantörens nödstopp, DNS-hantering och funktionsväxlar, och leverantören stöder dessa beteenden som en helhet. En manuell profil som ges till en standardklient ärver inget av detta. Standardklienten äger anslutningens livscykel och den lokala felpolicyn, vilket är bra när du konfigurerar dem själv och överraskande när du antar att de följde med. Båda alternativen når samma servrar; bara ett innehåller logiken runt omkring.

Om en funktion spelar roll, till exempel att blockera trafik utanför tunneln, måste den finnas i din konfiguration och inte i leverantörens app.

WireGuard manuellt: stegen som spelar roll

Leverantören dokumenterar generering av en WireGuard-konfiguration för en standardkompatibel klient och rekommenderar den vägen för manuella uppsättningar, medan OpenVPN behålls för äldre enheter. Generera profilen i kontopanelen, ta den till Pi:n och lägg den där bara ägaren kan läsa den. Klistra aldrig in filen i en supporttråd, för ett vänligt filnamn gör inte den inbäddade privata nyckeln publicerbar. Testa sedan tunneln med en enda begäran innan du ansluter något annat till den.

Utfasning av servrar är en driftdetalj som folk glömmer. En manuellt vald slutpunkt kan dras tillbaka, och leverantören noterar att en ersättningskonfiguration kan behövas. Anteckna vilken slutpunkt profilen använder så att ett senare fel går att diagnosticera.

Avgör om Pi:n också är en gateway

En tunnel som Pi:ns egna applikationer använder blir inte automatiskt en gateway för enheter bakom den. Vidarebefordran, returrouting, ägarskap av resolvern och varje policy som hindrar trafik från att läcka ut utanför tunneln är en separat design med egna fellägen. Om andra enheter ingår i omfattningen ska de bedömas som sitt eget fall i stället för att anta att Pi:ns anslutning täcker dem. Den separationen är det som håller en liten driftsättning underhållbar.

Acceptera sedan livscykeln: en ny begäran från Pi:n, namnmatchning via den avsedda resolvern och det start- eller återanslutningsbeteende som du planerade. Verifiera var och en i stället för att anta att appen eller profilen tillhandahåller dem.

Myten som är värd att släppa är att ett Linux-installationsprogram och en WireGuard-fil representerar samma beslut. De är två driftmodeller med två olika ägare.