A másodlagos VPN egy Wi-Fi-profilhoz tartozik, nem mindegyikhez
A másodlagos VPN egyetlen báziskapcsolathoz csatolt UUID. Tervezze meg, hogyan öröklik majd a jövőbeli Wi-Fi-profilok, és mi történik, ha azt az UUID-t lecserélik.
Állítson be egy VPN-t az otthoni Wi-Fi-kapcsolat másodlagos elemeként, és minden működik, amíg a laptop egy másik hozzáférési ponthoz nem csatlakozik, és az alagút nem marad lent. Az új kapcsolat külön konfigurációs objektum saját UUID-vel, és semmi oka nincs tudni arról a kötésről, amelyet az elődjének készített. Semmi nem hibásodott meg; a társítás egyszerűen soha nem létezett.
A NetworkManager kapcsolati referenciája a másodlagosokat olyan UUID-ként határozza meg, amelyek egy adott báziskapcsolattal együtt aktiválódnak. Azt is megjegyzi, hogy a közönséges VPN-profilok nem valósítják meg az automatikus aktiválást úgy, ahogy a báziskapcsolatok. Mindkét állítás ugyanahhoz a következtetéshez vezet: a társítás profilonként értendő, és valakinek minden újhoz létre kell hoznia.
Mi is valójában a másodlagos
A báziskapcsolatnak van identitása, UUID-je és másodlagosainak listája. Amikor aktiválódik, a kezelő ezeket a másodlagosokat is sorrendben aktiválja, és így egy VPN kézi kattintás nélkül követ egy Wi-Fi-hálózatot. A kapcsolat a báziskapcsolaton él, UUID-sztringekként írva, nem nevekként. Ez a reprezentációs választás nem véletlen; ez teszi lehetővé, hogy a társítás túléljen egy átnevezést.
Ez a névvel kapcsolatos részlet fontosabb, mint látszik. Egy VPN-profil átnevezése érintetlenül hagyja az UUID-jét, így a meglévő társítások tovább működnek. A régi profil törlése és egy új importálása új UUID-t eredményez, és minden társítás, amely a régire mutatott, most semmire sem mutat.
Hozzáadás előtt vizsgálja meg a meglévő listát. Az egy másodlagost hordozó otthoni profil nem minden SSID-re illeszkedő szabály; ez egy sor egy objektumban, és nem kérdezik meg, amikor egy másik bázis aktiválódik.
Oda tegye a társítást, ahol a profilok készülnek
Személyes gépen tegye a szándékolt másodlagos csatolását minden engedélyezett Wi-Fi-profil hozzáadásának részévé. Ez szokás, nem funkció, de olyan szokás, amely konzisztens állapotot eredményez, és hálózatonként egy parancsot vagy két párbeszédlátogatást igényel. Vezessen rövid feljegyzést arról, mely hálózatoknak kell hordozniuk az alagutat, mert a lista maga a szabályzat.
Kezelt eszközökön a kiépítési munkafolyamat hozza létre a Wi-Fi-bejegyzést és annak VPN-társítását ugyanabban a lépésben, és ugyanezt alkalmazza a már létező engedélyezett profilokra is. Egy VPN-profil önmagában történő terjesztése meghatározatlanul hagyja a báziskapcsolati viszonyokat, és így egy flotta olyan alagutat kap, amelyet csak a laptopok fele használ.
Ahol a felhasználók még a kezelt útvonalon kívül is létrehozhatnak profilokat, ott kifejezetten döntse el, mi történik ezekkel a bejegyzésekkel. Feltételezni, hogy társítást örökölnek, nem szabályzat; ez egy remény, amelyhez támogatási költség tapad.
Tervezze meg a VPN identitásának változását
A kiépítési forrásnak a szándékolt VPN UUID-jére van szüksége, nem egy kitalált megjelenítendő névre. Amikor a karbantartás ezt a VPN-t egy frissen importált objektummal helyettesíti, ugyanabban a változtatásban frissítse a kiépítési sablont és az érintett meglévő társításokat. Az átnevezés nem helyettesítés, és a kettő egyenértékűként kezelése az, amitől egy működő bevezetés egy hét múlva eltörik.
Az UUID-t a létezésének oka mellett tárolja. Egy jövőbeli mérnök, aki csupasz UUID-t talál a másodlagosok listáján, nem tudja megmondani, hogy aktuális-e, és valószínűleg törölni fogja rendrakás közben.
Az aktiválás nem kikényszerítés
A másodlagos iránti kérés aktiváláskor történik. Nem blokkolja az alkalmazásokat a hitelesítés befejezése előtti időszakban, és nem állítja le a forgalmat, miután az alagút meghibásodik. Ezek különböző tulajdonságok, amelyeket különböző mechanizmusok biztosítanak, és összekeverésük olyan tervet eredményez, amely a profilban szigorúnak látszik, a gyakorlatban pedig engedékeny.
A közvetlen forgalom blokkolása külön funkció saját konfigurációval és saját hibaüzemmódokkal, és figyelembe kell vennie a forgalmat, amelynek el kell érnie a hálózatot, mielőtt bármilyen alagút létezhet: captive portálok, bejelentkező oldalak, maga a végpont. Egy blokkolási szabályzat, amely a hitelesítés előtt nem teljesíthető, kizárja a gépet éppen abból a hálózatból, amelyre szüksége van.
Tegye ezt a különbséget azokba az útmutatókba, amelyeket a felhasználók ténylegesen olvasnak. Egy új Wi-Fi-hálózat kérheti az alagutat; a kikényszerítés dönti el, hogy kimehet-e valami, amikor nem lehet csatlakozni. Azok a felhasználók, akiknek csak az első felét mondják el, hibásnak jelentik a tervet.
Valóban új profillal teszteljen
Jóváhagyott teszthálózatot és újonnan létrehozott bázisprofilt használjon, ne a már működő otthoni bejegyzést. Figyelje meg a bázis aktiválását, a kért másodlagos UUID-t és minden hitelesítési kérést sorrendben, és jegyezze fel, melyik szakasz akad meg, amikor megakad. Az asztali bejelentkezés után elérhetővé váló titkos ügynök nem minden indítási környezetben van automatikusan jelen, ezért az újraindítás a tesztterv része. Ezután ellenőrizze a szándékolt erőforrást és a hibaútvonalat: feljön-e az alagút, mielőtt az alkalmazásnak szüksége lenne rá, és mi történik azzal az alkalmazással, amikor a hitelesítés meghiúsul?
Ezután ellenőrizze a szándékolt erőforrást és a hibaútvonalat: feljön-e az alagút, mielőtt az alkalmazásnak szüksége lenne rá, és mi történik azzal az alkalmazással, amikor az alagút nem tud hitelesíteni? Ez a két megfigyelés az elfogadási kritérium, és egyik sem látható magában a profilban.