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

Міф у тому, що L2TP на Android — ще одна річ, яку може запустити shell-скрипт: додати маршрут, викликати старий сервіс, готово. Так бути не може, бо чотири різні шари мають домовитися, перш ніж тунель понесе пакет. Шар IPsec захищає шлях, L2TP несе сесію, PPP узгоджує канал, а Android має зареєструвати результат як VPN, навколо якого він може маршрутизувати. Я бачив дві спроби зі скопійованими командами, і обидва рази маршрут існував, поки нічого не було зашифровано.

Що насправді дає зміна маршруту

Додавання маршруту вирішує, куди пакет піде далі. Воно не узгоджує асоціацію безпеки, не відкриває сесію L2TP і не виконує обмін PPP, що створює адресу, партнера й налаштування DNS. На телефоні видимий результат — трафік, що виходить не тим шляхом або виходить і вмирає, без будь-якого стану тунелю.

Те саме стосується виклику сервісу, скопійованого зі старого випуску. Внутрішня VPN-обв'язка Android не є опублікованим API автоматизації, а номерна транзакція з іншої версії може потрапити в іншу операцію або вимагати привілеїв, яких скрипт не має. Автоматизація, що несе пароль, ніколи не повинна залежати від угаданих внутрішніх аргументів, бо режим відмови — або тихий no-op, або напівстворений профіль, який ніхто не прибирає.

Чотири власники, і скрипт — жоден із них

Візьміть їх по порядку. 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 застосовуються до нього.
• Жоден внутрішній виклик сервісу, номер транзакції чи угаданий аргумент не несе облікових даних.
• Збій на будь-якому кроці не залишає напівзареєстрований профіль.