Menyajikan OpenVPN melalui TCP dan UDP dari satu host
Satu proses mengikat satu transport sebelum 2.7. Bandingkan pasangan TAP yang dijembatani, dua subnet TUN, dan kumpulan alamat bersama, lalu cocokkan setiap profil dengan listener-nya.
Jaringan yang hanya mengizinkan TCP 443 hidup berdampingan dengan jaringan yang meloloskan UDP dengan mudah, dan satu server harus melayani keduanya. Profil dengan proto udp menjawab kelompok kedua dan gagal pada kelompok pertama, dan menyunting konfigurasi yang sama agar menyebut proto tcp tidak menciptakan listener kedua. Direktif itu memilih satu transport untuk satu proses. Semua hal lain mengikuti dari batasan tersebut.
Entah Anda menjalankan lebih dari satu proses, atau Anda menjalankan versi yang dapat mengikat beberapa socket sekaligus.
Satu proses mengikat satu transport sebelum 2.7
Komunitas OpenVPN mengikat socket yang dijelaskan proto, dan direktif itu memilih satu transport untuk instance tersebut. TCP dan UDP adalah tumpukan terpisah, sehingga nomor port yang sama dapat diduduki keduanya pada saat yang sama, tetapi tidak oleh satu proses. Oleh karena itu jalur 2.6 memberi Anda satu transport per daemon. OpenVPN 2.7 menghapus batasan itu untuk server, yang dapat mengikat beberapa socket melalui beberapa pernyataan --local dalam satu proses.
Periksa versinya sebelum merancang di sekitar salah satu jawaban, karena tataan 2.7 adalah model operasional berbeda dengan sintaks konfigurasinya sendiri. Panduan yang ditulis untuk 2.6 menjelaskan dua proses bahkan ketika tidak mengatakannya.
Tiga cara menjalankan dua instance
Dengan antarmuka TAP, jalankan satu instance per transport dan jembatani dua perangkat tap di host. Kedua kumpulan klien berakhir di domain siaran yang sama, sehingga satu kumpulan alamat dapat mencakup keduanya dan protokol yang bergantung pada siaran tetap bekerja. Dengan TUN, penjembatanan tidak tersedia, jadi pemisahan paling sederhana memberi setiap instance subnetnya sendiri dan membiarkan perutean memisahkan kedua kumpulan klien. Opsi ketiga mempertahankan satu kumpulan dengan membuat setiap instance memanggil skrip learn-address yang memasang rute /32 untuk klien melalui perangkat instance tersebut.
Tataan ketiga itulah yang orang minta dan yang paling butuh kehati-hatian, karena skrip menjadi bagian dari jalur data dan harus menangani peristiwa tambah, perbarui, dan hapus dengan benar.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Pisahkan kedua instance
Setiap instance juga memerlukan port atau alamat terpisah, berkas status terpisah, dan tujuan log terpisah. Dua daemon yang menambahkan ke satu berkas status menghasilkan keluaran yang tidak dapat dibaca saat insiden, padahal justru saat itulah Anda membutuhkannya. Jika instance kedua mengikat alamat tertentu, alamat itu harus ada di host saat proses dimulai; jika tidak, proses keluar dengan kegagalan pengikatan sebelum mengatakan apa pun tentang kunci.
Beri nama unit dan profil sehingga transportnya jelas dari nama berkas. Operator berikutnya tidak perlu membuka konfigurasi untuk mengetahui mana yang TCP.
Cocokkan profil dengan listener
Server yang menjalankan proto tcp mengharapkan profil klien dengan proto tcp-client, dan profil yang masih membawa proto udp terhadap listener itu waktu habis tanpa kesalahan yang dapat ditindaklanjuti pengguna. Pertahankan dua profil jika penyebaran menawarkan kedua transport, dan beri label agar dukungan tahu mana yang dicoba. Nomor port saja tidak menjelaskan transport.
Aturan firewall mengikuti pemisahan yang sama: aturan untuk UDP 1194 tidak mengatakan apa pun tentang TCP 1194, dan aturan untuk satu alamat tidak mencakup listener lainnya.
Baca dulu pandangan server
Mulailah dengan ss -lntup di server dan pastikan listener TCP maupun UDP muncul. Kemudian hubungkan satu klien dari setiap jenis dan periksa keluaran status untuk dua entri dengan alamat berbeda. Jika socket ada dan tidak ada klien yang datang, jalur atau firewall menolak paket sebelum daemon melihatnya.
Socket yang tidak pernah muncul adalah masalah konfigurasi atau pengikatan, dan socket yang muncul tetapi tidak pernah mencatat koneksi adalah masalah penyaringan. Keduanya terlihat sama dari klien, karena itu pandangan server sendiri didahulukan. Ingatlah bahwa TCP membawa penyumbatan kepala antrean, jadi menawarkannya adalah langkah keterjangkauan, bukan peningkatan bagi klien dengan jalur UDP yang bersih.