Automasi L2TP pada Android: skrip boleh meminta, bukan membinanya

Mitonya ialah L2TP pada Android ialah satu lagi perkara yang boleh dimulakan oleh skrip shell: tambah laluan, panggil perkhidmatan lama, selesai. Itu tidak boleh berlaku, kerana empat lapisan berbeza perlu bersetuju sebelum terowong membawa paket. Lapisan IPsec melindungi laluan, L2TP membawa sesi, PPP merundingkan pautan, dan Android mesti mendaftarkan hasilnya sebagai VPN yang boleh ia laluan. Saya pernah melihat ini dicuba dua kali dengan arahan yang disalin, dan kedua-dua kali laluan itu wujud sementara tiada apa yang disulitkan.

Apa yang sebenarnya dicapai oleh perubahan laluan

Menambah laluan menentukan ke mana paket pergi seterusnya. Ia tidak merundingkan persatuan keselamatan, tidak membuka sesi L2TP, dan tidak menjalankan pertukaran PPP yang menghasilkan alamat, rakan sebaya dan tetapan DNS. Pada telefon, hasil yang kelihatan ialah trafik yang keluar melalui laluan yang salah, atau keluar lalu mati, tanpa keadaan terowong di mana-mana.

Perkara yang sama berlaku untuk panggilan perkhidmatan yang disalin daripada keluaran lama. Paip VPN dalaman Android bukan API automasi yang diterbitkan, dan transaksi bernombor daripada versi lain boleh mengenai operasi berbeza atau memerlukan keistimewaan yang tidak dimiliki skrip. Automasi yang membawa kata laluan tidak sepatutnya bergantung pada hujah dalaman yang diteka, kerana mod kegagalannya ialah no-op senyap atau profil separuh siap yang tiada siapa membersihkannya.

Empat pemilik, dan skrip bukan salah satu daripadanya

Ambil mereka mengikut urutan. IPsec menubuhkan dan mengekalkan laluan terlindung serta mengesahkan rakan sebaya. L2TP membawa sesi di atasnya, dan lapisan itulah sebabnya piawaian menganggap kedua-duanya sebagai mekanisme berasingan dan bukan satu protokol. Di dalamnya, PPP merundingkan parameter pautan yang akan digunakan oleh klien. Android kemudian memiliki bahagian platform: antara muka VPN berdaftar, skop setiap apl, keadaan always-on dan kitaran hayat yang menentukan apa yang berlaku apabila apl dibunuh.

Skrip hanya boleh melihat lapisan terakhir itu, dan biasanya secara tidak langsung. Ia boleh meminta klien menyambung jika klien itu mendedahkan kawalan terdokumentasi, dan ia boleh memerhati keadaan antara muka selepas itu. Ia tidak boleh menggantikan tiga lapisan di bawahnya, dan ia tidak boleh memaksa platform menganggap antara muka tidak berdaftar sebagai VPN.

Mengapa daemon juga bukan jalan pintas

Memulakan daemon Linux istimewa pada peranti kelihatan seperti bahagian yang hilang, dan selalunya ia memang menaikkan terowong. Apa yang tidak dilakukannya ialah mendaftarkan terowong itu dengan Android. Antara muka itu wujud di dalam kernel, tetapi pemilihan VPN platform, penghalaan setiap apl, dasar always-on dan kitaran hayat tidak mengetahuinya, dan perubahan laluan serta DNS daemon itu sendiri bersaing dengan pengurus rangkaian untuk jadual yang sama.

Hasilnya ialah sambungan yang berfungsi untuk trafik daemon dan secara misteri tidak untuk apl yang anda pedulikan, atau satu yang bertahan sehingga sistem menilai semula rangkaiannya. Tiada satu pun hasil itu pepijat platform; ia adalah sempadan antara memiliki soket dan memiliki kemudahan VPN.

Rupa laluan yang disokong

Jika organisasi boleh beralih kepada profil yang disediakan oleh Android sendiri, laluan platform ialah yang jujur. Sejak API 30, VpnManager menyokong penyediaan dan kawalan profil VPN platform oleh apl, dengan aliran kebenaran yang dilampirkan pada apl pemanggil. Ia bukan penukar L2TP: model profil yang disediakannya untuk IKEv2 tidak menterjemah konfigurasi L2TP sedia ada, dan menukar protokol ialah migrasi, bukan penamaan semula. Identiti, laluan, DNS peribadi dan kebenaran akses mesti dipindahkan dengan sengaja.

Jika perkhidmatan mesti kekal L2TP/IPsec, gabungan yang disokong ialah klien dan keluaran OS yang benar-benar didokumenkan oleh pengendali, dan kontrak automasinya jika ada. Apabila tiada kawalan tanpa pengawasan yang didokumenkan, jawapan yang betul ialah sambungan manual yang disokong, bukan skrip istimewa rapuh yang kebetulan berfungsi pada satu binaan.

Apa yang dilakukan oleh automasi yang betul

Dengan kawalan yang didokumenkan, automasi mempunyai tugas kecil dan boleh dipertahankan: minta sambungan bernama, tunggu kesediaan, berhenti pada kegagalan pengesahan atau persediaan, jalankan beban kerja yang dimaksudkan, dan serahkan pembersihan kepada komponen yang memiliki sambungan. Kelayakan kekal dengan klien yang tahu menyimpannya dan memutarkannya.

Tuliskan komponen mana yang memiliki setiap lapisan sebelum menulis baris pertama, dan semak hasilnya terhadapnya:

• IPsec dan PPP dikendalikan oleh klien, bukan laluan skrip.
• Sambungan muncul dalam keadaan VPN platform, jadi skop setiap apl dan always-on terpakai padanya.
• Tiada panggilan perkhidmatan dalaman, nombor transaksi atau hujah yang diteka membawa kelayakan.
• Kegagalan pada mana-mana langkah tidak meninggalkan profil separuh berdaftar.