Android always-on VPN: cara nama titik akhir diselesaikan dahulu

Telefon dimulakan semula, always-on dihidupkan, «sekat sambungan tanpa VPN» dihidupkan, tetapi terowong tidak pernah muncul. Tiada apa yang salah dikonfigurasikan: sekatan menjalankan tugasnya, dan percubaan klien itu sendiri untuk mencapai titik akhirnya juga tertakluk kepadanya. Nama titik akhir mesti diselesaikan sebelum terowong wujud, oleh klien yang dibenarkan bercakap dengan rangkaian sementara semua aplikasi lain tidak. Memahami komponen mana yang melakukannya, dan dalam urutan apa, itulah yang menukar teka-teki ini menjadi persoalan konfigurasi.

Apa yang sebenarnya diminta pembina VPN

Aplikasi VPN Android tidak menyerahkan alamat pelayan kepada platform. Ia membina antara muka setempat: alamat dan laluan untuk terowong, penyelesai yang perlu digunakan aplikasi di dalamnya, kemudian establish() memulangkan deskriptor fail yang dibaca dan ditulis aplikasi sebagai paket IP mentah. Titik akhir jauh tidak pernah muncul dalam pembina itu.

Itulah fakta struktur yang utama. Platform mencipta antara muka tun dan menguatkuasakan dasar padanya; aplikasi melaksanakan pengangkutan dalam ruang pengguna, bermakna aplikasi itu sendiri menyelesaikan nama titik akhirnya dan membuka sambungan yang disulitkan. Oleh itu titik akhir berbentuk nama hos adalah mungkin — bukan kerana platform menyokong nama, tetapi kerana platform tidak pernah melihat titik akhir.

Satu medan pembina memang menerima alamat: pelayan DNS. Ia mesti alamat penyelesai berangka, biasanya yang operator mahu ditanya melalui terowong. Medan itu menerangkan ke mana aplikasi menghantar pertanyaan selepas terowong naik. Ia tidak menyatakan apa-apa tentang cara klien menemui titik akhir, dan memperlakukan kedua-duanya sebagai tetapan yang sama ialah permulaan kekeliruan.

Dua soalan DNS, bukan satu

Soalan pertama: ke mana aplikasi menghantar pertanyaan apabila terowong sudah naik? Jawapannya ialah alamat penyelesai di dalam terowong, boleh dicapai melalui antara muka tun, dan bersifat berangka dari segi pembinaannya.

Soalan kedua: bagaimana klien menemui titik akhirnya sendiri sebelum terowong itu wujud? Carian itu berlaku di luar terowong, pada rangkaian asas, dalam proses klien. Ia boleh menggunakan nama, dan ia mesti menggunakan penyelesai yang boleh dicapai peranti tanpa VPN.

Tiga peringkat, tiga simptom berbeza. Satu mesej ralat yang berkata «tidak dapat menyambung» menggabungkan semuanya, itulah sebabnya orang mula menyunting medan pelayan DNS untuk membaiki masalah yang berlaku sebelum medan itu pernah dirujuk.

Mengapa bootstrap boleh tersekat

Always-on dengan sekatan dihidupkan bermakna trafik yang tidak berada di dalam VPN digugurkan, termasuk trafik daripada aplikasi yang memiliki VPN. Jalan keluar adalah jelas: aplikasi memanggil protect() pada soket, yang mengikatnya kepada rangkaian asas supaya ia memintas terowong dan dibenarkan keluar. Setiap klien VPN mesti melakukannya untuk pengangkutannya sendiri, atau ia tidak akan pernah mencapai pelayan.

Sekarang pertimbangkan penggunaan di mana satu-satunya penyelesai yang mengetahui nama titik akhir terletak di dalam terowong. Klien memerlukan terowong untuk menyelesaikan nama, dan nama untuk membina terowong. Itu kebergantungan bulat yang sebenar, dan tiada konfigurasi klien dapat menyelesaikannya. Itu kesilapan reka bentuk, bukan pepijat.

