Haruskah saya menggunakan ketuk atau menyetel untuk openvpn?


85

Apa perbedaan antara menggunakan dev tap dan dev tun untuk openvpn? Saya tahu mode yang berbeda tidak dapat saling beroperasi. Apa perbedaan teknis, selain itu hanya operasi layer 2 vs 3. Apakah ada karakteristik kinerja yang berbeda, atau tingkat overhead yang berbeda. Mode mana yang lebih baik. Fungsi apa yang tersedia secara eksklusif di setiap mode.


Tolong jelaskan perbedaannya? whats ethernet bridging dan mengapa itu buruk?
Thomaschaaf

Jawaban:


74

jika tidak apa-apa untuk membuat vpn pada layer 3 (satu hop lagi antara subnet) - pergi untuk tun.

jika Anda perlu menjembatani dua segmen ethernet di dua lokasi berbeda - kemudian gunakan ketuk. dalam pengaturan seperti itu Anda dapat memiliki komputer dalam ip subnet yang sama (mis. 10.0.0.0/24) di kedua ujung vpn, dan mereka akan dapat 'berbicara' satu sama lain secara langsung tanpa ada perubahan dalam tabel routing mereka. vpn akan bertindak seperti saklar ethernet. ini mungkin terdengar keren dan berguna dalam beberapa kasus tetapi saya sarankan untuk tidak melakukannya kecuali Anda benar-benar membutuhkannya. jika Anda memilih pengaturan bridging layer 2 - akan ada sedikit 'sampah' (yaitu paket siaran) yang melintasi vpn Anda.

menggunakan tap Anda akan memiliki overhead yang sedikit lebih - selain header ip juga 38B atau lebih header ethernet akan dikirim melalui terowongan (tergantung pada jenis lalu lintas Anda - itu mungkin akan menyebabkan lebih banyak fragmentasi).


24

Saya memilih "ketuk" ketika mengatur VPN untuk teman yang memiliki usaha kecil karena kantornya menggunakan kusut mesin Windows, printer komersial, dan server file Samba. Beberapa dari mereka menggunakan TCP / IP murni, beberapa tampaknya hanya menggunakan NetBIOS (dan karenanya membutuhkan paket siaran Ethernet) untuk berkomunikasi, dan beberapa saya bahkan tidak yakin.

Jika saya memilih "tun", saya mungkin akan menghadapi banyak layanan rusak - banyak hal yang berfungsi saat Anda berada di kantor secara fisik, tetapi kemudian akan rusak ketika Anda pergi ke luar lokasi dan laptop Anda tidak dapat "melihat" perangkat pada subnet Ethernet lagi.

Tetapi dengan memilih "ketuk", saya memberi tahu VPN untuk membuat mesin jarak jauh merasa persis seperti mereka ada di LAN, dengan paket Ethernet siaran dan protokol Ethernet mentah yang tersedia untuk berkomunikasi dengan printer dan server file dan untuk memberi daya pada tampilan Network Neighborhood mereka. Ini bekerja dengan baik, dan saya tidak pernah mendapatkan laporan tentang hal-hal yang tidak berfungsi di luar kantor!


15

Saya selalu mengatur tun. Ketuk digunakan oleh penghubung ethernet di OpenVPN dan memperkenalkan tingkat kerumitan yang tidak dipelihara yang sama sekali tidak perlu diganggu. Biasanya ketika VPN perlu diinstal, dibutuhkan sekarang , dan penyebaran yang rumit tidak datang dengan cepat.

The OpenVPN FAQ dan HOWTO Ethernet Bridging yang sangat baik sumber tentang topik ini.


9
Dalam pengalaman saya, tun lebih mudah untuk diatur tetapi tidak menangani banyak konfigurasi jaringan, sehingga Anda mengalami lebih banyak masalah jaringan yang aneh. Sebaliknya, ketuk sedikit lebih rumit untuk disetel, tetapi begitu Anda melakukannya, biasanya "hanya berfungsi" untuk semua orang.
Cerin

8

Jika Anda berencana untuk menghubungkan perangkat seluler (iOS atau Android) menggunakan OpenVPN, maka Anda harus menggunakan TUN karena saat ini TAP tidak didukung oleh OpenVPN pada mereka:

Kelemahan TAP: ..... tidak dapat digunakan dengan perangkat Android atau iOS


TAP didukung di Android melalui aplikasi pihak ketiga: OpenVPN Client (Pengembang: colucci-web.it)
Boo

5

Saya mulai menggunakan tun, tetapi beralih untuk mengetuk karena saya tidak suka menggunakan subnet / 30 untuk setiap PC (saya perlu mendukung Windows). Saya menemukan itu menjadi boros dan membingungkan.

Kemudian saya menemukan opsi "topologi subnet" di server. Bekerja dengan RC 2.1 (bukan 2.0), tetapi memberi saya semua keunggulan tun (tidak menjembatani, kinerja, perutean, dll.) Dengan kenyamanan satu alamat IP (berurutan) per mesin (windows).


5

