Linuxi rakenduse paigaldamine kõlab ekraanita Pi peal ühe juhisena, kuid peidab valiku kahe erineva tugipiiriga juurutustee vahel. Üks on teenusepakkuja ametlik rakendus, mis kannab omaenda distributsiooni- ja arhitektuurinõudeid. Teine on käsitsi konfiguratsioonifail, mida kasutab standardklient, mille operatsioonisüsteem juba pakendab. Mõlemad jõuavad samasse teenusesse ja need ei ole hoolduse mõttes vahetatavad.

Arhitektuuri küsimus tuleb esimesena, sest 64-bitine plaat võib käitada 32-bitist kasutajaruumi ja rakendus tarnitakse ainult ühega neist.

Kaks tugipiiri, mitte kaks paigaldajat

Lugege teenusepakkuja praegust paigalduslehte rakenduse kohta, mida kavatsete kasutada, ja võrrelge seda plaadiga: distributsiooni väljaanne, paketi arhitektuur ning kõik töölaua või sessiooni nõuded. See, et Pi toetab 64-bitist töötamist, ei ütle, milline kasutajaruum on praegu paigaldatud, ja just seda väärtust kontrollib paketihaldur. dpkg --print-architecture ja uname -m vastavad sellele kumbki ühe reaga. Kui väljaanne või arhitektuur jääb dokumenteeritud hulgast välja, ei toetata rakendust seal ka siis, kui see paigaldub.

Tugi varieerub ka pakendusmeetodi järgi. Ühe paketivormingu jaoks dokumenteeritud piirang ei kehti automaatselt hoidlast tehtud ehitisele ja Debianist tuletatud distributsioon ei ole automaatselt toetatud keskkond. Kogukonna paketid ja vanad paigaldusretseptid toovad oma hooldusmudeli, mille võite teadlikult vastu võtta, kuid mida ei tohiks kogemata omaks võtta.

Mida rakendus annab ja profiil mitte

Ametlik rakendus on enam kui ühendus: see kannab tavaliselt teenusepakkuja hädalülitit, DNS-käsitlust ja funktsioonilüliteid ning teenusepakkuja toetab neid käitumisi komplektina. Standardkliendile antud käsitsi profiil ei päri sellest midagi. Käsitsi klient omab ühenduse elutsüklit ja kohalikku tõrkepoliitikat, mis on korras, kui konfigureerite need ise, ja üllatav, kui eeldate, et need tulid kaasa. Mõlemad valikud jõuavad samadesse serveritesse; ainult üks sisaldab ümbritsevat loogikat.

Kui mõni funktsioon on oluline, näiteks tunnelist väljapoole liikuva liikluse blokeerimine, peab see olema teie konfiguratsioonis, mitte teenusepakkuja rakenduses.

WireGuard käsitsi: olulised sammud

Teenusepakkuja dokumenteerib standardiga ühilduva kliendi WireGuardi konfiguratsiooni loomist ja soovitab seda teed käsitsi seadistamiseks, jättes OpenVPN vanemate seadmete jaoks. Looge profiil kontopaneelil, tooge see Pi peale ja asetage sinna, kus ainult omanik saab seda lugeda. Ärge kunagi kleepige faili tugiteemasse, sest sõbralik failinimi ei muuda manustatud privaatvõtit avaldatavaks. Seejärel testige tunnelit ühe päringuga enne, kui ühendate sellega midagi muud.

Serverite kasutusest kõrvaldamine on operatiivne detail, mille inimesed unustavad. Käsitsi valitud lõpp-punkt võidakse tagasi võtta ja teenusepakkuja märgib, et asenduskonfiguratsioon võib osutuda vajalikuks. Märkige üles, millist lõpp-punkti profiil kasutab, et hilisemat tõrget saaks diagnoosida.

Otsustage, kas Pi on ka lüüs

Tunnel, mida kasutavad Pi enda rakendused, ei muutu automaatselt selle taga olevate seadmete lüüsiks. Edastamine, tagasisuunamine, resolveri omandiõigus ja mis tahes poliitika, mis takistab liiklusel tunnelist välja pääsemist, on eraldi disain oma tõrkerežiimidega. Kui teised seadmed on ulatuses, hinnake neid eraldi juhtumina, selle asemel et eeldada, et Pi ühendus katab need. Just see eraldatus hoiab väikese juurutuse hooldatavana.

Seejärel nõustuge elutsükliga: värske päring Pi-lt, nimede lahendamine kavandatud resolveri kaudu ja kavandatud käivitumis- või taasühendumiskäitumine. Kontrollige igaüht, selle asemel et eeldada, et rakendus või profiil selle pakub.

Müüt, millest tasub loobuda, on see, nagu esindaksid Linuxi paigaldaja ja WireGuardi fail sama otsust. Need on kaks töömudelit kahe erineva omanikuga.

Seotud artiklid