TAP atau TUN? Klien OpenVPN Android dan Pelayan Berjambatan

Profil yang berfungsi pada komputer riba gagal pada telefon. Langkah jelas ialah menukar satu perkataan dalam konfigurasi klien. Perkataan itu tidak akan membantu, kerana kedua-dua hujung tidak bercakap tentang jenis trafik yang sama.

TAP membawa bingkai Ethernet. TUN membawa paket IP. Aplikasi VPN Android diberikan antara muka IP, yang menjadikan salah satu daripada dua susunan itu mungkin dan yang satu lagi tidak, tanpa mengira apa yang dikatakan konfigurasi.

Perbandingannya singkat, tetapi ia menentukan sama ada anda boleh membetulkannya pada telefon atau perlu menukar perkhidmatan.

Dua jenis terowong dengan muatan berbeza

Antara muka TAP berkelakuan seperti penyesuai Ethernet. Ia membawa bingkai, iaitu ARP, siaran dan apa sahaja yang dibawa LAN di bawah IP. Itulah yang menjadikan penjambatan mungkin: terowong melanjutkan domain siaran dan klien berkelakuan seolah-olah dipasang ke suis.

Antara muka TUN membawa paket IP yang dialamatkan kepadanya. Tiada lapisan pautan untuk dirundingkan, tiada ARP dan tiada siaran. Penghalaan menentukan apa yang masuk ke terowong, dan konfigurasi bahagian pelayan menggunakan subnet dan bukan jambatan.

Kedua-dua hujung mesti bersetuju yang mana satu daripada dua itu yang mereka lakukan. Menukar dev tap kepada dev tun pada satu sisi tidak menukar perkhidmatan; ia menghasilkan klien yang menjangka terowong dihalakan dan pelayan yang masih menghantar bingkai, dan jabat tangan boleh berjaya sementara tiada apa yang berguna melintas.

Apa yang sebenarnya diberikan Android kepada aplikasi

API VpnService platform memberikan aplikasi antara muka maya untuk paket IP, dikonfigurasikan dengan alamat, laluan dan MTU. Tiada penyesuai Ethernet dalam API itu, dan tiada cara untuk aplikasi mencipta satu.

Itulah sebabnya OpenVPN Connect mendokumenkan sokongan untuk sambungan TUN yang dihalakan pada Android dan bukan penjambatan TAP. Soalan Lazim Android ialah pernyataan sebelah klien tentang sempadan itu, dan ia sepadan dengan API platform.

Alat rangkaian dengan root, perisian tegar tersuai atau produk yang melaksanakan lapisan terjemahan eksplisit ialah susunan lain. Kes biasa ialah yang perlu dirancang: aplikasi yang boleh mengimport fail anda dan berjalan sebagai pengguna biasa, dengan antara muka IP dan tiada apa di bawahnya.

Bagaimana rupanya apabila anda tetap mencuba

Sambungan biasanya terbentuk. Itulah yang menjadikan kegagalan mengelirukan: klien melaporkan bersambung, log pelayan menunjukkan rakan sebaya, dan tiada aplikasi berfungsi.

Trafik yang dialamatkan ke alamat yang diberikan kepada telefon tidak tiba, kerana pelayan menjambatani bingkai ke alamat MAC yang tidak pernah dimiliki telefon. Penemuan yang bergantung pada siaran kekal kosong. Jika LAN bergantung pada DHCP melalui jambatan, telefon tidak akan memperoleh pajakan dengan cara itu, dan alamat yang diberikan secara manual dalam subnet berjambatan masih tidak mencipta antara muka yang hilang.

Sesetengah klien gagal lebih awal, semasa mengimport profil, apabila melihat jenis peranti yang tidak dapat mereka laksanakan. Kedua-dua tingkah laku bermaksud perkara yang sama, dan tidak satu pun dibetulkan dengan menambah laluan, menukar DNS atau meluaskan julat alamat terowong.

Apa yang perlu diubah oleh bahagian pelayan

Pembetulan itu milik sesiapa yang mengendalikan perkhidmatan VPN, dan ia biasanya tambahan dan bukan migrasi. Jalankan contoh OpenVPN kedua dengan peranti yang dihalakan, subnet klien sendiri dan konfigurasi bahagian pelayan yang memberikan alamat serta menolak laluan yang diperlukan telefon. Contoh berjambatan sedia ada terus melayani peranti yang benar-benar memerlukan Ethernet.

Dua butiran menjadikannya berfungsi dalam amalan. LAN memerlukan laluan balik untuk subnet klien baharu, menunjuk kepada hos VPN, jika tidak balasan tidak akan kembali. Dan tembok api pada hos terowong mesti memajukan antara antara muka terowong dan LAN, dan itulah langkah yang paling kerap terlepas apabila ujian dari hos itu sendiri berjaya.

Jika pengendali tidak boleh menambah perkhidmatan, alternatifnya ialah peranti yang boleh menyertai jambatan, iaitu komputer riba atau penghala yang bertindak bagi pihak telefon. Itu jalan pintas dengan kos pengurusan sendiri, bukan konfigurasi Android.

Putuskan daripada aplikasi, bukan terowong

Tanya apa yang sebenarnya perlu dicapai oleh telefon, kemudian petakannya. Perkongsian fail atau laman intranet yang dicapai melalui nama atau alamat ialah keperluan IP, dan terowong yang dihalakan memenuhinya sebaik sahaja DNS menyelesaikan nama dan laluan wujud. Alat penemuan yang melayari domain siaran setempat bukan keperluan IP, dan berapa banyak penghalaan pun tidak akan mengisinya.

Jadual itu juga merupakan permintaan yang dihantar. Namakan aplikasi, alamat atau nama yang digunakannya, dan sama ada ia bergantung pada penemuan. Pengendali boleh bertindak atas huraian itu, yang tidak dapat dilakukan oleh sesiapa atas telefon yang tidak mahu bersambung.

Akhir sekali, kekalkan perkhidmatan TAP untuk peranti yang memerlukannya daripada memaksa setiap klien meniru penyesuai LAN. Dua perkhidmatan dengan tujuan yang jelas lebih mudah disokong daripada satu yang berfungsi separuh untuk semua.