Perutean VPN Android: aturan kebijakan sebelum tabel main

Rute yang ditambahkan ke tabel main di Android terlihat benar di setiap daftar dan tetap tidak membawa lalu lintas. Alasannya adalah tabel main hanyalah salah satu opsi di antara beberapa, dan tabel itu tidak ditanyakan lebih dulu. Layanan jaringan Android membangun aturan kebijakan yang memilih tabel perutean menggunakan informasi yang tidak dimuat alamat tujuan — uid aplikasi, tanda pada paket, antarmuka tempat paket tiba — dan pencarian tujuan terjadi setelahnya, di dalam tabel yang dipilih aturan tersebut.

Tiga keputusan dalam urutan tetap

Paket yang keluar membuat tiga keputusan terpisah. Pertama, aturan kebijakan menentukan tabel perutean mana yang berlaku. Kedua, rute di dalam tabel itu menentukan hop berikutnya dan antarmuka keluar. Ketiga, kait netfilter menentukan apakah paket bertahan, diubah, atau dialihkan.

Urutan penting karena setiap tahap hanya dapat menjawab pertanyaannya sendiri. Aturan firewall yang menerima paket tidak memilih tabel, dan rute yang ditambahkan ke tabel yang tidak dipilih aturan mana pun akan diam. Banyak kebingungan seputar VPN Android muncul karena memperbaiki salah satu dari tiga hal itu lalu tidak melihat perubahan, padahal kesalahannya ada di tahap lain.

Tanda adalah bidang terpaket, bukan label milik Anda

Android memaketkan beberapa fakta ke dalam nilai tanda yang sama: jaringan mana yang dipilih, apakah aplikasi secara eksplisit memilih jaringan, apakah socket terlindung dari VPN, dan bit yang berkaitan dengan izin. Header fwmark AOSP mendefinisikan tata letak itu untuk pohon saat ini, dan tata letak tersebut merupakan bagian internal platform yang berubah antar rilis.

Itulah sebabnya menulis nilai tanda secara utuh dengan iptables -j MARK --set-mark berbahaya di Android. Perintah itu tidak menambahkan tag; ia menggantikan pemilihan jaringan yang sudah dilakukan sistem. Paket lalu cocok dengan aturan yang berbeda, yang bisa terlihat seolah VPN mulai bekerja, atau seolah aplikasi tak terkait kehilangan konektivitas, tergantung bit mana yang ditimpa.

Jika Anda harus menyentuh tanda, baca dulu nilai saat ini dan gunakan mask agar hanya bit yang Anda pahami yang diubah:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Tanda koneksi adalah objek terpisah dari tanda paket, dan keduanya bukan rute. Memulihkan tanda pada paket balasan adalah langkah berbeda dari memilih tabel saat keluar, itulah sebabnya perbaikan satu arah menghasilkan koneksi yang terbuka lalu menggantung.

Siapa yang memiliki aturan dan tabel

Layanan jaringan Android, netd, membuat aturan dan tabel per jaringan. AOSP RouteController adalah tempat aturan itu dirakit untuk VPN, jaringan fisik, dan rentang uid, dan siklus hidupnya terikat pada peristiwa jaringan, bukan pada berkas konfigurasi.

Ada dua konsekuensi. Pertama, prioritas dan nomor tabel yang Anda temukan di satu ponsel adalah detail internal build, bukan antarmuka: nomor yang tampak sama di versi Android lain bisa berarti hal yang sama sekali berbeda. Kedua, keadaan dibangun ulang saat jaringan berubah, sehingga aturan yang dimasukkan hari ini dari shell root bisa hilang setelah peralihan Wi-Fi berikutnya.

Hilangnya itu sering dilaporkan sebagai sistem mengabaikan rute. Yang sebenarnya terjadi adalah aturan yang memilih tabel sudah tidak ada, dan rute di dalam tabel kini tak terjangkau dari sudut pandang paket. Periksa daftar aturan, bukan daftar rute, ketika konfigurasi yang berfungsi berhenti bekerja setelah penyambungan ulang.

Pertanyaan urutan kait tidak punya jawaban universal

Pertanyaan apakah iptables berjalan sebelum perutean VPN tidak bisa dijawab tanpa menyebut jalur paket. Paket yang dibuat secara lokal melewati kait output, di mana perubahan tanda memicu pemeriksaan perutean ulang — pencarian kedua, bukan penyuntingan surut atas yang pertama. Paket yang datang dari klien tether melewati jalur prerouting dan diteruskan sebagai gantinya, dan rantai yang melihatnya berbeda.

Jadi aturan yang sama bisa efektif untuk lalu lintas aplikasi dan tak terlihat bagi lalu lintas tether, dan penghitung yang tetap nol memberi tahu Anda jalur mana yang ditempuh paket, bukan apakah aturannya salah. Gunakan penghitung untuk menetapkan jalur sebelum mengubah syarat pencocokan apa pun.

Ini juga tahap ketika kesalahan perutean kebijakan menjadi sulit dilihat. Merutekan ke tabel yang ada tetapi tidak memuat tujuan menghasilkan jaringan tak terjangkau yang tampak seperti penolakan firewall, sedangkan penolakan firewall menghasilkan batas waktu yang tampak seperti lubang hitam perutean.

Diagnosis di dalam sistem, atau biarkan saja

Untuk tinjauan yang diizinkan, tetapkan empat fakta sebelum menyentuh apa pun: uid dan profil aplikasi, jaringan yang dipilih Android untuknya, apakah VPN menyertakan aplikasi itu sama sekali, dan apakah masalahnya ada pada kedua keluarga alamat. Pengecualian per aplikasi menjelaskan sangat banyak laporan VPN tidak berfungsi tanpa kesalahan perutean apa pun.

Lalu baca aturan, mask, dan tabel yang benar-benar berlaku, dan pertahankan peralihan jaringan di dalam jendela pengamatan. Jika perilaku berubah selama penyambungan ulang, Anda sedang melihat siklus hidup terkelola, bukan rute yang hilang.

Untuk kebutuhan biasa, gunakan kontrol yang didukung: penyertaan dan pengecualian per aplikasi di aplikasi VPN, dan pemilihan jaringan milik platform untuk apa pun yang membutuhkan jalur tertentu. Jika integrasi berhak istimewa benar-benar harus bekerja sama dengan mesin perutean, targetkan implementasi versi Android persis yang Anda dukung dan pelihara siklus hidupnya melalui komponen yang memilikinya. Membilas rantai platform atau menyisipkan aturan berprioritas tinggi mengubah diagnosis menjadi manajer jaringan kedua, dan ponsel akan berperilaku sesuai itu.