Relay stream në Nginx për UDP-në e OpenVPN: çfarë ndryshon

Klienti juaj është vendosur në UDP, serveri Nginx ka një bllok location që tregon portin e VPN-së, dhe asgjë nuk arrin. Kjo është e pritshme: një location HTTP nuk mund të mbajë një datagram UDP, sido që të quhet pjesa e përparme. Nginx ka nevojë për një dëgjues stream për këtë, dhe pasi konfigurimin ta zhvendosni atje, një grup i dytë detajesh vendos nëse sesioni mbijeton.

Shtresa proxy vjen përpara adresës

Moduli stream i Nginx bën proxy për TCP dhe UDP pa analizuar HTTP. Moduli i tij HTTP pret një rresht kërkese, titujt dhe një përgjigje, dhe asnjë prej tyre nuk gjendet në një OpenVPN datagram vendas. Zgjedhja e shtresës është pra vendimi i parë, dhe është i pavarur nga fakti nëse dëgjuesi është IPv4 apo IPv6.

Një konfigurim që duket se funksionon me OpenVPN në TCP nuk thotë asgjë për rastin UDP. Transporti është këtu pjesë e protokollit, jo një detaj i vendosjes.

Dëgjuesi dhe backend-i

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

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

Verifikoni që ndërtimi përfshin modulin stream përpara se të modifikoni diçka; një paketë shpërndarjeje mund ta ndajë atë në një modul të veçantë, dhe një modul që mungon prodhon një gabim konfigurimi në vend të një tuneli. Vendoseni bllokun në kontekstin kryesor të konfigurimit, jo brenda http, dhe zëvendësoni adresën e dokumentacionit me backend-in e vërtetë.

Si të dy rrugët ashtu edhe të dy firewall-et duhet të lejojnë datagramet: rruga drejt dëgjuesit dhe rruga nga proxy drejt backend-it. Një dëgjues IPv6 gjithashtu nuk krijon një rrugë IPv4, kështu që nëse disa klientë përdorin ende IPv4, ai dëgjues është një zë i veçantë me testet e veta. Kontrolloni firewall-in e vetë backend-it nga adresa e proxy-t, jo nga laptopi juaj.

Afatet e sesionit nuk janë afate kërkese

Proxy stream mban gjendjen për një sesion UDP dhe e hedh atë sipas afatit dhe cilësimeve të përgjigjes. Një afat i shkurtër i kopjuar nga një relay DNS përshtatet keq me një VPN që pret të shkëmbejë datagrame për orë të tëra, dhe defekti shfaqet si një lidhje që vdes në heshtje, jo si një që refuzon të nisë.

Lexoni proxy_timeout efektiv të vendosjes dhe çdo cilësim të numërimit të përgjigjeve, pastaj krahasoni ato me sjelljen keepalive që VPN përdor në të vërtetë. Dy numra të shkruar në skedarë të ndryshëm nga njerëz të ndryshëm janë gjendja normale e një sistemi që funksionon. Dy numra që nuk janë krahasuar kurrë janë gjendja normale e një sistemi me ndërprerje. Shkruajini të dy në regjistrin e shërbimit, që krahasimi të ndodhë një herë, në dritën e ditës.

Çfarë ndryshon relay-i dhe çfarë jo

Proxy stream nuk e përfundon kanalin e kontrollit TLS të OpenVPN dhe nuk e kthen atë në HTTPS. Backend-i mbetet shërbimi VPN, dhe marrëdhënia e certifikatës mbetet midis klientit dhe atij shërbimi. Ruajtja e identitetit të synuar të backend-it mbetet detyrë e klientit dhe serverit.

Proxy-ja e zakonshme ndryshon gjithashtu adresën e burimit që sheh backend-i. Regjistrat do të tregojnë proxy-n, dhe çdo rregull hyrjeje i bazuar në IP në serverin VPN do të vlerësojë atë adresë në vend të asaj të klientit. Ruajtja transparente e burimit është një dizajn i veçantë rrugëtimi dhe privilegjesh, jo diçka që rrjedh nga shtimi i udp në një dëgjues. Planifikojeni përpara se të shkruhet një politikë që varet nga adresa e klientit.

Verifikoni nga klienti, jo nga porta

Një kontroll lokal që porta UDP është e hapur provon se dëgjuesi ekziston. Nuk provon se një klient mund të autentifikohet përmes saj ose të vazhdojë të shkëmbejë trafik. Përfundoni një lidhje reale nga një klient i miratuar, më pas konfirmoni që sesioni mbetet mjaft gjatë për të pasur rëndësi.

Kur dikush raporton se Nginx nuk mund të bëjë UDP sepse në vend të tij funksionoi një mjet i thjeshtë relay, këto dy fakte nuk lidhen. Mjeti provoi se backend-i përgjigjet; nuk tha asgjë për atë që mbështet pjesa e përparme. Të dyja mund të jenë të vërteta, dhe vetëm njëra prej tyre është konfigurim për këtë vendosje.