Karena saya menemukan saran sederhana sulit didapat:

Anda dapat menggunakan TUN jika Anda hanya menggunakan VPN untuk terhubung ke internet .

Anda perlu menggunakan TAP jika Anda ingin terhubung ke jaringan jarak jauh yang sebenarnya (printer, desktop jarak jauh, dll.)


4

Saya memiliki pertanyaan yang sama ini bertahun-tahun yang lalu dan berusaha menjelaskannya secara langsung (yang secara pribadi saya temukan kekurangan sumber daya lain) di blog saya: An OpenVPN Primer

Semoga ini bisa membantu seseorang


2
Sementara ini secara teoritis dapat menjawab pertanyaan, akan lebih baik untuk memasukkan bagian-bagian penting dari jawaban di sini, dan menyediakan tautan untuk referensi.
Mark Henderson

Pos yang bagus! Saya jarang membaca seluruh posting seperti ini tetapi yang ini saya lakukan. Saya setuju dengan Mark Henderson, Anda harus menulis ringkasan kecil dan meletakkan tautan setelahnya.
Pierre-Luc Bertrand

4


TUN "rule of thumb" saya - jika Anda HANYA membutuhkan akses ke sumber daya yang terhubung langsung ke mesin server OpenVPN di ujung lainnya, dan tidak ada masalah Windows. Sedikit kreativitas di sini dapat membantu, dengan membuat sumber daya "tampak" menjadi lokal ke server OpenVPN. (contohnya mungkin koneksi CUPS ke printer jaringan, atau berbagi Samba pada komputer lain DIMUNTAH pada server OpenVPN.)

TAP - jika Anda memerlukan akses ke beberapa sumber daya (mesin, penyimpanan, printer, perangkat) yang terhubung melalui jaringan di ujung lainnya. TAP juga mungkin diperlukan untuk aplikasi Windows tertentu.


Keuntungan:
TUN biasanya membatasi akses VPN ke satu mesin (alamat IP) dan karenanya (mungkin) keamanan yang lebih baik melalui konektivitas terbatas ke jaringan sisi jauh. Koneksi TUN akan membuat lebih sedikit beban pada terowongan VPN, dan pada gilirannya jaringan sisi-jauh karena hanya lalu lintas ke / dari alamat IP tunggal akan melintasi VPN ke sisi lain. Rute IP ke stasiun lain di subnet tidak termasuk, sehingga lalu lintas tidak dikirim melintasi terowongan VPN dan sedikit atau tidak ada komunikasi yang dimungkinkan di luar server OpenVPN.

TAP - biasanya memungkinkan paket mengalir dengan bebas di antara titik akhir. Ini memberikan fleksibilitas komunikasi dengan stasiun lain di jaringan sisi jauh, termasuk beberapa metode yang digunakan oleh perangkat lunak Microsoft yang lebih lama. TAP memiliki paparan keamanan inheren yang terlibat dengan pemberian akses luar "di belakang firewall". Ini akan memungkinkan lebih banyak paket traffic mengalir melalui terowongan VPN. Ini juga membuka kemungkinan konflik alamat antara titik akhir.

ada yangperbedaan latensi karena lapisan tumpukan, tetapi dalam sebagian besar skenario pengguna akhir, kecepatan sambungan titik akhir mungkin merupakan penyumbang latensi yang lebih signifikan daripada lapisan tumpukan tertentu pada transmisi. Jika latensi dipermasalahkan, mungkin merupakan ide bagus untuk mempertimbangkan alternatif lain. Multiprocessor tingkat GHz saat ini biasanya lebih cepat dari hambatan pengiriman melalui internet.

"Lebih baik" dan "Lebih buruk" tidak dapat didefinisikan tanpa konteks.
(Ini adalah jawaban favorit konsultan, "Yah, itu tergantung ...")
Apakah Ferrari "lebih baik" daripada truk sampah? Jika Anda mencoba untuk berpuasa, itu mungkin; tetapi jika Anda mencoba untuk mengangkut beban berat, mungkin tidak.

Batasan seperti "kebutuhan untuk akses" dan "persyaratan keamanan" harus didefinisikan, serta mendefinisikan batasan seperti throughput jaringan dan batasan peralatan, sebelum orang dapat memutuskan apakah TUN atau TAP lebih cocok dengan kebutuhan Anda.


2

Menyiapkan TAP hampir tidak memerlukan pekerjaan tambahan dari orang yang mengaturnya.

Tentu saja jika Anda tahu cara mengatur TUN tetapi tidak mengerti apa yang Anda lakukan dan hanya mengikuti tutorial tun, Anda akan berjuang untuk mengatur TAP tetapi bukan karena itu lebih sulit tetapi karena Anda tidak tahu apa yang Anda lakukan. perbuatan. Yang dengan mudah dapat menyebabkan konflik jaringan di lingkungan TAP dan sepertinya itu lebih rumit.

Faktanya adalah, jika Anda tidak memerlukan tutorial karena Anda tahu apa yang Anda lakukan, mengatur ketukan membutuhkan waktu yang sama dengan mengatur tun.

