Egy szkriptnek, amelynek a VPN feljövetele után kell futnia, eseményre van szüksége attól a komponenstől, amely a kapcsolatot birtokolja. Egy régi hálózati hook-könyvtárba tett fájl nem visszahívás minden VPN-hez, amelyet a NetworkManager, a pppd vagy egy önálló OpenVPN-folyamat létrehozhat. E tulajdonosok mindegyike más eseményt jelent más környezettel, ezért a tulajdonost a hook kiválasztása előtt azonosítani kell. Különben a szkript helyes, és egyszerűen soha nem fut le.

A NetworkManager által kezelt VPN esetében a diszpécser a megfelelő hely, és a vpn-up a megfelelő művelet.

A vpn-upot használja, ne az interfész eseményét

A diszpécser megkülönbözteti a up és a vpn-up eseményét. Az első egy aktivált interfészt jelent; a második egy aktivált VPN-kapcsolatot. A Wi-Fi feljövetele csak azt jelenti, hogy az alatta lévő kapcsolat létezik; az alagút még tárgyalhat, vagy soha nem hitelesíthet.

A szkript megkapja az interfészt és a műveletet, míg a kapcsolat részletei a környezeten keresztül érkeznek, beleértve a profil UUID-ját és a VPN IP-interfészét. Olvassa ezeket a változókat, ahelyett hogy az identitást eszköznevekből következtetné.

Szűkítse az egyezést egy kapcsolatra

A kapcsolat UUID-jára vagy a diszpécser által adott más identitásra illesszen, ne egy tun előtagra vagy ppp0. Az interfésznevek nem stabilak, egyszerre több alagút is létezhet, és két profil ugyanazt a megjelenített nevet viselheti. A tun előtagra illesztés azt jelenti, hogy a szkript előbb-utóbb olyan kapcsolatra fut le, amelyhez senki nem akart hozzányúlni. Egy profilra kétszer is lefuthat, amikor az újracsatlakozás újraépíti az eszközt.

Tegye a feladatot idempotenssé. Az a visszahívás, amely minden híváskor útvonalat fűz hozzá, végül duplikátumokkal tölti fel a táblát, és a második példány az, amely elrontja az útválasztást.

Tudja, mit nem bizonyít az aktiválás

vpn-pre-up azelőtt fut, hogy a NetworkManager a VPN teljes aktiválását jelentené, és a kezelő megvárja ezeket a szkripteket. Blokkoló szakaszt csak akkor használjon, ha a feladat valóban odavaló, mert a lassú ellenőrzés késlelteti az aktiválást, amelyre minden más komponens vár.

Az útvonalak megléte nem bizonyítja, hogy egy alkalmazás figyel, hogy egy privát név feloldódik, vagy hogy létezik felhasználói munkamenet. Ezeket külön ellenőrizze korlátozott időtúllépéssel, és jelentse, melyik réteg hibázott, ahelyett hogy az egész láncot újrapróbálná.

Tisztelje a környezetet, amelyben a szkript fut

A diszpécser szkriptjei rootként, minden felhasználói munkameneten kívül futnak. Ne feltételezze, hogy a bejelentkezett felhasználó környezete, grafikus munkamenete vagy feloldott kulcstartója elérhető. Senkinek nem szabadna a hiányzó asztali környezetre úgy reagálnia, hogy minden hitelesítő adatot minden folyamat számára olvashatóvá tesz. Tartsa a felhasználói munkamenet munkáját egy felhasználói szolgáltatásban vagy munkamenet-segédben, amelynek a visszahívás jelezhet a felhasználó megszemélyesítése nélkül.

A szkript tulajdonjoga és jogosultságai is számítanak. Egy rootként futtatott fájl, amelyet bármely felhasználó kicserélhet, a jogosultságnövelés útja, és ez olyan megállapítás, amely független attól, hogy a VPN logikája helyes-e.

Számoljon a bontással, amely soha nem következik be

A NetworkManager dokumentálja, hogy a vpn-pre-down nem kerül kibocsátásra kényszerített bontásoknál, például váratlan leállásnál vagy a kapcsolat elvesztésénél. Ezért a csak egy szabályos pre-down köré épített takarítás szerkezetileg hiányos. Minden megosztott állapothoz, amelyet a szkript módosít, másik tulajdonos kell, aki összeomlás után helyre tudja állítani, és ezt a helyreállítási utat tesztelni kell, nem feltételezni.

Próbálja ki a hookot normál csatlakozással, újracsatlakozással, szándékos bontással és kihúzott kábellel. Jegyezze fel az UUID-t, a műveletet és az interfészt, amely lefutott, titkok naplózása nélkül. Ez a feljegyzés az egyetlen megbízható bizonyíték arra, hogy a hook a szándékolt kapcsolatra futott, és ez teszi biztonságossá a következő változtatást.

Kapcsolódó cikkek