Automatizimi i L2TP në Android: një skript mund të kërkojë, jo ta ndërtojë

Miti është se L2TP në Android është edhe një gjë që një skript shell mund ta nisë: shto një rrugë, thirr shërbimin e vjetër, mbaroi. Nuk mund të jetë, sepse katër shtresa të ndryshme duhet të bien dakord përpara se një tunel të mbajë një paketë. Shtresa IPsec mbron rrugën, L2TP mbart sesionin, PPP negocion lidhjen, dhe Android duhet ta regjistrojë rezultatin si VPN rreth së cilës mund të rutojë. E kam parë këtë të provohet dy herë me komanda të kopjuara, dhe të dyja herët rruga ekzistonte ndërsa asgjë nuk ishte e kriptuar.

Çfarë arrin vërtet një ndryshim rruge

Shtimi i një rruge vendos ku shkon paketa më pas. Ai nuk negocion një asociacion sigurie, nuk hap një sesion L2TP dhe nuk ekzekuton shkëmbimin PPP që prodhon një adresë, një palë dhe cilësime DNS. Në një telefon, rezultati i dukshëm është trafik që del në rrugën e gabuar, ose del dhe vdes, pa asnjë gjendje tuneli askund.

E njëjta gjë vlen për një thirrje shërbimi të kopjuar nga një version më i vjetër. Instalimi i brendshëm VPN i Android nuk është një API automatizimi e publikuar, dhe një transaksion i numëruar nga një version tjetër mund të godasë një operacion tjetër ose të kërkojë privilegje që skripti nuk i ka. Një automatizim që mbart një fjalëkalim nuk duhet të varet kurrë nga argumente të brendshme të hamendësuara, sepse mënyra e dështimit është ose një no-op i heshtur ose një profil gjysmë i krijuar që askush nuk e pastron.

Katër pronarë, dhe skripti nuk është asnjë prej tyre

Merrini me radhë. IPsec vendos dhe mirëmban rrugën e mbrojtur dhe vërteton palët. L2TP mbart sesionin mbi të, dhe kjo shtresim është arsyeja pse standardi i trajton si mekanizma të veçantë dhe jo si një protokoll. Brenda kësaj, PPP negocion parametrat e lidhjes që klienti do të përdorë. Më pas Android zotëron anën e platformës: ndërfaqen VPN të regjistruar, shtrirjen për aplikacion, gjendjen always-on dhe ciklin e jetës që vendos çfarë ndodh kur aplikacioni vritet.

Një skript mund të shohë vetëm shtresën e fundit, dhe zakonisht tërthorazi. Mund t'i kërkojë një klienti të lidhet nëse ai klient ekspozon një kontroll të dokumentuar, dhe më pas mund të vëzhgojë gjendjen e ndërfaqes. Nuk mund të zëvendësojë tre shtresat poshtë, dhe nuk mund ta bëjë platformën të trajtojë një ndërfaqe të paregjistruar si VPN.

Pse as një daemon nuk është shkurtore

Nisja e një daemon Linux të privilegjuar në pajisje duket si pjesa që mungon, dhe shpesh vërtet ngre një tunel. Ajo që nuk bën është regjistrimi i atij tuneli në Android. Ndërfaqja ekziston brenda kernelit, por përzgjedhja VPN e platformës, rrugëtimi për aplikacion, politika always-on dhe cikli i jetës nuk e dinë atë, dhe ndryshimet e veta të rrugës dhe DNS të daemon-it konkurrojnë me menaxherin e rrjetit për të njëjtat tabela.

Rezultati është një lidhje që funksionon për trafikun e daemon-it dhe në mënyrë misterioze jo për aplikacionin që ju interesonte, ose një që mbijeton derisa sistemi të rivlerësojë rrjetet e tij. Asnjëri prej rezultateve nuk është bug i platformës; është kufiri midis zotërimit të një socket dhe zotërimit të facilitetit VPN.

Si duken rrugët e mbështetura

Nëse organizata mund të kalojë në një profil që vetë Android e siguron, rruga e platformës është e ndershme. Nga API 30, VpnManager mbështet sigurimin dhe kontrollin e profileve VPN të platformës nga aplikacionet, me një rrjedhë autorizimi të lidhur me aplikacionin që thërret. Nuk është konvertues L2TP: modeli i profilit që siguron për IKEv2 nuk përkthen një konfigurim ekzistues L2TP, dhe ndryshimi i protokollit është migrim, jo riemërtim. Identitetet, rrugët, DNS privat dhe lejet e qasjes duhet të transferohen me qëllim.

Nëse shërbimi duhet të mbetet L2TP/IPsec, kombinimi i mbështetur është një klient dhe një version OS që operatori vërtet e dokumenton, dhe kontrata e tij e automatizimit nëse ekziston. Kur nuk ka një kontroll të dokumentuar pa mbikëqyrje, përgjigjja e saktë është një lidhje manuale e mbështetur, jo një skript i privilegjuar i brishtë që ndodh të funksionojë në një ndërtim.

Çfarë bën një automatizim i saktë

Me një kontroll të dokumentuar, automatizimi ka një punë të vogël dhe të mbrojtshme: kërko lidhjen e emërtuar, prit gatishmërinë, ndal në dështim vërtetimi ose konfigurimi, ekzekuto ngarkesën e synuar dhe lëre pastrimin te komponenti që zotëron lidhjen. Kredencialet mbeten te klienti që di t'i ruajë dhe t'i rrotullojë ato.

Shkruani cili komponent zotëron çdo shtresë përpara se të shkruani rreshtin e parë, dhe kontrolloni rezultatin kundrejt kësaj:

• IPsec dhe PPP trajtohen nga klienti, jo nga rrugët e skriptit.
• Lidhja shfaqet në gjendjen VPN të platformës, prandaj shtrirja për aplikacion dhe always-on zbatohen për të.
• Asnjë thirrje e brendshme shërbimi, numër transaksioni ose argument i hamendësuar nuk mbart një kredencial.
• Një dështim në çdo hap nuk lë pas një profil gjysmë të regjistruar.