Automatizare L2TP pe Android: un script poate cere, dar nu poate construi

Mitul este că L2TP pe Android este încă un lucru pe care un script shell îl poate porni: adaugi o rută, apelezi serviciul vechi, gata. Nu poate fi, pentru că patru straturi diferite trebuie să fie de acord înainte ca un tunel să transporte un pachet. Stratul IPsec protejează calea, L2TP transportă sesiunea, PPP negociază legătura, iar Android trebuie să înregistreze rezultatul ca o VPN în jurul căreia poate ruta. Am văzut asta încercat de două ori cu comenzi copiate, și de ambele ori ruta exista în timp ce nimic nu era criptat.

Ce realizează de fapt o schimbare de rută

Adăugarea unei rute decide unde merge pachetul în continuare. Nu negociază o asociere de securitate, nu deschide o sesiune L2TP și nu execută schimbul PPP care produce o adresă, un partener și setări DNS. Pe un telefon, rezultatul vizibil este trafic care iese pe calea greșită sau iese și moare, fără nicio stare de tunel nicăieri.

Același lucru este valabil pentru un apel de serviciu copiat dintr-o versiune mai veche. Instalația VPN internă a Android nu este un API de automatizare publicat, iar o tranzacție numerotată dintr-o altă versiune poate lovi altă operație sau poate cere privilegii pe care scriptul nu le are. O automatizare care transportă o parolă nu ar trebui să depindă niciodată de argumente interne ghicite, pentru că modul de eșec este fie un no-op silențios, fie un profil pe jumătate creat pe care nimeni nu îl curăță.

Patru proprietari, iar scriptul nu este niciunul

Ia-le în ordine. IPsec stabilește și întreține calea protejată și autentifică partenerii. L2TP transportă sesiunea peste ea, iar stratificarea este motivul pentru care standardul le tratează ca mecanisme separate, nu ca un singur protocol. În interiorul acestui lucru, PPP negociază parametrii legăturii pe care clientul îi va folosi. Apoi Android deține partea de platformă: interfața VPN înregistrată, sfera pe aplicație, starea always-on și ciclul de viață care decide ce se întâmplă când aplicația este omorâtă.

Un script poate vedea doar ultimul dintre aceste straturi, și de obicei indirect. Poate cere unui client să se conecteze dacă acel client expune un control documentat, și poate urmări starea interfeței după aceea. Nu poate înlocui cele trei straturi de dedesubt și nu poate face platforma să trateze o interfață neînregistrată ca VPN.

De ce nici un demon nu este o scurtătură

Pornirea unui demon Linux privilegiat pe dispozitiv pare piesa lipsă și adesea ridică într-adevăr un tunel. Ceea ce nu face este să înregistreze acel tunel la Android. Interfața există în kernel, dar selecția VPN a platformei, rutarea pe aplicație, politica always-on și ciclul de viață nu știu de ea, iar modificările proprii de rută și DNS ale demonului concurează cu managerul de rețea pentru aceleași tabele.

Rezultatul este o conexiune care funcționează pentru traficul demonului și în mod misterios nu pentru aplicația care conta pentru tine, sau una care supraviețuiește până când sistemul își reevaluează rețelele. Niciunul dintre rezultate nu este un bug al platformei; este granița dintre a deține un socket și a deține facilitatea VPN.

Cum arată căile acceptate

Dacă organizația poate trece la un profil pe care Android îl furnizează singur, calea platformei este cea onestă. De la API 30, VpnManager acceptă furnizarea și controlul profilurilor VPN ale platformei de către aplicații, cu un flux de autorizare legat de aplicația care apelează. Nu este un convertor L2TP: modelul de profil furnizat pentru IKEv2 nu traduce o configurație L2TP existentă, iar schimbarea protocolului este o migrare, nu o redenumire. Identitățile, rutele, DNS-ul privat și permisiunile de acces trebuie transferate intenționat.

Dacă serviciul trebuie să rămână L2TP/IPsec, combinația acceptată este un client și o versiune de sistem pe care operatorul o documentează cu adevărat, și contractul său de automatizare dacă există. Când nu există un control nesupravegheat documentat, răspunsul corect este o conexiune manuală acceptată, nu un script privilegiat fragil care se întâmplă să funcționeze pe un singur build.

Ce face o automatizare corectă

Având un control documentat, automatizarea are o sarcină mică și apărabilă: cere conexiunea numită, așteaptă disponibilitatea, oprește-te la eșec de autentificare sau configurare, rulează încărcătura de lucru dorită și lasă curățarea componentei care deține conexiunea. Acreditările rămân la clientul care știe să le stocheze și să le rotească.

Notează ce componentă deține fiecare strat înainte de a scrie prima linie și verifică rezultatul față de asta:

• IPsec și PPP sunt gestionate de client, nu de rutele scriptului.
• Conexiunea apare în starea VPN a platformei, așa că sfera pe aplicație și always-on se aplică ei.
• Niciun apel intern de serviciu, număr de tranzacție sau argument ghicit nu transportă o acreditare.
• Un eșec la orice pas nu lasă în urmă un profil pe jumătate înregistrat.