Relay ng stream sa Nginx para sa UDP ng OpenVPN: ano ang nagbabago

Ang iyong kliyente ay nakatakda sa UDP, ang server ng Nginx ay may blokeng location na tumuturo sa port ng VPN, at walang dumarating. Iyon ay inaasahan: hindi kayang magdala ng datagram ng UDP ang isang location ng HTTP, anuman ang itawag sa harapang bahagi. Kailangan ng Nginx ng tagapakinig na stream para dito, at kapag nailipat mo na ang konfigurasyon doon, isang pangalawang pangkat ng detalye ang magpapasya kung mabubuhay ang sesyon.

Ang layer ng proxy ay nauuna sa address

Ang modyul na stream ng Nginx ay nag-proxy ng TCP at UDP nang hindi pinag-aaralan ang HTTP. Inaasahan ng modyul nitong HTTP ang isang linyang kahilingan, mga header, at isang tugon, at wala sa mga iyon sa isang OpenVPN datagram na native. Kaya ang pagpili ng layer ang unang desisyon, at wala itong kinalaman sa kung ang tagapakinig ay IPv4 o IPv6.

Ang konfigurasyong mukhang gumagana sa OpenVPN sa TCP ay walang sinasabi tungkol sa kaso ng UDP. Ang transportasyon dito ay bahagi ng protocol, hindi detalye ng deployment.

Ang tagapakinig at ang backend

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

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

Tiyakin na kasama sa build ang modyul na stream bago mag-edit ng kahit ano; maaaring paghiwalayin ito ng distribusyong pakete sa sariling modyul, at ang nawawalang modyul ay nagdudulot ng error sa konfigurasyon sa halip na tunnel. Ilagay ang bloke sa pangunahing konteksto ng konfigurasyon, hindi sa loob ng http, at palitan ang address ng dokumentasyon ng tunay na backend.

Parehong ang mga ruta at ang dalawang firewall ay dapat payagan ang mga datagram: ang daan patungo sa tagapakinig at ang daan mula sa proxy patungo sa backend. Ang tagapakinig na IPv6 ay hindi rin lumilikha ng daang IPv4, kaya kung may mga kliyenteng gumagamit pa ng IPv4, ang tagapakinig na iyon ay hiwalay na entry na may sariling pagsubok. Suriin ang firewall ng backend mismo mula sa address ng proxy, hindi mula sa iyong laptop.

Ang timeout ng sesyon ay hindi timeout ng kahilingan

Ang proxy na stream ay nag-iingat ng estado para sa sesyon ng UDP at itinatapon ito ayon sa timeout at mga setting ng tugon nito. Ang maikling timeout na kinopya mula sa relay ng DNS ay hindi bagay sa VPN na umaasang magpalitan ng datagram nang ilang oras, at ang pagkasira ay lumilitaw na koneksyong tahimik na namamatay sa halip na isang tumatangging magsimula.

Basahin ang epektibong proxy_timeout ng deployment at anumang setting ng pagbilang ng tugon, pagkatapos ay ihambing ang mga ito sa pag-uugaling keepalive na aktwal na ginagamit ng VPN. Ang dalawang numero na isinulat ng magkaibang tao sa magkaibang file ay normal na kalagayan ng sistemang gumagana. Ang dalawang numero na hindi kailanman inihambing ay normal na kalagayan ng sistemang paminsan-minsang pumalya. Isulat ang dalawa sa talaan ng serbisyo upang ang paghahambing ay mangyari nang isang beses, sa liwanag ng araw.

Ano ang binabago ng relay, at ano ang hindi

Hindi tinatapos ng proxy na stream ang channel ng kontrol ng TLS ng OpenVPN at hindi ito ginagawang HTTPS. Ang backend ay nananatiling serbisyo ng VPN, at ang ugnayan ng sertipiko ay nananatili sa pagitan ng kliyente at ng serbisyong iyon. Ang pagpapanatili ng inaasahang pagkakakilanlan ng backend ay trabaho pa rin ng kliyente at ng server.

Binabago rin ng ordinaryong pag-proxy ang address ng pinagmulan na nakikita ng backend. Ipapakita ng mga log ang proxy, at anumang tuntunin sa pag-access na batay sa IP sa server ng VPN ay susuriin ang address na iyon sa halip na ang sa kliyente. Ang transparent na pagpapanatili ng pinagmulan ay hiwalay na disenyo ng routing at pribilehiyo, hindi isang bagay na nagmumula sa pagdaragdag ng udp sa isang tagapakinig. Planuhin ito bago isulat ang isang patakarang nakadepende sa address ng kliyente.

Beripikahin mula sa kliyente, hindi mula sa port

Ang lokal na pagsusuring nakabukas ang port ng UDP ay nagpapatunay na may tagapakinig. Hindi nito pinatutunayan na makapagpapatotoo ang isang kliyente sa pamamagitan nito o makapagpapatuloy sa pagpapalitan ng trapiko. Kumpletuhin ang tunay na koneksyon mula sa isang aprubadong kliyente, pagkatapos ay tiyakin na nananatili ang sesyon nang sapat na haba upang maging makabuluhan.

Kapag may nag-ulat na hindi kayang gawin ng Nginx ang UDP dahil gumana sa halip ang isang simpleng kasangkapan sa relay, ang dalawang katotohanang iyon ay walang kaugnayan. Pinatunayan ng kasangkapan na sumasagot ang backend; wala itong sinabi tungkol sa sinusuportahan ng harapang bahagi. Parehong maaaring totoo, at isa lamang sa kanila ang konfigurasyon para sa deployment na ito.