Senarai benarkan Android VpnService: mengapa halaman dibenarkan masih tersekat

Anda menambah domain ke senarai benarkan, pertanyaan sampai ke aplikasi anda, pemadan mengembalikan dibenarkan, dan halaman itu tetap tidak pernah dimuatkan. Pada ketika itu kebanyakan orang mula menulis semula pemadan dan menambah perbandingan kad bebas. Berdasarkan pengalaman saya pemadan biasanya betul, dan kegagalan terletak satu lapisan lebih dalam: dalam jawapan DNS yang anda sintesiskan, dalam laluan yang anda pasang, atau dalam soket yang anda gunakan untuk meneruskan pertanyaan. Senarai ialah bahagian mudah; laluan paket ialah tempat senarai benarkan rosak.

Pemadan jarang menjadi punca

Perkara pertama yang perlu dipisahkan ialah disekat daripada rosak. Nama yang disekat harus gagal dengan cepat dan kelihatan, kerana pelayar menerima jawapan bahawa nama itu tidak wujud lalu berhenti. Nama yang rosak tersekat, mencuba semula melalui IPv6, beralih ke pengangkutan lain, dan meninggalkan anda dengan penunjuk berputar. Jika anda melihat penunjuk berputar, senarai benarkan anda mungkin menjawab sesuatu yang tidak dapat ditangani oleh klien.

Rekod A kosong ialah kesilapan klasik. Mengembalikan NOERROR dengan sifar jawapan kelihatan seperti jawapan sah, jadi penyelesai stub menerimanya, pelayar mencuba semula, mencuba AAAA, mencuba penyelesai lain dan menyerah jauh kemudian. Kod jawapan 3, iaitu NXDOMAIN, dengan bahagian soalan diulang dan ID transaksi disalin, menamatkan perbualan serta-merta. Gunakannya untuk setiap nama yang anda tolak dengan sengaja.

IPv6 juga wajar mendapat keputusan yang sama dan bukan nilai lalai. Jika anda menjawab NXDOMAIN untuk A dan membenarkan AAAA melalui, klien boleh mencapai nama yang disekat melalui IPv6 dan penapis bocor. Sesetengah pelaksanaan menjawab pertanyaan AAAA yang disekat dengan alamat loopback supaya sambungan gagal serta-merta dan bukannya beralih ke laluan sandaran. Pilih satu dasar, gunakannya pada kedua-dua jenis rekod, dan log kedua-duanya.

Laluan yang menangkap segala-galanya memiliki segala-galanya

Reka bentuk DNS sahaja tidak pernah menambah addRoute("0.0.0.0", 0), jadi hanya pertanyaan masuk ke antara muka TUN dan segala-galanya terus menggunakan rangkaian di bawahnya. Itulah bentuk yang selamat, dan ia juga menjelaskan mengapa sesetengah senarai benarkan kelihatan berfungsi pada Wi-Fi dan gagal pada rangkaian selular.

Detik laluan lalai wujud, setiap aliran menjadi milik anda. Paket TCP yang tiba di antara muka dan tidak diteruskan mahupun dijawab akan duduk dalam baris gilir sehingga klien kehabisan masa, dan tiada ralat untuk dilog kerana tiada apa yang gagal. Saya pernah melihat seseorang menghabiskan sebelah petang pada senarai benarkan yang rosak yang sebenarnya hanyalah penerus yang hilang untuk port 443. Log protokol dan destinasi setiap paket yang anda putuskan untuk digugurkan.

Soket penyelesai mesti keluar dari terowong

Penerusan ialah tempat perangkap seterusnya. Penyelesai pembawa selalunya berada pada alamat persendirian yang tidak dapat dicapai oleh terowong, jadi pertanyaan yang anda teruskan tidak ke mana-mana dan aplikasi melaporkan tamat masa bacaan. Hantar pertanyaan yang diluluskan kepada penyelesai yang anda tahu boleh dicapai, dan berikan soket itu dahulu kepada VpnService.protect(). Soket yang tidak dilindungi menghantar pertanyaan kembali ke terowong anda sendiri, di mana ia tiba lagi di aplikasi dan berputar sehingga tamat masa tercetus.

