A Linux-alkalmazás telepítése egyetlen utasításnak hangzik egy kijelző nélküli Pi-n, mégis két, eltérő támogatási határú telepítési útvonal közötti választást rejt. Az egyik a szolgáltató hivatalos alkalmazása, amely saját disztribúciós és architektúra-követelményeket hordoz. A másik egy kézi konfigurációs fájl, amelyet az operációs rendszer által már csomagolt szabványos kliens használ. Mindkettő ugyanahhoz a szolgáltatáshoz ér el, és karbantartási szempontból nem felcserélhetők.

Az architektúra kérdése jön először, mert egy 64 bites kártya futtathat 32 bites felhasználói teret, az alkalmazás pedig csak az egyiket szállítja.

Két támogatási határ, nem két telepítő

Olvassa el a szolgáltató aktuális telepítési oldalát a használni kívánt alkalmazáshoz, és vesse össze a kártyával: disztribúció-kiadás, csomagarchitektúra és bármilyen asztali vagy munkamenet-követelmény. Az, hogy a Pi támogatja a 64 bites működést, nem mondja meg, melyik felhasználói tér van most telepítve, és a csomagkezelő éppen ezt az értéket ellenőrzi. A dpkg --print-architecture és az uname -m egy-egy sorban válaszol erre. Ha a kiadás vagy az architektúra kívül esik a dokumentált halmazon, az alkalmazás ott nem támogatott, akkor sem, ha települ.

A támogatás a csomagolási módtól is függ. Az egyik csomagformátumhoz dokumentált korlátozás nem vonatkozik automatikusan egy tárolóból készült buildre, és a Debianból származó disztribúció nem automatikusan támogatott környezet. A közösségi csomagok és a régi telepítési receptek saját karbantartási modellt hoznak, amelyet elfogadhat szándékosan, de nem szabad véletlenül átvennie.

Amit az alkalmazás ad, és amit egy profil nem

A hivatalos alkalmazás több puszta kapcsolatnál: általában hozza a szolgáltató vészleállítóját, a DNS-kezelést és a funkciókapcsolókat, és a szolgáltató ezeket a viselkedéseket együtt támogatja. A szabványos kliensnek átadott kézi profil ebből semmit nem örököl. A kézi kliens birtokolja a kapcsolat életciklusát és a helyi hibahelyzet-kezelést, ami rendben van, ha maga állítja be őket, és meglepő, ha azt feltételezi, hogy velük érkeztek. Mindkét lehetőség ugyanazokat a szervereket éri el; csak az egyik tartalmazza a környező logikát.

Ha egy funkció számít, például az alagúton kívüli forgalom blokkolása, akkor annak az Ön konfigurációjában kell léteznie, nem a szolgáltató alkalmazásában.

WireGuard kézzel: a fontos lépések

A szolgáltató dokumentálja a WireGuard-konfiguráció létrehozását szabványkompatibilis klienshez, és ezt az utat ajánlja a kézi beállításokhoz, miközben a régebbi eszközök számára megtartja az OpenVPN-t. Hozza létre a profilt a fiók irányítópultján, vigye át a Pi-re, és olyan helyre tegye, ahol csak a tulajdonos olvashatja. Soha ne illessze be a fájlt támogatási szálba, mert a barátságos fájlnév nem teszi közzé tehetővé a beágyazott privát kulcsot. Ezután egyetlen kéréssel tesztelje az alagutat, mielőtt bármi mást rákapcsolna.

A szerverek kivonása olyan üzemeltetési részlet, amelyről az emberek megfeledkeznek. Egy kézzel kiválasztott végpont visszavonható, és a szolgáltató megjegyzi, hogy helyettesítő konfigurációra lehet szükség. Jegyezze fel, melyik végpontot használja a profil, hogy egy későbbi hiba diagnosztizálható legyen.

Döntse el, hogy a Pi átjáró is-e

A Pi saját alkalmazásai által használt alagút nem válik automatikusan átjáróvá a mögötte lévő eszközök számára. A továbbítás, a visszaútvonalazás, a feloldó tulajdonlása és minden olyan szabály, amely megakadályozza a forgalom kijutását az alagúton kívülre, külön tervezés saját hibahelyzeteivel. Ha más eszközök is a hatókörben vannak, saját esetként értékelje őket, ahelyett hogy feltételezné, hogy a Pi kapcsolata lefedi őket. Ez az elkülönítés tartja karbantarthatóvá a kis telepítést.

Ezután fogadja el az életciklust: friss kérés a Pi-ről, névfeloldás a szándékolt feloldón keresztül, és a tervezett indítási vagy újracsatlakozási viselkedés. Mindegyiket ellenőrizze, ahelyett hogy feltételezné, hogy az alkalmazás vagy a profil biztosítja.

A mese, amelyet érdemes elengedni, az, hogy a Linux-telepítő és a WireGuard-fájl ugyanazt a döntést jelenti. Két üzemeltetési modell két különböző tulajdonossal.

Kapcsolódó cikkek