Masa mendedahkan kebergantungan yang sama dalam bentuk yang lebih ringan. Semasa but sebelum buka kunci pertama, peranti mungkin belum mempunyai rangkaian yang boleh digunakan; pada captive portal, rangkaian wujud tetapi menyekat segala-galanya kecuali portal; semasa peralihan Wi-Fi ke selular, rangkaian asas soket terlindung berubah dan klien mesti menyedarinya lalu menyelesaikan semula. Setiap satu daripadanya ialah peristiwa bootstrap, dan setiap satunya wajar diuji dengan sengaja daripada ditemui pada pukul 3 pagi.

Mengapa menyematkan jawapan bukan penyelesaian

Jalan pintas yang menggoda ialah menyelesaikan nama sekali lalu menampal alamat yang terhasil ke dalam medan berangka, atau mengekodkannya secara keras dalam binaan tersuai. Ia kelihatan berfungsi, dan ia menukar nama menjadi potret. Apabila operator memindahkan titik akhir — penghijrahan, perubahan anycast, alamat serantau baharu — klien terus mendail yang lama dan tiada apa dalam UI menjelaskan mengapa.

Rekod DNS membawa masa hidup semata-mata supaya jawapan boleh berubah; caching ditakrifkan mengikut jangka hayat itu, bukan selamanya. Menyematkan jawapan membuang mekanisme yang menjadikan nama lebih baik daripada alamat, sambil mengekalkan kos operasi kerana telah menggunakan nama.

Penyematan juga cenderung bergerak bersama tabiat buruk kedua: melonggarkan pemeriksaan identiti kerana sambungan kini gagal secara berbeza. Pengesahan identiti pelayan bukan sebahagian daripada masalah bootstrap, dan melemahkannya menukar kesulitan DNS dengan risiko pemintasan.

Reka bentuk yang bertahan selepas but semula

Susunan yang tahan lama memang tidak menarik. Gunakan klien yang melaksanakan soket terlindung dengan betul dan menyelesaikan titik akhirnya pada rangkaian asas, dan berikannya nama titik akhir yang diselesaikan secara awam, atau melalui penyelesai yang boleh dicapai sebelum terowong. Biarkan sekatan dihidupkan; mematikannya sepenuhnya supaya DNS berfungsi menghapuskan sifat yang menjadi sebab penggunaan itu wujud.

Di tempat titik akhir mesti kekal peribadi, sediakan laluan bootstrap yang jelas yang boleh digunakan platform — penyelesai yang boleh dicapai tanpa terowong, atau sambungan pengurusan yang diselenggara operator — dan kekalkan pengecualian itu sempit serta dimiliki oleh dasar, bukan oleh togol pengguna. Dokumentasi Android VpnService ialah rujukan tentang apa yang dijamin platform berkenaan perlindungan dan kitaran hayat, dan rujukan VpnService.Builder mengesahkan bahawa medan DNS menerima alamat berangka.

Kemudian sahkan ketiga-tiga peringkat, mengikut urutan, pada sambungan baharu selepas but semula: nama titik akhir diselesaikan, terowong terbentuk dan rakan sebaya disahkan, dan nama peribadi diselesaikan melalui penyelesai terowong. Jika peringkat pertama gagal, tiada apa selepasnya boleh berfungsi, dan pembaikan terletak pada laluan bootstrap — tidak pernah pada medan penyelesai.

• Penyelesaian titik akhir berlaku dalam aplikasi, di luar terowong, pada soket terlindung.
• Medan DNS dalam pembina adalah untuk aplikasi di dalam terowong, bukan untuk titik akhir klien sendiri.
• Penyelesai yang hanya boleh dicapai melalui terowong ialah kebuntuan, bukan permulaan perlahan.
• Uji titik akhir, pengesahan dan carian peribadi secara berasingan selepas but semula.