Otomatisasi L2TP di Android: skrip bisa meminta, bukan membangunnya

Mitonya adalah bahwa L2TP di Android adalah satu hal lagi yang bisa dijalankan skrip shell: tambahkan rute, panggil layanan lama, selesai. Itu tidak mungkin, karena empat lapisan berbeda harus sepakat sebelum terowongan membawa paket. Lapisan IPsec melindungi jalur, L2TP membawa sesi, PPP menegosiasikan tautan, dan Android harus mendaftarkan hasilnya sebagai VPN yang bisa ia rutekan. Saya sudah melihat ini dicoba dua kali dengan perintah yang disalin, dan kedua kali rutenya ada sementara tidak ada yang terenkripsi.

Apa yang sebenarnya dicapai oleh perubahan rute

Menambahkan rute menentukan ke mana paket pergi berikutnya. Itu tidak menegosiasikan asosiasi keamanan, tidak membuka sesi L2TP, dan tidak menjalankan pertukaran PPP yang menghasilkan alamat, peer, dan pengaturan DNS. Di ponsel, hasil yang terlihat adalah lalu lintas yang keluar lewat jalur yang salah, atau keluar lalu mati, tanpa status terowongan di mana pun.

Hal yang sama berlaku untuk panggilan layanan yang disalin dari rilis lama. Perpipaan VPN internal Android bukan API otomatisasi yang dipublikasikan, dan transaksi bernomor dari versi lain bisa mengenai operasi yang berbeda atau menuntut hak istimewa yang tidak dimiliki skrip. Otomatisasi yang membawa kata sandi tidak boleh bergantung pada argumen internal yang ditebak, karena mode kegagalannya adalah no-op senyap atau profil setengah jadi yang tidak dibersihkan siapa pun.

Empat pemilik, dan skrip bukan salah satunya

Ambil berurutan. IPsec membangun dan memelihara jalur yang dilindungi serta mengautentikasi peer. L2TP membawa sesi di atasnya, dan pelapisan itulah sebabnya standar memperlakukan keduanya sebagai mekanisme terpisah, bukan satu protokol. Di dalamnya, PPP menegosiasikan parameter tautan yang akan dipakai klien. Android lalu memiliki sisi platform: antarmuka VPN terdaftar, cakupan per aplikasi, status always-on, dan siklus hidup yang menentukan apa yang terjadi saat aplikasi dimatikan.

Skrip hanya bisa melihat lapisan terakhir itu, dan biasanya secara tidak langsung. Ia bisa meminta klien untuk terhubung jika klien tersebut mengekspos kontrol yang terdokumentasi, dan ia bisa memantau status antarmuka setelahnya. Ia tidak bisa menggantikan tiga lapisan di bawahnya, dan tidak bisa membuat platform memperlakukan antarmuka yang tidak terdaftar sebagai VPN.

Mengapa daemon juga bukan jalan pintas

Menjalankan daemon Linux dengan hak istimewa di perangkat tampak seperti bagian yang hilang, dan sering kali memang menyalakan terowongan. Yang tidak dilakukannya adalah mendaftarkan terowongan itu ke Android. Antarmuka itu ada di dalam kernel, tetapi pemilihan VPN platform, perutean per aplikasi, kebijakan always-on, dan siklus hidup tidak mengetahuinya, dan perubahan rute serta DNS dari daemon itu sendiri bersaing dengan manajer jaringan untuk tabel yang sama.

Hasilnya adalah koneksi yang berfungsi untuk lalu lintas daemon dan secara misterius tidak untuk aplikasi yang Anda pedulikan, atau koneksi yang bertahan sampai sistem mengevaluasi ulang jaringannya. Tidak ada hasil yang merupakan bug platform; ini adalah batas antara memiliki socket dan memiliki fasilitas VPN.

Seperti apa rute yang didukung

Jika organisasi bisa pindah ke profil yang disediakan Android sendiri, jalur platform adalah yang jujur. Sejak API 30, VpnManager mendukung penyediaan dan pengendalian profil VPN platform oleh aplikasi, dengan alur otorisasi yang melekat pada aplikasi pemanggil. Ini bukan konverter L2TP: model profil yang disediakannya untuk IKEv2 tidak menerjemahkan konfigurasi L2TP yang ada, dan berpindah protokol adalah migrasi, bukan penggantian nama. Identitas, rute, DNS privat, dan izin akses harus dipindahkan dengan sengaja.

Jika layanan harus tetap L2TP/IPsec, kombinasi yang didukung adalah klien dan rilis OS yang benar-benar didokumentasikan operator, serta kontrak otomatisasinya jika ada. Ketika tidak ada kontrol tanpa pengawasan yang terdokumentasi, jawaban yang benar adalah koneksi manual yang didukung, bukan skrip berhak istimewa yang rapuh yang kebetulan berfungsi pada satu build.

Apa yang dilakukan otomatisasi yang benar

Dengan kontrol yang terdokumentasi, otomatisasi punya pekerjaan kecil yang bisa dipertahankan: minta koneksi yang disebut namanya, tunggu kesiapan, berhenti saat autentikasi atau penyetelan gagal, jalankan beban kerja yang dimaksud, dan serahkan pembersihan ke komponen yang memiliki koneksi. Kredensial tetap bersama klien yang tahu cara menyimpannya dan merotasinya.

Tuliskan komponen mana yang memiliki tiap lapisan sebelum menulis baris pertama, dan periksa hasilnya terhadap itu:

• IPsec dan PPP ditangani klien, bukan rute skrip.
• Koneksi muncul di status VPN platform, jadi cakupan per aplikasi dan always-on berlaku padanya.
• Tidak ada panggilan layanan internal, nomor transaksi, atau argumen tebakan yang membawa kredensial.
• Kegagalan di langkah mana pun tidak meninggalkan profil setengah terdaftar.