L2TP-automatizálás Androidon: a szkript kérhet, de nem építhet

A mítosz az, hogy L2TP az Androidon még egy dolog, amit egy shell-szkript elindíthat: adj hozzá egy útvonalat, hívd a régi szolgáltatást, kész. Nem lehet így, mert négy különböző rétegnek meg kell egyeznie, mielőtt egy alagút csomagot visz. Az IPsec réteg védi az utat, az L2TP viszi a munkamenetet, a PPP tárgyalja a kapcsolatot, az Androidnak pedig VPN-ként kell nyilvántartania az eredményt, ami körül útvonalazhat. Kétszer láttam erre kísérletet másolt parancsokkal, és mindkétszer létezett az útvonal, miközben semmi sem volt titkosítva.

Mit ér el valójában az útvonal módosítása

Egy útvonal hozzáadása eldönti, hova megy a csomag következőként. Nem tárgyal biztonsági társítást, nem nyit L2TP-munkamenetet, és nem futtatja azt a PPP-cserét, amely címet, partnert és DNS-beállításokat állít elő. Készüléken a látható eredmény a rossz úton kilépő, vagy kilépő és elhaló forgalom, mindenhol alagútállapot nélkül.

Ugyanez igaz egy régebbi kiadásból másolt szolgáltatáshívásra. Az Android belső VPN-vezetékezése nem publikált automatizálási API, és egy másik verzióból származó számozott tranzakció más műveletet érhet el, vagy olyan jogosultságokat kérhet, amelyekkel a szkript nem rendelkezik. A jelszót szállító automatizálás soha ne függjön kitalált belső argumentumoktól, mert a hiba módja vagy csendes no-op, vagy félkész profil, amelyet senki sem tisztít.

Négy tulajdonos, és a szkript egyik sem

Vedd őket sorrendben. Az IPsec létrehozza és fenntartja a védett utat, és hitelesíti a partnereket. Az L2TP viszi fölötte a munkamenetet, és ez a rétegezés az oka, hogy a szabvány külön mechanizmusként kezeli őket, nem egy protokollként. Ezen belül a PPP tárgyalja a kapcsolat paramétereit, amelyeket a kliens használni fog. Ezután az Android birtokolja a platform oldalát: a regisztrált VPN-felületet, az alkalmazásonkénti hatókört, az always-on állapotot és azt az életciklust, amely eldönti, mi történik az alkalmazás leállításakor.

A szkript csak az utolsó réteget látja, és általában közvetve. Kérheti egy kliens csatlakozását, ha az a kliens dokumentált vezérlést tesz elérhetővé, és utána figyelheti a felület állapotát. Nem helyettesítheti az alatta lévő három réteget, és nem érheti el, hogy a platform egy nem regisztrált felületet VPN-ként kezeljen.

Miért nem rövidítés a daemon sem

Egy privilegizált Linux-daemon indítása az eszközön a hiányzó darabnak tűnik, és gyakran valóban felhoz egy alagutat. Amit nem tesz meg, az az, hogy ezt az alagutat regisztrálja az Androidnál. A felület létezik a kernelben, de a platform VPN-választása, az alkalmazásonkénti útvonalazás, az always-on szabályzat és az életciklus nem tud róla, a daemon saját útvonal- és DNS-változtatásai pedig ugyanazokért a táblákért versenyeznek a hálózatkezelővel.

Az eredmény egy kapcsolat, amely a daemon forgalmának működik, és rejtélyesen nem annak az alkalmazásnak, amely számított neked, vagy egy olyan, amely addig marad, amíg a rendszer újra nem értékeli a hálózatait. Egyik kimenet sem platformhiba; ez a határ a socket birtoklása és a VPN-létesítmény birtoklása között.

Milyenek a támogatott utak

Ha a szervezet áttérhet egy olyan profilra, amelyet maga az Android biztosít, a platform útja az őszinte. Az API 30-tól a VpnManager támogatja a platform VPN-profilok alkalmazások általi biztosítását és vezérlését, a hívó alkalmazáshoz kapcsolt engedélyezési folyamattal. Ez nem L2TP-átalakító: az IKEv2-höz biztosított profilmodell nem fordítja le a meglévő L2TP-konfigurációt, és a protokollváltás migráció, nem átnevezés. Az identitásokat, útvonalakat, privát DNS-t és hozzáférési engedélyeket szándékosan kell átvinni.

Ha a szolgáltatásnak L2TP/IPsec-nek kell maradnia, a támogatott kombináció egy kliens és egy operációsrendszer-kiadás, amelyet az üzemeltető ténylegesen dokumentál, és annak automatizálási szerződése, ha van. Ha nincs dokumentált felügyelet nélküli vezérlés, a helyes válasz egy támogatott kézi kapcsolat, nem pedig egy törékeny privilegizált szkript, amely véletlenül működik egy builden.

Mit tesz egy helyes automatizálás

Dokumentált vezérlés esetén az automatizálásnak kicsi és védhető munkája van: kérje a megnevezett kapcsolatot, várjon a készenlétre, álljon le hitelesítési vagy beállítási hiba esetén, futtassa a tervezett terhelést, és hagyja a takarítást a kapcsolatot birtokló komponensre. A hitelesítő adatok annál a kliensnél maradnak, amely tudja tárolni és forgatni őket.

Írd le, melyik komponens birtokolja az egyes rétegeket, mielőtt megírod az első sort, és ellenőrizd az eredményt ehhez képest:

• Az IPsec-et és a PPP-t a kliens kezeli, nem a szkript útvonalai.
• A kapcsolat megjelenik a platform VPN-állapotában, ezért az alkalmazásonkénti hatókör és az always-on vonatkozik rá.
• Egyetlen belső szolgáltatáshívás, tranzakciószám vagy kitalált argumentum sem szállít hitelesítő adatot.
• Bármely lépés kudarca nem hagy maga után félregisztrált profilt.