dengan ketuk ada banyak solusi tentang subnetting, saya menemukan diri saya cara termudah adalah dengan menggunakan subnet kelas B. site1 (Network1) menggunakan 172.22.1.0/16 site2 (network2) menggunakan 172.22.2.0/16 site3 menggunakan 172.22.3.0/16 dll.

Anda mengatur site1 dengan server oVPN dan memberi klien kisaran ip 172.22.254.2 - 172.22.254.255/16 sehingga Anda dapat memiliki lebih dari 200 klien ovpn (subnet) setiap subnet dapat memiliki lebih dari 200 klien. Menjadikan total 40.000 klien yang dapat Anda tangani (ragu oVPN dapat mengatasinya, tetapi seperti yang Anda lihat, pengaturan subnetting yang tepat akan memberi Anda lebih dari cukup seperti yang kemungkinan besar Anda butuhkan)

Anda menggunakan keran dan semua klien bersama seperti dalam jaringan perusahaan besar.

JIKA, namun setiap situs memiliki DHCP sendiri, dan seharusnya demikian, Anda harus memastikan menggunakan ebtable atau iptables atau dnsmasq untuk memblokir distribusi dhcp menjadi liar. Namun tabel akan memperlambat kinerja. menggunakan dnsmasq dhcp-host = 20: a9: 9b: 22: 33: 44, abaikan misalnya akan menjadi tugas besar untuk melakukan setup pada semua server dhcp. Namun, pada perangkat keras modern dampak dari ebtables tidak terlalu besar. hanya 1 atau 2%

overhead keran, kira-kira 32 untuk tun, tidak terlalu banyak masalah (mungkin pada jaringan tidak terenkripsi) tetapi pada jaringan terenkripsi biasanya AES yang akan menyebabkan perlambatan.

Pada wrt3200acm saya misalnya tidak terenkripsi saya mendapatkan 360Mbps. Menggunakan enkripsi turun menjadi 54-100Mbps tergantung pada jenis enkripsi yang saya pilih) tetapi openvpn tidak melakukan enkripsi pada 1500 dan enkripsi ke-2 pada 32 overhead. Sebaliknya ia melakukan enkripsi 1 kali pada 1500 + 32overhead.

Jadi pengaruhnya di sini minimal.

Pada perangkat keras lama Anda mungkin lebih memperhatikan dampaknya, tetapi pada perangkat keras modern itu benar-benar turun ke minimum.

Enkripsi antara 2 mesin virtual dengan dukungan AES membuat saya ovpn saya dengan TAP hingga 120-150Mbps.

Beberapa laporan router khusus DENGAN dukungan enkripsi perangkat keras AES mencapai 400Mbps! 3 kali lebih cepat daripada i5-3570k dapat melakukannya (yang pada sistem pengujian saya tidak bisa lebih tinggi dari 150Mbps pada 100% dari 1 utilisasi inti) Ujung saya yang lain: E3-1231 v3, kemudian kira-kira pada pemanfaatan CPU 7%, sekitar 25% dari penggunaan openvpn inti digunakan. Jadi E3 kemungkinan besar dapat meningkatkan koneksi 3 hingga 4 kali.

jadi Anda akan memiliki sesuatu antara 360Mbps dan 600Mbps dengan koneksi antara E3-1231 v3 cpu melakukan tap AES265 cipher, auth SHA256 dan ta.key, sertifikat tls-cipher Saya juga menggunakan TLS-DHE-RSA-WITH-AES- tertinggi 256-SHA256

Untuk menunjukkan hal ini, dengan ketuk: wrt3200acm mendapatkan hingga 70-80mbps dengan enkripsi. i5-3570k mencapai 120-150 dengan enkripsi. E3-1231 v3 mendapatkan setidaknya 360Mbps dengan enkripsi (ini diinterpolasi dari temuan saya dengan kasus 1 dan 2 karena saya tidak memiliki 2 E3-1231 v3 untuk diuji.)

Ini adalah temuan saya berdasarkan copy windows ke windows antara 2 klien di 2 subnet berbeda yang terhubung oleh TAP openvpn


-1

Jika demikian, mengapa, berapa banyak yang Anda dapatkan? Saya akan menggunakan TAP, secara eksplisit untuk alasan bahwa lapisan paket hasil dengan latensi yang jauh lebih sedikit dan kehilangan transmisi yang dikurangi dengan metode ini. Namun hanya dengan layer 3 apakah ini mempengaruhi efek nyata pada operasi VPN, terutama aspek tunneling dan IP mana yang diizinkan melalui dan alamat yang ditentukan. Penggunaan UDP mungkin memperkenalkan situasi lain di mana Anda harus memutuskan rute mana yang terbaik untuk Anda. Setiap jaringan berbeda dan memerlukan satu set parameter unik. Semoga ini membantu.


1
Cukup membingungkan. Harap pertimbangkan untuk membersihkannya, menjelaskan perbedaan yang penting dan menguncinya.
vonbrand
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.