A .ovpn fájlja kódot is futtathat, nem csak forgalmat irányíthat

A legtöbb ember úgy olvassa a .ovpn fájlt, ahogy egy router beállítási oldalát: címek, útvonalak, titkosítások listája. A kódot futtató rész a fájl alja közelében van, vízvezeték-szerű direktívák mellett, és azzal a jogosultsággal fut, amivel a kliens már rendelkezik. Ez az a rés, amelyet a gondatlan vagy rosszindulatú profil kihasznál, és ez az a rés is, amely három hét múlva támogatási problémává tesz egy hasznos DNS-segédet. Az eseménydirektíva, a biztonsági szint és a fájl tulajdonjoga dönti el, mi történhet; a szkript tartalma dönti el, mi történik valójában. Mind a négyet olvassa el, mielőtt kapcsolódik.

A segédet futtató profil program, nem beállításfájl

Az olyan direktívák, mint a route és a dhcp-option, azt az állapotot írják le, amelyet a kliensnek létre kell hoznia, és a kliens adatként kezeli őket. Az up szkript más: a kliens folyamatként indítja, és egy kapcsolati részletekkel teli környezetet ad át neki, így mindaz, amit a szerzője írt, az Ön fiókjának jogaival fut. Egy olyan laptopon, ahol a felhasználó rendszergazda, ez széles ajtó egy mellékletként vagy fórumtémából beillesztett fájl számára. A különbség nem stílusbeli, hanem a konfiguráció és a kód közötti különbség.

A mítosz, amelyet ideje elengedni, hogy egy profil csak átirányítani tudja a forgalmat. Az ip route add parancsot futtató segéd és a távoli gazdagép ellen curl-t futtató segéd ugyanaz a mechanizmus, és a profil kívülről azonosnak látszik. Semmi nem árulja el a fájl külsejében, melyik van Önnél, ezért az ellenőrzésnek magáig a szkriptig kell eljutnia.

Mi dönti el valójában a végrehajtást, és hogyan néznek ki az azt engedélyező sorok

Három dolog irányít egy segédet: az őt megnevező eseménydirektíva, az őt engedélyező script-security szint és maga a kliensplatform megvalósítása. Egy profil kérhet horgot, és mégsem lát semmit történni, mert egy mobil kliens vagy egy lecsupaszított asztali build talán egyáltalán nem valósítja meg azt az eseményt. Ugyanígy az a profil, amely több engedélyt kér, mint amennyire a funkciójának szüksége van, valamit elárul a származásáról. Az engedélyszint képesség, nem jóváhagyás. Az engedélyező sorok így néznek ki, az útvonal az Öné helyett áll.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

A 0. szint elutasítja a külső programokat, az 1. szint, az alapértelmezett, csak a kliens beépített futtatható fájljait engedi, tehát a horognak 2 vagy magasabb kell; a 3. szint főleg a régi jelszavak átadására létezik, és jobb elkerülni. A horoggal szállított profilnak a direktívára és arra a szintre is szüksége van, ezért a fájl alja közelében lévő egyetlen sor ugyanazt a vizsgálatot érdemli, mint a tanúsítványblokk. A OpenVPN kézikönyv felsorolja az engedélyszinteket, és érdemes a megfogalmazását a profil tényleges kérése mellé olvasni.

Tulajdonjog, útvonal és hogy mivel etetik a segédet

Az a profil, amelyben megbízik, de olyan szkriptre mutat, amelyet egy másik fiók átírhat, nem megbízható megoldás, mert a tegnapi ellenőrzés már nem írja le, mi fut ma. Ellenőrizze a segéd tulajdonosát és módját, és azt, hogy a beállított útvonal ahhoz a fájlhoz vezet-e, amelyet megvizsgált, és nem egy olyan névhez, amelyet valami más elfedhet. Az argumentumok és a környezet ugyanezt a pillantást érdemlik: a kliens kapcsolati részleteket ad át a horognak, és egy segéd, amely az egész környezetét naplózza, esetleg hitelesítő adatokat ír egy támogatási jegybe. Részesítse előnyben az üzemeltető vagy a platform dokumentált integrációját egy nem kapcsolódó bejegyzésből másolt DNS-szkripttel szemben, mert két, ugyanazon fájlért harcoló feloldókezelő olyan hibát okoz, amely törött VPN-nek látszik.

Amikor hibás horgot jelent, a környezetet szerkessze ki, mielőtt bárhová beillesztené. A hibakeresést segítő dump hordozhatja azt a tokent is, amely hitelesíti Önt.

A takarítási hibák azután jelennek meg, hogy az alagút elment

Az up segéd útvonalakat és feloldóbeállításokat ad hozzá, a down segédnek pedig el kellene távolítania őket. Ha a down horog hiányzik, csendben meghiúsul, vagy soha nem fut le, mert a klienst megölték, a maradékok túlélik a munkamenetet. A forgalom ekkor olyan útvonalat vesz, amelyet senki nem tervezett, és a nevek olyan feloldón keresztül oldódnak fel, amelyet el kellett volna távolítani, miközben maga az alagút egészségesnek látszik. Ezek a tünetek a bontás után jelentkeznek, ezért a hálózatot hibáztatják a profil helyett.

Tesztelje a bontást külön lépésként: hozza fel az alagutat, jegyezze fel az útvonalakat és a feloldót, engedje le, majd erősítse meg, hogy mindkettő eltűnt. Egy tisztán kapcsolódó profil is hagyhat maga után állapotot, és a segéd nulla kilépési kódja nem bizonyítja, hogy a feloldó ott végződött, ahol gondolja.

A segéd átvizsgálása és a kijárat megtartása

Olvassa el a szkriptet elejétől a végéig, három dolgot keresve: jogosultságot igénylő parancsokat, mereven kódolt útvonalakat, amelyek esetleg nem léteznek a rendszerén, és minden hálózati hívást, amelyet végrehajt. Aztán nézze meg, hogyan hibázik, mert a hibákat lenyelő segéd a konfigurációs hibát rejtéllyé változtatja. Ha egy mondatban nem tudja megmondani, mit tesz a szkript, és ki változtathatja meg, akkor nem áll készen az engedélyezésére. Az a profil, amely több jogosultságot kér, mint amennyit az a mondat igényel, a megállás jele.

Tartsa az utolsó működő profilt és az általa hivatkozott segédet védett tárolóban, mindkét verziót feljegyezve, hogy a visszaállítás másolat legyen, ne újjáépítés a legrosszabb pillanatban. Ha a segéd csak olyan disztribúcióhoz vagy kliensverzióhoz létezik, amelynek már nincs rá szüksége, vonja vissza a beállítást birtokló konfigurációban, ahelyett hogy addig emelné a jogosultságokat, amíg a hibák meg nem szűnnek. Ez a kijárat: kevesebb mozgó alkatrész, nem több engedély.