Nginx stream relė OpenVPN UDP: ką ji keičia

Jūsų klientas nustatytas UDP, Nginx serveryje yra location blokas, nukreiptas į VPN portą, o niekas neateina. Tai tikėtina: HTTP location negali pernešti UDP datagramos, kad ir kaip būtų vadinama priekinė dalis. Tam Nginx reikia stream klausytojo, o perkėlus konfigūraciją ten, ar sesija išliks, sprendžia antra detalių grupė.

Proxy sluoksnis ateina prieš adresą

Nginx stream modulis proxina TCP ir UDP neanalizuodamas HTTP. Jo HTTP modulis tikisi užklausos eilutės, antraščių ir atsakymo, ir nė vieno jų nėra OpenVPN datagramoje. Todėl sluoksnio pasirinkimas yra pirmasis sprendimas, ir jis nepriklauso nuo to, ar klausytojas yra IPv4, ar IPv6.

Konfigūracija, kuri atrodo veikianti su TCP OpenVPN, nieko nesako apie UDP atvejį. Transportas čia yra protokolo dalis, o ne diegimo detalė.

Klausytojas ir backend

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

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

Prieš ką nors redaguodami įsitikinkite, kad build turi stream modulį; platinimo paketas gali jį išskaidyti į atskirą modulį, o trūkstamas modulis duoda konfigūracijos klaidą, o ne tunelį. Įdėkite bloką į pagrindinį konfigūracijos kontekstą, o ne į http, ir pakeiskite dokumentacijos adresą tikruoju backend.

Abu maršrutai ir abi ugniasienės turi praleisti datagramas: kelias iki klausytojo ir kelias nuo proxy iki backend. IPv6 klausytojas taip pat nesukuria IPv4 kelio, tad jei kai kurie klientai dar naudoja IPv4, tas klausytojas yra atskiras įrašas su savo testavimu. Tikrinkite backend ugniasienę iš proxy adreso, o ne iš savo nešiojamojo kompiuterio.

Sesijos skirtieji laikai nėra užklausos skirtieji laikai

stream proxy saugo UDP sesijos būseną ir ją išmeta pagal savo skirtąjį laiką bei atsakymo nustatymus. Trumpas skirtasis laikas, nukopijuotas iš DNS relės, netinka VPN, kuris tikisi valandų valandas keistis datagramomis, o gedimas pasirodo kaip tyliai mirštantis ryšys, o ne toks, kuris atsisako pradėti.

Perskaitykite diegimo faktinį proxy_timeout ir bet kurį atsakymų skaičiaus nustatymą, tada palyginkite juos su keepalive elgsena, kurią VPN iš tikrųjų naudoja. Du skaičiai, kuriuos skirtingi žmonės parašė skirtinguose failuose, yra normali veikiančios sistemos būsena. Du skaičiai, kurie niekada nebuvo palyginti, yra normali protarpiais veikiančios sistemos būsena. Įrašykite abu į paslaugos įrašą, kad palyginimas įvyktų vieną kartą, dienos šviesoje.

Ką relė keičia, o ko ne

stream proxy nebaigia OpenVPN TLS valdymo kanalo ir nekonvertuoja jo į HTTPS. Backend lieka VPN paslauga, o sertifikato ryšys lieka tarp kliento ir tos paslaugos. Numatytos backend tapatybės išsaugojimas vis dar yra kliento ir serverio darbas.

Įprastas proxinimas taip pat keičia šaltinio adresą, kurį mato backend. Žurnalai rodys proxy, o bet kuri IP pagrindu veikianti prieigos taisyklė VPN serveryje vertins tą adresą, o ne kliento. Skaidrus šaltinio išsaugojimas yra atskiras maršrutizavimo ir privilegijų dizainas, o ne tai, kas atsiranda pridėjus udp prie klausytojo. Suplanuokite tai prieš rašant politiką, kuri priklauso nuo kliento adreso.

Tikrinkite iš kliento, o ne iš porto

Vietinė patikra, kad UDP portas atidarytas, įrodo, kad klausytojas egzistuoja. Ji neįrodo, kad klientas gali per jį autentifikuotis ar toliau keistis srautu. Užbaikite tikrą ryšį iš patvirtinto kliento, tada patvirtinkite, kad sesija išlieka pakankamai ilgai, kad tai turėtų prasmę.

Kai kas nors praneša, kad Nginx negali UDP, nes vietoj jo suveikė paprastas relės įrankis, šie du faktai nesusiję. Įrankis įrodė, kad backend atsako; jis nieko nesakė apie tai, ką palaiko priekinė dalis. Abu gali būti tiesa, ir tik vienas iš jų yra šio diegimo konfigūracija.