Автоматизация на L2TP в Android: скриптът може да поиска, но не да построи

Митът е, че L2TP в Android е още едно нещо, което скрипт може да стартира: добави маршрут, извикай старата услуга, готово. Не може, защото четири различни слоя трябва да се съгласуват, преди тунел да пренесе пакет. Слоят IPsec защитава пътя, L2TP носи сесията, PPP договаря връзката, а Android трябва да регистрира резултата като VPN, около което да маршрутизира. Виждал съм два опита с копирани команди и в двата случая маршрутът съществуваше, докато нищо не беше криптирано.

Какво всъщност постига промяна на маршрут

Добавянето на маршрут решава накъде отива пакетът следващия. То не договаря асоциация за сигурност, не отваря сесия L2TP и не изпълнява PPP обмена, който дава адрес, партньор и настройки за DNS. На телефон видимият резултат е трафик, който излиза по грешния път, или излиза и умира, без никакво състояние на тунел.

Същото важи за извикване на услуга, копирано от по-стар release. Вътрешната VPN инфраструктура на Android не е публикуван API за автоматизация и номерирана транзакция от друга версия може да уцели друга операция или да изиска права, които скриптът няма. Автоматизация, която носи парола, никога не трябва да разчита на гадани вътрешни аргументи, защото отказът е или тихо бездействие, или полускъсен профил, който никой не изчиства.

Четири собственика, а скриптът не е нито един от тях

Вземете ги поред. IPsec установява и поддържа защитения път и удостоверява партньорите. L2TP носи сесията по него и точно това подреждане е причината стандартът да ги третира като отделни механизми, а не като един протокол. Вътре PPP договаря параметрите на връзката, които клиентът ще използва. После Android притежава платформената страна: регистрирания VPN интерфейс, обхвата по приложения, състоянието always-on и жизнения цикъл, който решава какво става при убиване на приложението.

Скриптът вижда само последния от тези слоеве и обикновено косвено. Може да поиска от клиент да се свърже, ако той предлага документирано управление, и после да наблюдава състоянието на интерфейса. Не може да замести трите слоя под него и не може да накара платформата да третира нерегистриран интерфейс като VPN.

Защо демонът също не е пряк път

Стартирането на привилегирован Linux демон на устройството изглежда липсващото парче и често наистина вдига тунел. Това, което не прави, е да регистрира този тунел в Android. Интерфейсът съществува в ядрото, но изборът на VPN на платформата, маршрутизацията по приложения, политиката always-on и жизненият цикъл не знаят за него, а собствените промени на маршрути и DNS на демона се състезават с мрежовия мениджър за същите таблици.

Резултатът е връзка, която работи за трафика на демона и мистериозно не работи за приложението, което ви интересува, или такава, която оцелява, докато системата преоцени мрежите си. Нито един изход не е дефект на платформата; това е границата между притежаването на сокет и притежаването на VPN възможност.

Как изглеждат поддържаните пътища

Ако организацията може да премине към профил, който Android сам предоставя, платформенният път е честният. От API 30, VpnManager поддържа предоставяне и управление на платформени VPN профили от приложения, с работен поток за оторизация, свързан с извикващото приложение. Той не е конвертор за L2TP: моделът на профила, който предоставя за IKEv2, не превежда съществуваща L2TP конфигурация, а смяната на протокол е миграция, не преименуване. Идентичности, маршрути, частен DNS и права за достъп трябва да се пренесат съзнателно.

Ако услугата трябва да остане на L2TP/IPsec, поддържаната комбинация е клиент и версия на ОС, които операторът наистина документира, и неговият договор за автоматизация, ако има такъв. Когато няма документирано управление без надзор, верният отговор е поддържана ръчна връзка, а не чуплив привилегирован скрипт, който случайно работи на една сборка.

Какво прави правилната автоматизация

При документирано управление автоматизацията има малка и защитима задача: поискай именуваната връзка, изчакай готовност, спри при неуспех на удостоверяване или настройка, изпълни предвидената работа и остави почистването на компонента, който притежава връзката. Данните за достъп остават при клиента, който знае как да ги съхранява и сменя.

Запишете кой компонент притежава всеки слой, преди да напишете първия ред, и проверете резултата спрямо това:

• IPsec и PPP се обработват от клиента, не от маршрутите на скрипта.
• Връзката се появява в VPN състоянието на платформата, така че обхватът по приложения и always-on важат за нея.
• Никое вътрешно извикване на услуга, номер на транзакция или гадан аргумент не носи данни за достъп.
• Неуспех на който и да е етап не оставя полурегистриран профил.