Penghalaan VPN Android: peraturan dasar sebelum jadual main

Laluan yang ditambah pada jadual main di Android kelihatan betul dalam setiap senarai dan tetap tidak membawa trafik. Sebabnya ialah jadual main hanyalah satu pilihan antara beberapa, dan ia tidak ditanya dahulu. Perkhidmatan rangkaian Android membina peraturan dasar yang memilih jadual penghalaan menggunakan maklumat yang tidak terkandung dalam alamat destinasi — uid aplikasi, tanda pada paket, antara muka tempat ia tiba — dan carian destinasi berlaku selepas itu, di dalam jadual yang dipilih oleh peraturan tersebut.

Tiga keputusan dalam susunan tetap

Paket yang keluar membuat tiga keputusan berasingan. Pertama, peraturan dasar menentukan jadual penghalaan mana yang terpakai. Kedua, laluan dalam jadual itu menentukan hop seterusnya dan antara muka keluar. Ketiga, cangkuk netfilter menentukan sama ada paket itu bertahan, diubah suai atau dialihkan.

Susunan penting kerana setiap peringkat hanya boleh menjawab soalnya sendiri. Peraturan firewall yang menerima paket tidak memilih jadual, dan laluan yang ditambah pada jadual yang tidak dipilih oleh mana-mana peraturan tidak berkesan. Banyak kekeliruan tentang VPN Android datang daripada membaiki salah satu daripada tiga itu dan tidak melihat sebarang perubahan, kerana kerosakan ada pada yang lain.

Tanda ialah medan berbungkus, bukan label milik anda

Android membungkus beberapa fakta dalam nilai tanda yang sama: rangkaian mana yang dipilih, sama ada aplikasi memilih rangkaian secara jelas, sama ada soket dilindungi daripada VPN, dan bit berkaitan kebenaran. Pengepala fwmark AOSP mentakrifkan susun atur itu untuk pokok semasa, dan susun atur itu ialah perkara dalaman platform yang berubah antara keluaran.

Itulah sebabnya menulis nilai tanda penuh dengan iptables -j MARK --set-mark berbahaya di Android. Ia tidak menambah teg; ia menggantikan pemilihan rangkaian yang sudah dibuat oleh sistem. Paket itu kemudian sepadan dengan peraturan berbeza, yang boleh kelihatan seolah-olah VPN mula berfungsi, atau seolah-olah aplikasi tidak berkaitan kehilangan sambungan, bergantung pada bit yang ditulis ganti.

Jika anda perlu menyentuh tanda, baca nilai semasa dahulu dan gunakan topeng supaya hanya bit yang anda fahami diubah suai:

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

Tanda sambungan ialah objek berasingan daripada tanda paket, dan kedua-duanya bukan laluan. Memulihkan tanda pada paket balasan ialah langkah berasingan daripada memilih jadual semasa keluar, itulah sebabnya pembaikan sehala menghasilkan sambungan yang terbuka dan kemudian tergantung.

Siapa yang memiliki peraturan dan jadual

Perkhidmatan rangkaian Android, netd, mencipta peraturan dan jadual bagi setiap rangkaian. AOSP RouteController ialah tempat peraturan itu dipasang untuk VPN, rangkaian fizikal dan julat uid, dan kitaran hayatnya terikat pada peristiwa rangkaian dan bukan pada fail konfigurasi.

Dua akibat menyusul. Pertama, keutamaan dan nombor jadual yang anda temui pada satu peranti ialah butiran dalaman binaan, bukan antara muka: nombor yang kelihatan sama pada versi Android lain mungkin bermaksud sesuatu yang sama sekali berbeza. Kedua, keadaan dibina semula apabila rangkaian berubah, jadi peraturan yang dimasukkan hari ini daripada shell root mungkin hilang selepas peralihan Wi-Fi seterusnya.

Kehilangan itu sering dilaporkan sebagai sistem mengabaikan laluan. Apa yang sebenarnya berlaku ialah peraturan yang memilih jadual itu tidak lagi wujud, dan laluan di dalam jadual kini tidak dapat dicapai dari sudut pandangan paket. Semak senarai peraturan, bukan senarai laluan, apabila konfigurasi yang berfungsi berhenti berfungsi selepas sambungan semula.

Soalan tentang susunan cangkuk tiada jawapan sejagat

Soalan sama ada iptables berjalan sebelum penghalaan VPN tidak boleh dijawab tanpa menamakan laluan paket. Paket yang dijana secara setempat melalui cangkuk output, di mana perubahan tanda mencetuskan semakan penghalaan semula — carian kedua, bukan suntingan retroaktif pada yang pertama. Paket yang tiba daripada klien tether melalui laluan prerouting dan diteruskan sebaliknya, dan rantaian yang melihatnya berbeza.

Jadi peraturan yang sama boleh berkesan untuk trafik aplikasi dan tidak kelihatan kepada trafik tether, dan pembilang yang kekal pada sifar memberitahu anda laluan mana yang diambil oleh paket, bukan sama ada peraturan itu salah. Gunakan pembilang untuk menetapkan laluan sebelum menukar sebarang syarat padanan.

Ini juga peringkat apabila kesilapan penghalaan dasar menjadi sukar dilihat. Penghalaan ke jadual yang wujud tetapi tidak mengandungi destinasi menghasilkan rangkaian tidak dapat dicapai yang kelihatan seperti penolakan firewall, manakala penolakan firewall menghasilkan tamat masa yang kelihatan seperti lubang hitam penghalaan.

Diagnosis di dalam sistem, atau biarkan sahaja

Untuk semakan yang dibenarkan, tetapkan empat fakta sebelum menyentuh apa-apa: uid dan profil aplikasi, rangkaian yang dipilih Android untuknya, sama ada VPN menyertakan aplikasi itu sama sekali, dan sama ada masalah itu wujud untuk kedua-dua keluarga alamat. Pengecualian setiap aplikasi menjelaskan banyak laporan VPN tidak berfungsi tanpa sebarang kerosakan penghalaan.

Kemudian baca peraturan, topeng dan jadual yang benar-benar berkuat kuasa, dan kekalkan peralihan rangkaian dalam tetingkap pemerhatian. Jika tingkah laku berubah sepanjang sambungan semula, anda sedang melihat kitaran hayat terurus, bukan laluan yang hilang.

Untuk keperluan biasa, gunakan kawalan yang disokong: penyertaan dan pengecualian setiap aplikasi dalam aplikasi VPN, dan pemilihan rangkaian platform itu sendiri untuk apa-apa yang memerlukan laluan tertentu. Jika integrasi istimewa benar-benar perlu bekerjasama dengan jentera penghalaan, sasarkan pelaksanaan versi Android yang tepat yang anda sokong dan kekalkan kitaran hayatnya melalui komponen yang memilikinya. Membilas rantaian platform atau memasukkan peraturan keutamaan tinggi mengubah diagnosis menjadi pengurus rangkaian kedua, dan telefon akan berkelakuan sewajarnya.