Menghidangkan OpenVPN melalui TCP dan UDP dari satu hos
Satu proses mengikat satu pengangkutan sebelum 2.7. Bandingkan pasangan TAP yang dijambatani, dua subnet TUN dan kolam dikongsi, kemudian padankan setiap profil dengan pendengarnya.
Rangkaian yang hanya membenarkan TCP 443 wujud bersama rangkaian yang meluluskan UDP tanpa masalah, dan satu pelayan perlu melayani kedua-duanya. Profil dengan proto udp menjawab kumpulan kedua dan gagal pada yang pertama, dan menyunting konfigurasi yang sama untuk menyatakan proto tcp tidak mencipta pendengar kedua. Arahan itu memilih satu pengangkutan untuk satu proses. Segala-galanya yang lain berpunca daripada kekangan itu.
Sama ada anda menjalankan lebih daripada satu proses, atau anda menjalankan versi yang boleh mengikat beberapa soket serentak.
Satu proses mengikat satu pengangkutan sebelum 2.7
Komuniti OpenVPN mengikat soket yang diterangkan proto, dan arahan itu memilih satu pengangkutan untuk instans tersebut. TCP dan UDP ialah tindanan berasingan, jadi nombor port yang sama boleh diduduki oleh kedua-duanya serentak, tetapi bukan oleh satu proses. Oleh itu baris 2.6 memberikan anda satu pengangkutan bagi setiap daemon. OpenVPN 2.7 membuang kekangan itu untuk pelayan, yang boleh mengikat beberapa soket melalui beberapa pernyataan --local dalam satu proses.
Semak versi sebelum mereka bentuk sekitar mana-mana jawapan, kerana susunan 2.7 ialah model operasi berbeza dengan sintaks konfigurasinya sendiri. Panduan yang ditulis untuk 2.6 menerangkan dua proses walaupun ia tidak menyatakannya.
Tiga cara menjalankan dua instans
Dengan antara muka TAP, jalankan satu instans bagi setiap pengangkutan dan jambatani dua peranti tap pada hos. Kedua-dua set klien berakhir dalam domain siaran yang sama, yang membolehkan satu kolam alamat meliputi mereka dan memastikan protokol yang bergantung pada siaran terus berfungsi. Dengan TUN, penjambatan tidak tersedia, jadi pembahagian paling mudah memberikan setiap instans subnetnya sendiri dan penghalaan memisahkan kedua-dua set klien. Pilihan ketiga mengekalkan satu kolam dengan membiarkan setiap instans memanggil skrip learn-address yang memasang laluan /32 untuk klien melalui peranti instans itu.
Susunan ketiga itulah yang diminta orang dan yang paling memerlukan kehati-hatian, kerana skrip menjadi sebahagian daripada laluan data dan mesti mengendalikan peristiwa tambah, kemas kini dan padam dengan betul.
| 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 |
Asingkan kedua-dua instans
Setiap instans juga memerlukan port atau alamat berasingan, fail status berasingan dan destinasi log berasingan. Dua daemon yang menambah pada satu fail status menghasilkan output yang tidak dapat dibaca semasa insiden, dan ketika itulah anda memerlukannya. Jika instans kedua mengikat alamat tertentu, alamat itu mesti wujud pada hos apabila proses bermula; jika tidak, ia keluar dengan kegagalan pengikatan sebelum menyatakan apa-apa tentang kunci.
Namakan unit dan profil supaya pengangkutan jelas daripada nama fail. Pengendali seterusnya tidak sepatutnya perlu membuka konfigurasi untuk mengetahui yang mana TCP.
Padankan profil dengan pendengar
Pelayan yang menjalankan proto tcp mengharapkan profil klien dengan proto tcp-client, dan profil yang masih membawa proto udp terhadap pendengar itu tamat masa tanpa ralat yang boleh diambil tindakan oleh pengguna. Kekalkan dua profil jika penggunaan menawarkan kedua-dua pengangkutan, dan labelkan supaya sokongan tahu yang mana telah dicuba. Nombor port sahaja tidak menerangkan pengangkutan.
Peraturan tembok api mengikut pembahagian yang sama: peraturan untuk UDP 1194 tidak menyatakan apa-apa tentang TCP 1194, dan peraturan untuk satu alamat tidak meliputi pendengar yang lain.
Baca pandangan pelayan dahulu
Mulakan dengan ss -lntup pada pelayan dan sahkan bahawa pendengar TCP dan UDP kedua-duanya muncul. Kemudian sambungkan satu klien bagi setiap jenis dan semak output status untuk dua entri dengan alamat berbeza. Jika soket wujud dan tiada klien datang, laluan atau tembok api menolak paket sebelum daemon melihatnya.
Soket yang tidak pernah muncul ialah masalah konfigurasi atau pengikatan, dan soket yang muncul tetapi tidak pernah merekodkan sambungan ialah masalah penapisan. Kedua-duanya kelihatan sama dari klien, sebab itulah pandangan pelayan itu sendiri didahulukan. Ingat bahawa TCP membawa penyekatan kepala baris, jadi menawarkannya ialah langkah kebolehcapaian dan bukan peningkatan untuk klien dengan laluan UDP yang bersih.