OpenVPN Android tidak menambah laluan tanpa alamat terowong

Profil OpenVPN anda di Android gagal menambah laluan kerana telefon tidak mempunyai alamat pada antara muka maya, jadi tiada apa untuk laluan tujukan. Laluan hanya menjawab ke mana paket patut pergi. Alamat terowong menjawab siapa telefon di dalam terowong, dan klien mesti menyediakannya sebelum antara muka boleh wujud. Lalui empat pemeriksaan di bawah mengikut urutan dan berhenti pada kegagalan pertama, kerana menyunting laluan sebelum alamat wujud menyembunyikan masalah sebenar.

Baca kegagalan mengikut urutan klien melaksanakannya

VpnService.Builder Android memisahkan kedua-dua konsep: addAddress() meletakkan alamat pada antara muka yang sedang dibina aplikasi, addRoute() menambah awalan destinasi, dan establish() enggan mencipta antara muka sehingga sekurang-kurangnya satu alamat ditambah. Klien OpenVPN memetakan profil dan pilihan yang ditolak pelayan tepat pada panggilan itu, jadi sambungan yang tidak pernah menghurai alamat tidak boleh membina antara muka sama sekali.

Itulah sebabnya baris log yang anda baca mungkin menamakan laluan sedangkan puncanya satu langkah lebih awal. Klien hanya sampai ke peringkat laluan selepas antara muka wujud; tanpa alamat, panggilan laluan gagal serta-merta atau tidak pernah berjalan. Apabila log berkata ia tidak boleh menambah laluan, mulakan dengan alamat dan bukan dengan sintaks laluan.

Pemeriksaan 1: adakah pelayan meletakkan alamat dalam balasan?

Bagi perkhidmatan OpenVPN yang dilalukan, alamat datang daripada kumpulan pelayan atau peruntukan setiap klien, dan topologi menentukan bentuknya. Pada pelayan OpenVPN 2.4 atau lebih baharu, perkhidmatan dengan topologi subnet kelihatan seperti ini:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Dengan bentuk itu pelayan menolak sesuatu seperti ifconfig 10.8.0.6 255.255.255.0. Pemasangan topology net30 yang lebih lama menolak alamat rakan sebaya pula, contohnya ifconfig 10.8.0.6 10.8.0.5, jadi profil yang dipindahkan antara dua model itu boleh kelihatan betul sambil membawa topeng rangkaian yang salah.

Cari dalam log sambungan klien set pilihan yang ditolak. Jika ia tidak mempunyai satu pun baris ifconfig, pelayan tidak pernah menghantar alamat atau klien menolak pilihan itu. Pada pelayan yang menggunakan client-config-dir, fail yang dinamakan sempena common name pada sijil mesti wujud dan membawa peruntukan itu:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Pemeriksaan 2: adakah klien mengekalkan alamat yang diberi?

Penapis yang terlalu luas ialah punca biasa kedua. pull-filter wujud dalam OpenVPN 2.4 dan lebih baharu, dan apabila beberapa penapis sepadan dengan pilihan yang sama, yang terakhir sepadan menang, jadi catch-all di hujung membuang alamat tanpa ralat:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Sempitkan penapis kepada pilihan yang benar-benar ingin anda buang dan biarkan alamat itu:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Nasihat untuk mematikan semua pull biasanya datang daripada seseorang yang mahu menyingkirkan satu laluan sahaja. route-nopull ialah suis yang lebih sempit: ia mengekalkan ifconfig dan pilihan lain yang ditolak sambil menolak laluan yang ditolak dan pilihan gaya DHCP. Gunakannya apabila itu benar-benar yang anda mahu, dan jawab persoalan alamat secara berasingan.

Pemeriksaan 3: adakah alamat itu milik anda untuk ditaip?

Pengalamatan manual hanya sah apabila pengendali menyerahkan nilainya kepada anda. Jika anda menaipnya sendiri, ia mesti datang daripada subnet klien VPN, unik antara sesi aktif dan sepadan dengan topologi yang dijalankan pelayan. Menyalin alamat jambatan desktop atau hos di LAN jauh gagal pada kedua-dua segi: telefon akan menuntut alamat yang sudah wujud di tempat lain, dan get laluan tidak akan mempunyai laluan balik ke sana.

Awalan LAN jauh dalam laluan ialah destinasi, bukan identiti telefon. Laluan untuk 10.60.0.0/24 bermaksud capai rangkaian itu melalui terowong; ia tidak menyatakan alamat 10.60.0.x mana yang perlu dipegang telefon, dan telefon tidak sepatutnya memegang mana-mana daripadanya. Peruntukan statik tergolong di sebelah pelayan, tempat ia tidak boleh berlanggar dengan kumpulan dinamik.

Dua sesi pada satu identiti mendedahkan perlanggaran yang sama. Jika sijil yang sama bersambung dua kali dan pelayan menolak satu alamat tetap kepada kedua-duanya, sesi kedua menduplikasi yang pertama, dan penyelesaiannya ialah identiti berasingan atau peruntukan berasingan, bukan suntingan di sebelah klien.

Pemeriksaan 4: adakah sesuatu yang lain memegang slot terowong?

Android hanya membenarkan satu perkhidmatan VPN aktif pada satu masa. Aplikasi VPN lain, atau entri VPN sentiasa-hidup yang dibiarkan dihidupkan untuk profil yang tidak lagi berfungsi, boleh mengambil slot itu sebelum klien OpenVPN anda memanggil establish(). Antara muka kemudian tidak pernah muncul walaupun profil itu sah, jadi putuskan VPN yang lain, matikan tetapan sentiasa-hidup dan sambung semula sebelum menyentuh profil.

Perkhidmatan yang berkeras pada jambatan Ethernet ialah jalan buntu yang lain. Aplikasi Android tanpa root boleh mencipta terowong IP, bukan segmen Ethernet terjambat, jadi tiada alamat yang anda taip akan membuat pelayan dev tap berfungsi; pengendali mesti menawarkan perkhidmatan yang dilalukan. Apabila melaporkan masalah, sertakan nama dan versi klien, set pilihan yang ditolak, topologi dan langkah tepat tempat alamat sepatutnya muncul.

Jika keempat-empat pemeriksaan lulus dan alamat itu ada, unik dan bertopeng dengan betul, persoalan laluan menjadi yang biasa: awalan mana yang dibenarkan pelayan dan bagaimana klien harus mengehadkannya. Catat alamat terowong, topeng rangkaiannya dan topologi sebelum mengubah apa-apa lagi, kerana tiga nilai itulah yang pengendali perlu bandingkan dengan pandangan pelayan.