Автоматизација на 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 важат за неа.
• Ниту еден внатрешен повик на сервис, број на трансакција или погоден аргумент не носи акредитив.
• Неуспех на кој било чекор не остава половично регистриран профил.