Kegagalan kelihatan sama seperti gangguan rangkaian, dan itulah sebabnya ia bertahan begitu lama dalam laporan pepijat. Simpan pembilang untuk pertanyaan dihantar dan jawapan diterima: jika nombor pertama naik dan yang kedua kekal sifar, anda sedang melihat soket, bukan senarai.

Saiz dan checksum gagal tanpa mesej

Penyingkiran senyap juga datang daripada saiz. Jawapan DNS dengan set jawapan besar, atau jabat tangan TCP dengan pilihan yang banyak, boleh melebihi MTU laluan yang tidak pernah anda tetapkan secara jelas; serpihan itu hilang di hulu dan klien sama ada mencuba semula dengan lebih kecil atau berhenti mencuba. Menetapkan MTU antara muka kepada 1280 ialah pilihan konservatif yang bertahan pada kebanyakan laluan selular, dan bersikap jelas lebih baik daripada mewarisi nilai lalai yang tidak diukur oleh sesiapa.

Jika anda membina paket sendiri, checksum ialah pembunuh senyap yang seterusnya. Checksum UDP yang dikira pada pseudotajuk yang meninggalkan panjang UDP atau medan protokol menghasilkan paket yang kelihatan terbentuk baik di pihak anda dan dibuang oleh penerima tanpa jejak. Bandingkan pseudotajuk anda dengan spesifikasi medan demi medan, dan cetak checksum yang dikira untuk satu aliran yang diketahui semasa anda menyahpepijat.

Apa yang VpnService tidak akan lakukan untuk anda

Dua had wajar diketahui sebelum anda mereka bentuk mengelilinginya. Tiada aplikasi biasa boleh memasang proksi seluruh sistem atau fail PAC di luar Wi-Fi, dan bahagian itu tidak berubah. Laluan setiap aplikasi telah berubah: sebelum API 29, VpnService.Builder tidak boleh membawa proksi langsung, dan sejak API 29 setHttpProxy(ProxyInfo.buildPacProxy(uri)) menyerahkan skrip PAC kepada platform untuk dinilai bagi rangkaian VPN. Nilai peraturan dalam kod anda sendiri apabila menyasarkan API lebih lama atau apabila model PAC tidak dapat menyatakan peraturan itu. UDP juga bukan percuma: pelayar hanya menghantar TCP melalui proksi SOCKS, dan kebanyakan klien SOCKS5 tidak pernah melaksanakan UDP ASSOCIATE, jadi reka bentuk berasaskan proksi menggugurkan atau membocorkan UDP sementara TCP kelihatan sihat.

Had kedua itulah sebabnya protokol berasaskan UDP boleh berfungsi pada rangkaian biasa dan gagal pada detik VPN anda bersambung. Jika terowong dijangka membawa UDP, penerus mesti melaksanakan laluan penerusan untuknya, bukan hanya laluan TCP dengan jenis soket yang berbeza.

Semak dalam urutan ini

Lakukan senarai mengikut urutan dan berhenti pada peringkat pertama yang gagal, kerana setiap semakan seterusnya hanya bunyi bising sehingga yang sebelumnya bertahan.

1. Senaraikan laluan yang dipasang dan sahkan sama ada paket bukan DNS masuk ke antara muka TUN sama sekali.
2. Log nama pertanyaan, keputusan dan kod jawapan untuk satu nama disekat dan satu nama diluluskan.
3. Sahkan soket penyelesai dilindungi dan penyelesai yang dipilih menjawab dari dalam terowong.
4. Sahkan MTU antara muka dan checksum satu jawapan yang anda bina sendiri.
5. Ulang halaman yang sama pada Wi-Fi dan rangkaian selular, kerana penyelesai pembawa dan MTU laluan berbeza.

Jika kelima-limanya bertahan dan halaman masih tersekat, suspek seterusnya ialah penerus itu sendiri: bandingkan permintaan yang ditangkap dengan jawapan yang ditangkap dan cari kiraan bait yang hilang atau soket separuh tertutup. Rujukan VpnService.Builder meliputi kontrak laluan, DNS dan MTU, dan protect() ialah panggilan VpnService berasingan dan bukan pilihan builder; antara muka bersambung hanya bermakna kontrak pertama dipenuhi.