Relay stream Nginx untuk UDP OpenVPN: apa yang berubah

Klien Anda disetel ke UDP, server Nginx punya blok location yang mengarah ke port VPN, dan tidak ada yang tiba. Itu wajar: location HTTP tidak dapat membawa datagram UDP, apa pun namanya di bagian depan. Nginx membutuhkan listener stream untuk ini, dan setelah konfigurasi dipindahkan ke sana, sekumpulan detail kedua menentukan apakah sesi bertahan.

Lapisan proxy datang sebelum alamat

Modul stream Nginx mem-proxy TCP dan UDP tanpa mengurai HTTP. Modul HTTP-nya mengharapkan baris permintaan, header, dan respons, yang tidak satu pun ada dalam OpenVPN datagram asli. Memilih lapisan karenanya menjadi keputusan pertama, dan itu tidak bergantung pada apakah listener berupa IPv4 atau IPv6.

Konfigurasi yang tampak bekerja dengan OpenVPN TCP tidak mengatakan apa pun tentang kasus UDP. Transportasi di sini adalah bagian dari protokol, bukan detail penerapan.

Listener dan backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

Pastikan build menyertakan modul stream sebelum mengubah apa pun; paket distribusi dapat memisahkannya ke modul terpisah, dan modul yang hilang menghasilkan kesalahan konfigurasi, bukan tunnel. Letakkan blok di konteks konfigurasi utama, bukan di dalam http, dan ganti alamat dokumentasi dengan backend yang sebenarnya.

Kedua rute dan kedua firewall harus mengizinkan datagram: jalur ke listener dan jalur dari proxy ke backend. Listener IPv6 juga tidak membuat jalur IPv4, jadi jika sebagian klien masih memakai IPv4, listener itu adalah entri terpisah dengan pengujiannya sendiri. Periksa firewall backend itu sendiri dari alamat proxy, bukan dari laptop Anda.

Timeout sesi bukan timeout permintaan

Proxy stream menyimpan status untuk sesi UDP dan membuangnya sesuai timeout dan pengaturan responsnya. Timeout pendek yang disalin dari relay DNS tidak cocok untuk VPN yang mengharapkan pertukaran datagram berjam-jam, dan kegagalannya muncul sebagai koneksi yang mati diam-diam, bukan yang menolak dimulai.

Baca proxy_timeout efektif penerapan dan pengaturan hitung respons apa pun, lalu bandingkan dengan perilaku keepalive yang benar-benar dipakai VPN. Dua angka yang ditulis orang berbeda di berkas berbeda adalah keadaan normal sistem yang berfungsi. Dua angka yang tak pernah dibandingkan adalah keadaan normal sistem yang kadang-kadang gagal. Tulis keduanya ke catatan layanan agar perbandingannya terjadi sekali, di siang hari.

Apa yang diubah relay, dan apa yang tidak

Proxy stream tidak mengakhiri kanal kontrol TLS OpenVPN atau mengubahnya menjadi HTTPS. Backend tetap menjadi layanan VPN, dan hubungan sertifikat tetap antara klien dan layanan itu. Menjaga identitas backend yang dimaksud tetap menjadi tugas klien dan server.

Proxying biasa juga mengubah alamat sumber yang dilihat backend. Log akan menunjukkan proxy, dan aturan akses berbasis IP apa pun di server VPN akan menilai alamat itu, bukan alamat klien. Pelestarian sumber secara transparan adalah desain perutean dan hak istimewa tersendiri, bukan sesuatu yang muncul dari menambahkan udp ke listener. Rencanakan sebelum kebijakan yang bergantung pada alamat klien ditulis.

Verifikasi dari klien, bukan dari port

Pemeriksaan lokal bahwa port UDP terbuka membuktikan listener ada. Itu tidak membuktikan klien dapat mengautentikasi melewatinya atau terus bertukar lalu lintas. Selesaikan koneksi nyata dari klien yang disetujui, lalu pastikan sesi bertahan cukup lama untuk berarti.

Ketika seseorang melaporkan bahwa Nginx tidak bisa UDP karena alat relay sederhana berhasil menggantikannya, kedua fakta itu tidak berhubungan. Alat itu membuktikan backend menjawab; tidak mengatakan apa pun tentang apa yang didukung bagian depan. Keduanya bisa benar, dan hanya satu yang merupakan konfigurasi untuk penerapan ini.