TAP atau TUN? Klien OpenVPN Android dan Server Berjembatan

Profil yang bekerja di laptop gagal di ponsel. Langkah yang jelas adalah mengubah satu kata di konfigurasi klien. Kata itu tidak akan membantu, karena kedua ujungnya tidak membicarakan jenis lalu lintas yang sama.

TAP membawa frame Ethernet. TUN membawa paket IP. Aplikasi VPN Android diberi antarmuka IP, yang membuat salah satu dari dua tataan itu mungkin dan yang lain tidak, terlepas dari apa yang dikatakan konfigurasi.

Perbandingannya singkat, tetapi menentukan apakah Anda dapat memperbaikinya di ponsel atau harus mengubah layanan.

Dua jenis terowongan dengan muatan berbeda

Antarmuka TAP berperilaku seperti adaptor Ethernet. Ia membawa frame, yaitu ARP, siaran, dan apa pun yang dibawa LAN di bawah IP. Itulah yang membuat penjembatanan mungkin: terowongan memperluas domain siaran dan klien berperilaku seolah tersambung ke sakelar.

Antarmuka TUN membawa paket IP yang dialamatkan kepadanya. Tidak ada lapisan taut yang dinegosiasikan, tidak ada ARP, dan tidak ada siaran. Perutean menentukan apa yang masuk ke terowongan, dan konfigurasi sisi server memakai subnet alih-alih jembatan.

Kedua ujung harus sepakat mana dari keduanya yang mereka lakukan. Mengubah dev tap menjadi dev tun pada satu sisi tidak mengonversi layanan; itu menghasilkan klien yang mengharapkan terowongan yang dirutekan dan server yang masih mengirim frame, dan jabat tangan bisa berhasil sementara tidak ada yang berguna menyeberang.

Apa yang sebenarnya diberikan Android kepada aplikasi

API VpnService platform memberi aplikasi antarmuka virtual untuk paket IP, dikonfigurasi dengan alamat, rute, dan MTU. Tidak ada adaptor Ethernet dalam API itu, dan tidak ada cara bagi aplikasi untuk menciptakannya.

Karena itulah OpenVPN Connect mendokumentasikan dukungan koneksi TUN yang dirutekan di Android alih-alih penjembatanan TAP. FAQ Android adalah pernyataan sisi klien tentang batas itu, dan itu sesuai dengan API platform.

Alat jaringan dengan root, firmware khusus, atau produk yang menerapkan lapisan terjemahan eksplisit adalah tataan lain. Kasus biasa adalah yang perlu direncanakan: aplikasi yang dapat mengimpor berkas Anda dan berjalan sebagai pengguna normal, dengan antarmuka IP dan tidak ada apa pun di bawahnya.

Bagaimana tampilannya saat Anda tetap mencoba

Koneksi biasanya terbentuk. Itulah yang membuat kegagalannya membingungkan: klien melaporkan tersambung, log server menunjukkan rekan, dan tidak ada aplikasi yang bekerja.

Lalu lintas yang dialamatkan ke alamat yang diberikan kepada ponsel tidak tiba, karena server menjembatani frame ke alamat MAC yang tidak pernah dimiliki ponsel. Penemuan yang bergantung pada siaran tetap kosong. Jika LAN bergantung pada DHCP melalui jembatan, ponsel tidak akan memperoleh sewa dengan cara itu, dan alamat yang diberikan secara manual di subnet berjembatan tetap tidak menciptakan antarmuka yang hilang.

Beberapa klien gagal lebih awal, saat mengimpor profil, ketika melihat jenis perangkat yang tidak dapat mereka terapkan. Kedua perilaku itu berarti hal yang sama, dan tidak satu pun diperbaiki dengan menambahkan rute, mengubah DNS, atau memperlebar rentang alamat terowongan.

Apa yang harus diubah sisi server

Perbaikannya menjadi milik siapa pun yang menjalankan layanan VPN, dan biasanya bersifat tambahan alih-alih migrasi. Jalankan instans OpenVPN kedua dengan perangkat yang dirutekan, subnet klien sendiri, dan konfigurasi sisi server yang memberikan alamat serta mendorong rute yang dibutuhkan ponsel. Instans berjembatan yang ada tetap melayani perangkat yang benar-benar membutuhkan Ethernet.

Dua detail membuatnya berfungsi dalam praktik. LAN membutuhkan rute balik untuk subnet klien baru, mengarah ke host VPN, jika tidak balasan tidak akan pernah kembali. Dan firewall di host terowongan harus meneruskan antara antarmuka terowongan dan LAN, dan itulah langkah yang paling sering terlewat ketika uji dari host itu sendiri berhasil.

Jika operator tidak dapat menambahkan layanan, alternatifnya adalah perangkat yang dapat bergabung ke jembatan, yaitu laptop atau router yang bertindak atas nama ponsel. Itu jalan pintas dengan biaya pengelolaannya sendiri, bukan konfigurasi Android.

Putuskan dari aplikasi, bukan dari terowongan

Tanyakan apa yang sebenarnya harus dicapai ponsel, lalu petakan. Berbagi berkas atau situs intranet yang dicapai dengan nama atau alamat adalah kebutuhan IP, dan terowongan yang dirutekan memenuhinya begitu DNS menyelesaikan nama dan rutenya ada. Alat penemuan yang menelusuri domain siaran lokal bukan kebutuhan IP, dan berapa pun peruteannya tidak akan mengisinya.

Tabel itu juga merupakan permintaan yang dikirim. Sebutkan aplikasinya, alamat atau nama yang dipakainya, dan apakah ia bergantung pada penemuan. Operator dapat bertindak atas deskripsi itu, yang tidak dapat dilakukan siapa pun atas ponsel yang tidak mau tersambung.

Terakhir, pertahankan layanan TAP untuk perangkat yang membutuhkannya alih-alih membuat setiap klien meniru adaptor LAN. Dua layanan dengan tujuan yang jelas lebih mudah didukung daripada satu yang bekerja setengah untuk semua.