Klien anda ditetapkan kepada UDP, pelayan Nginx mempunyai blok location yang menunjuk ke port VPN, dan tiada apa yang tiba. Itu dijangka: location HTTP tidak boleh membawa datagram UDP, apa pun nama bahagian hadapan. Nginx memerlukan pendengar stream untuk ini, dan setelah konfigurasi dipindahkan ke sana, satu lagi set butiran menentukan sama ada sesi akan bertahan.

Lapisan proksi datang sebelum alamat

Modul stream Nginx memproksi TCP dan UDP tanpa menghuraikan HTTP. Modul HTTP-nya menjangka baris permintaan, pengepala dan respons, dan tiada satu pun daripadanya ada dalam OpenVPN datagram asli. Memilih lapisan itu sebabnya keputusan pertama, dan ia tidak bergantung pada sama ada pendengar ialah IPv4 atau IPv6.

Konfigurasi yang kelihatan berfungsi dengan OpenVPN TCP tidak mengatakan apa-apa tentang kes UDP. Pengangkutan di sini ialah sebahagian daripada protokol, bukan butiran penggunaan.

Pendengar dan backend

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

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

Pastikan binaan mengandungi modul stream sebelum mengedit apa-apa; pakej pengedaran mungkin memisahkannya ke modul berasingan, dan modul yang tiada menghasilkan ralat konfigurasi dan bukan terowong. Letakkan blok itu dalam konteks konfigurasi utama, bukan di dalam http, dan gantikan alamat dokumentasi dengan backend sebenar.

Kedua-dua laluan dan kedua-dua firewall mesti membenarkan datagram: laluan ke pendengar dan laluan dari proksi ke backend. Pendengar IPv6 juga tidak mencipta laluan IPv4, jadi jika sesetengah klien masih menggunakan IPv4, pendengar itu ialah entri berasingan dengan ujiannya sendiri. Periksa firewall backend itu sendiri dari alamat proksi, bukan dari komputer riba anda.

Had masa sesi bukan had masa permintaan

Proksi stream menyimpan keadaan untuk sesi UDP dan membuangnya mengikut had masa dan tetapan responsnya. Had masa pendek yang disalin daripada relay DNS tidak sesuai untuk VPN yang menjangka bertukar datagram berjam-jam, dan kegagalan muncul sebagai sambungan yang mati senyap dan bukannya yang enggan bermula.

Baca proxy_timeout berkesan penggunaan dan sebarang tetapan kiraan respons, kemudian bandingkannya dengan tingkah laku keepalive yang benar-benar digunakan oleh VPN. Dua nombor yang ditulis oleh orang berbeza dalam fail berbeza ialah keadaan normal sistem yang berfungsi. Dua nombor yang tidak pernah dibandingkan ialah keadaan normal sistem yang terputus-putus. Tulis kedua-duanya dalam rekod perkhidmatan supaya perbandingan berlaku sekali, dalam cahaya siang.

Apa yang diubah oleh relay, dan apa yang tidak

Proksi stream tidak menamatkan saluran kawalan TLS OpenVPN atau menukarnya kepada HTTPS. Backend kekal sebagai perkhidmatan VPN, dan hubungan sijil kekal antara klien dan perkhidmatan itu. Memelihara identiti backend yang dimaksudkan masih menjadi tugas klien dan pelayan.

Proksi biasa juga mengubah alamat sumber yang dilihat oleh backend. Log akan menunjukkan proksi, dan sebarang peraturan akses berasaskan IP pada pelayan VPN akan menilai alamat itu dan bukan alamat klien. Pemeliharaan sumber secara telus ialah reka bentuk penghalaan dan keistimewaan yang berasingan, bukan sesuatu yang terhasil daripada menambah udp pada pendengar. Rancangnya sebelum dasar yang bergantung pada alamat klien ditulis.

Sahkan daripada klien, bukan daripada port

Semakan setempat bahawa port UDP terbuka membuktikan pendengar wujud. Ia tidak membuktikan bahawa klien boleh mengesahkan melalui port itu atau terus bertukar trafik. Lengkapkan sambungan sebenar daripada klien yang diluluskan, kemudian pastikan sesi kekal cukup lama untuk bermakna.

Apabila seseorang melaporkan bahawa Nginx tidak boleh melakukan UDP kerana alat relay mudah berjaya menggantikannya, kedua-dua fakta itu tidak berkaitan. Alat itu membuktikan bahawa backend menjawab; ia tidak mengatakan apa-apa tentang apa yang disokong oleh bahagian hadapan. Kedua-duanya boleh benar, dan hanya satu daripadanya ialah konfigurasi untuk penggunaan ini.

Artikel berkaitan