OpenVPN Android tidak menambahkan rute tanpa alamat tunnel

Profil OpenVPN Anda di Android gagal menambahkan rute karena ponsel tidak memiliki alamat pada antarmuka virtual, sehingga tidak ada yang bisa ditunjuk oleh rute. Rute hanya menjawab ke mana paket harus pergi. Alamat tunnel menjawab siapa ponsel di dalam tunnel, dan klien harus menyediakannya sebelum antarmuka dapat ada. Jalankan empat pemeriksaan di bawah ini secara berurutan dan berhenti pada kegagalan pertama, karena mengedit rute sebelum alamat ada menyembunyikan masalah sebenarnya.

Baca kegagalan sesuai urutan yang dijalankan klien

VpnService.Builder Android memisahkan kedua konsep: addAddress() menaruh alamat pada antarmuka yang sedang dibangun aplikasi, addRoute() menambahkan prefiks tujuan, dan establish() menolak membuat antarmuka sampai setidaknya satu alamat ditambahkan. Klien OpenVPN memetakan profil dan opsi yang dikirim server tepat ke panggilan itu, jadi koneksi yang tidak pernah mengurai alamat sama sekali tidak dapat membangun antarmuka.

Itulah sebabnya baris log yang Anda baca bisa menyebut rute padahal penyebabnya satu langkah lebih awal. Klien baru mencapai tahap rute setelah antarmuka ada; tanpa alamat, panggilan rute langsung gagal atau tidak pernah berjalan. Saat log mengatakan tidak dapat menambahkan rute, mulailah dari alamat, bukan dari sintaks rute.

Pemeriksaan 1: apakah server menaruh alamat dalam balasan?

Untuk layanan OpenVPN yang dirutekan, alamat berasal dari kumpulan server atau dari penugasan per klien, dan topologi menentukan bentuknya. Pada server OpenVPN 2.4 atau lebih baru, layanan dengan topologi subnet terlihat seperti ini:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Dengan bentuk itu server mengirim sesuatu seperti ifconfig 10.8.0.6 255.255.255.0. Pemasangan topology net30 yang lebih lama mengirim alamat peer, misalnya ifconfig 10.8.0.6 10.8.0.5, sehingga profil yang dipindahkan antara kedua model bisa tampak benar sementara membawa netmask yang salah.

Cari di log koneksi klien kumpulan opsi yang dikirim. Jika tidak ada satu pun baris ifconfig, server tidak pernah mengirim alamat atau klien menolak opsi itu. Pada server yang memakai client-config-dir, berkas yang dinamai menurut common name pada sertifikat harus ada dan memuat penugasan:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Pemeriksaan 2: apakah klien menyimpan alamat yang diberikan?

Filter yang terlalu luas adalah penyebab umum kedua. pull-filter ada di OpenVPN 2.4 dan yang lebih baru, dan bila beberapa filter cocok dengan opsi yang sama, yang terakhir cocok menang, sehingga catch-all di akhir menghapus alamat tanpa kesalahan:

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

Sempitkan filter ke opsi yang benar-benar ingin Anda hilangkan dan biarkan alamatnya:

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

Saran untuk menonaktifkan semua pull biasanya datang dari orang yang ingin menyingkirkan satu rute saja. route-nopull adalah sakelar yang lebih sempit: ia mempertahankan ifconfig dan opsi lain yang dikirim sambil menolak rute yang dikirim dan opsi bergaya DHCP. Pakailah bila memang itu yang Anda inginkan, dan jawab pertanyaan alamat secara terpisah.

Pemeriksaan 3: apakah alamat itu milik Anda untuk diketik?

Pengalamatan manual sah hanya bila operator menyerahkan nilainya kepada Anda. Jika Anda mengetiknya sendiri, alamat itu harus berasal dari subnet klien VPN, unik di antara sesi aktif dan cocok dengan topologi yang dijalankan server. Menyalin alamat jembatan desktop atau host di LAN jauh gagal pada kedua hal: ponsel akan mengklaim alamat yang sudah ada di tempat lain, dan gateway tidak akan punya jalur balik ke alamat itu.

Prefiks LAN jauh dalam rute adalah tujuan, bukan identitas ponsel. Rute untuk 10.60.0.0/24 berarti capai jaringan itu melalui tunnel; ia tidak mengatakan alamat 10.60.0.x mana yang harus dipegang ponsel, dan ponsel seharusnya tidak memegang satu pun. Penugasan statis berada di sisi server, tempat ia tidak dapat bertabrakan dengan kumpulan dinamis.

Dua sesi pada satu identitas membuka tabrakan yang sama. Jika sertifikat yang sama terhubung dua kali dan server mengirim satu alamat tetap ke keduanya, sesi kedua menduplikasi yang pertama, dan solusinya adalah identitas terpisah atau penugasan terpisah, bukan penyuntingan di sisi klien.

Pemeriksaan 4: apakah ada hal lain yang menempati slot tunnel?

Android hanya mengizinkan satu layanan VPN aktif pada satu waktu. Aplikasi VPN lain, atau entri VPN selalu-aktif yang dibiarkan menyala untuk profil yang sudah tidak berfungsi, dapat mengambil slot itu sebelum klien OpenVPN Anda memanggil establish(). Antarmuka kemudian tidak pernah muncul meski profil valid, jadi putuskan VPN lain, matikan pengaturan selalu-aktif dan sambungkan ulang sebelum menyentuh profil.

Layanan yang memaksa jembatan Ethernet adalah jalan buntu lainnya. Aplikasi Android tanpa root dapat membuat tunnel IP, bukan segmen Ethernet terjembatani, jadi tidak ada alamat yang Anda ketik akan membuat server dev tap bekerja; operator harus menawarkan layanan yang dirutekan. Saat melaporkan masalah, sertakan nama dan versi klien, kumpulan opsi yang dikirim, topologi dan langkah tepat tempat alamat seharusnya muncul.

Jika keempat pemeriksaan lolos dan alamat ada, unik serta bertopeng benar, pertanyaan rute menjadi yang biasa: prefiks mana yang diizinkan server dan bagaimana klien harus membatasinya. Catat alamat tunnel, netmask dan topologinya sebelum mengubah hal lain, karena ketiga nilai itulah yang perlu dibandingkan operator dengan pandangan server.