Stream relay v Nginxu za OpenVPN UDP: kaj spremeni

Vaš odjemalec je nastavljen na UDP, strežnik Nginx ima blok location, ki kaže na vrata VPN, in nič ne pride. To je pričakovano: location HTTP ne more prenesti datagrama UDP, kakorkoli se imenuje sprednji del. Za to Nginx potrebuje poslušalec stream, in ko konfiguracijo premaknete tja, o tem, ali bo seja preživela, odloča drug nabor podrobnosti.

Plast proxy pride pred naslovom

Modul stream v Nginxu posreduje TCP in UDP, ne da bi razčlenil HTTP. Njegov modul HTTP pričakuje vrstico zahteve, glave in odgovor, in nič od tega ni v izvornem OpenVPN datagramu. Izbira plasti je zato prva odločitev in ni odvisna od tega, ali je poslušalec IPv4 ali IPv6.

Konfiguracija, ki se zdi, da deluje s TCP OpenVPN, o primeru UDP ne pove nič. Transport je tu del protokola, ne podrobnost uvedbe.

Poslušalec in backend

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

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

Preden karkoli urejate, preverite, ali build vključuje modul stream; distribucijski paket ga lahko razdeli v ločen modul, manjkajoč modul pa povzroči konfiguracijsko napako, ne tunela. Blok postavite v glavni kontekst konfiguracije, ne znotraj http, in zamenjajte dokumentacijski naslov z resničnim backendom.

Tako obe poti kot oba požarna zidova morata prepustiti datagrame: pot do poslušalca in pot od proxyja do backenda. Poslušalec IPv6 tudi ne ustvari poti IPv4, zato je, če nekateri odjemalci še uporabljajo IPv4, ta poslušalec ločen vnos z lastnim testiranjem. Preverite požarni zid samega backenda z naslova proxyja, ne s prenosnika.

Časovne omejitve seje niso časovne omejitve zahteve

Proxy stream hrani stanje seje UDP in ga zavrže skladno s svojo časovno omejitvijo in nastavitvami odgovora. Kratka omejitev, kopirana iz relayja DNS, se slabo prilega VPN, ki pričakuje izmenjavo datagramov ure in ure, napaka pa se pokaže kot povezava, ki tiho umre, ne kot tista, ki noče začeti.

Preberite dejansko proxy_timeout uvedbe in vsako nastavitev štetja odgovorov, nato ju primerjajte z vedenjem keepalive, ki ga VPN dejansko uporablja. Dve števili, ki sta ju različni osebi zapisali v različnih datotekah, sta običajno stanje delujočega sistema. Dve števili, ki nikoli nista bili primerjani, sta običajno stanje sistema, ki občasno odpove. Zapišite oba v servisni zapis, da se primerjava zgodi enkrat, na dnevni svetlobi.

Kaj relay spremeni in česa ne

Proxy stream ne zaključi krmilnega kanala TLS OpenVPN in ga ne pretvori v HTTPS. Backend ostane storitev VPN, razmerje potrdila pa ostane med odjemalcem in to storitvijo. Ohranjanje predvidene identitete backenda je še vedno naloga odjemalca in strežnika.

Običajno posredovanje spremeni tudi naslov vira, ki ga vidi backend. Dnevniki bodo pokazali proxy, in vsako pravilo dostopa na podlagi IP na strežniku VPN bo ocenilo ta naslov namesto odjemalčevega. Pregledno ohranjanje vira je ločen načrt usmerjanja in pravic, ne nekaj, kar izhaja iz dodajanja udp poslušalcu. Načrtujte to, preden bo napisana politika, ki je odvisna od naslova odjemalca.

Preverjajte z odjemalca, ne z vrat

Lokalno preverjanje, da so vrata UDP odprta, dokaže, da poslušalec obstaja. Ne dokaže, da se odjemalec lahko prek njih overi ali nadaljuje z izmenjavo prometa. Dokončajte resnično povezavo z odobrenega odjemalca in nato potrdite, da seja ostane dovolj dolgo, da je pomembna.

Ko nekdo poroča, da Nginx ne zmore UDP, ker je namesto njega delovalo preprosto orodje relay, ti dve dejstvi nista povezani. Orodje je dokazalo, da backend odgovarja; ni povedalo ničesar o tem, kaj podpira sprednji del. Oboje je lahko res in le eno od tega je konfiguracija za to uvedbo.