UDP bukan selalu lebih pantas: memilih pengangkutan OpenVPN

Setiap panduan mengatakan UDP mengalahkan TCP untuk OpenVPN, dan nasihat itu ialah lalai, bukan ukuran. Pengangkutan mengubah cara paket dihantar dan apa yang berlaku apabila laluan menggugurkannya, bukan cara terowong disulitkan. Di sebalik portal tawanan atau proksi yang hanya membenarkan port 443, pilihan yang lebih perlahan itulah yang benar-benar bersambung. Perkara berikut memisahkan apa yang protokol lakukan daripada apa yang dibenarkan oleh rangkaian akses anda.

Apa yang sebenarnya diubah oleh pengangkutan

TCP menyampaikan aliran bait yang boleh dipercayai dan tersusun serta menghantar semula semua yang hilang, seperti yang ditetapkan oleh RFC 9293. UDP menyerahkan datagram kepada rangkaian, dan OpenVPN menjalankan lapisan kebolehpercayaannya sendiri di atas soket itu. Enkapsulasi TCP di dalam TCP menyusun dua gelung pemulihan, jadi satu segmen yang hilang boleh menahan aliran dalaman sehingga penghantaran semula luar tiba. Interaksi itulah hujah sebenar untuk UDP, dan ia muncul sebagai kependaman dan bukan sebagai daya pengeluaran.

Kesannya bertambah dengan kehilangan dan masa pergi balik. Pada laluan tempatan yang bersih kedua-dua pengangkutan terasa sama, sebab itu ujian makmal jarang menghasilkan semula aduan. Pada pautan mudah alih yang sesak perbezaannya kelihatan dalam sesi interaktif jauh sebelum pemindahan besar menyedari apa-apa.

Tiada satu pun daripada ini menyentuh kerahsiaan atau integriti. Jabat tangan TLS dan sifer saluran data adalah sama untuk kedua-dua pengangkutan, jadi bertukar tidak dapat menyelamatkan sut sifer yang lemah.

Di mana TCP mendapat tempatnya

Rangkaian akses ialah sebab biasa memilih TCP. Hotel, lapangan terbang atau rangkaian tetamu mungkin membenarkan 443 keluar dan membuang semua yang lain, dan pendengar TCP pada port itu ialah satu-satunya profil yang berfungsi. Itu kebolehcapaian, bukan prestasi, dan itu sebab yang cukup baik dengan sendirinya.

TCP juga membantu apabila laluan stabil tetapi kotak tengah bermusuhan. Sesetengah rangkaian menetapkan semula aliran UDP yang panjang sambil bertoleransi sesi TCP yang menyerupai trafik web biasa. Sama ada persamaan itu berjaya ialah sifat rangkaian tertentu, dan tiada panduan boleh menjanjikannya untuk semua. Uji di dalam rangkaian yang gagal sebelum menyalahkan protokol.

Log masuk yang ditolak bukan masalah pengangkutan. Menyahdayakan pengesahan sijil untuk memaksa sambungan melalui ialah perubahan lain dengan hasil yang jauh lebih buruk.

Menyediakan profil TCP ialah kompromi praktikal. Kebanyakan klien menyimpan kedua-duanya dan membolehkan anda bertukar apabila rangkaian menolak laluan UDP, yang tidak memakan kos sehingga anda memerlukannya. Apa yang tidak patut anda lakukan ialah menghantar dua profil yang menunjuk ke titik akhir berbeza, kerana perbandingan anda kemudian mengukur pelayan.

Semak pendengar mana yang sebenarnya anda ada

Sebelum membandingkan prestasi, pastikan kedua-dua hujung bersetuju tentang pengangkutan dan port. Menukar proto udp kepada proto tcp dalam fail klien tidak mencipta pendengar pelayan. Pelayan mesti dikonfigurasikan untuk protokol itu, dan profil mesti sepadan dengannya.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep mencetak apa yang diberitahu kepada pelayan untuk digunakan, manakala dua senarai soket menunjukkan apa yang ia terikat. Pendengar UDP hanya muncul dalam senarai pertama dan pendengar TCP hanya dalam senarai kedua, jadi baris yang hilang ialah cara terpantas mencari profil yang tidak pernah digunakan. Bandingkan port juga, kerana profil TCP pada 1194 berkelakuan berbeza daripada yang pada 443 dalam kebanyakan rangkaian akses. Mulakan semula perkhidmatan selepas perubahan dan baca baris log yang melaporkan pengikatan.

Pengesahan di pihak klien murah: jalankan sambungan dengan --verb 4 dan baca baris pengangkutan dalam log. Jika klien berkata UDP manakala pelayan mendengar pada TCP, jabat tangan tidak pernah bermula dan tiada penalaan akan membantu.

Bandingkan beban kerja, bukan label pengangkutan

Perbandingan yang adil mengekalkan segala-galanya malar kecuali pengangkutan. Peranti yang sama, rangkaian akses yang sama, hos destinasi yang sama, aplikasi yang sama dan idealnya pelayan yang sama. Jika kedua-dua profil menunjuk ke hos berbeza, anda juga mengukur hos itu.

Catat tiga hasil bagi setiap larian: sama ada terowong terbentuk, sama ada ia kekal dan sama ada tugasan selesai. Permintaan kecil yang berjaya manakala pemindahan besar tersekat menunjukkan saiz paket dan MTU, bukan pengangkutan. Sambungan semula berulang menunjukkan laluan atau tamat masa kotak tengah.

Kekalkan profil yang berfungsi dalam keadaan yang benar-benar anda hadapi, dan simpan yang lain. Pilihan itu milik rangkaian, bukan orang, sebab itu mana-mana jawapan lalai tunggal salah di suatu tempat.