Nginx stream starpnieks OpenVPN UDP: ko tas maina

Jūsu klients ir iestatīts uz UDP, Nginx serverim ir location bloks, kas norāda uz VPN portu, un nekas nenāk. Tas ir gaidāmi: HTTP location nevar pārnest UDP datagrammu, lai kā arī sauktu priekšējo daļu. Tam Nginx vajag stream klausītāju, un pēc konfigurācijas pārvietošanas tur, vai sesija izdzīvos, izlemj otra detaļu kopa.

Starpnieka slānis nāk pirms adreses

Nginx stream modulis starpnieko TCP un UDP, neanalizējot HTTP. Tā HTTP modulis gaida pieprasījuma rindu, galvenes un atbildi, un neviens no tiem nav OpenVPN datagrammā. Tāpēc slāņa izvēle ir pirmais lēmums, un tas nav atkarīgs no tā, vai klausītājs ir IPv4 vai IPv6.

Konfigurācija, kas šķiet strādājam ar TCP OpenVPN, neko nepasaka par UDP gadījumu. Transports šeit ir protokola daļa, nevis izvietošanas detaļa.

Klausītājs un backend

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

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

Pirms kaut ko rediģējat, pārliecinieties, ka build ietver stream moduli; izplatīšanas pakotne var to atdalīt atsevišķā modulī, un trūkstošs modulis dod konfigurācijas kļūdu, nevis tuneli. Ievietojiet bloku galvenajā konfigurācijas kontekstā, nevis http iekšienē, un aizstājiet dokumentācijas adresi ar īsto backend.

Gan abiem maršrutiem, gan abiem ugunsmūriem jāļauj datagrammas: ceļš līdz klausītājam un ceļš no starpnieka līdz backend. IPv6 klausītājs arī neveido IPv4 ceļu, tāpēc, ja daži klienti joprojām izmanto IPv4, šis klausītājs ir atsevišķs ieraksts ar savu testēšanu. Pārbaudiet backend ugunsmūri no starpnieka adreses, nevis no sava portatīvā datora.

Sesijas taimauti nav pieprasījuma taimauti

stream starpnieks uztur UDP sesijas stāvokli un izmet to pēc sava taimauta un atbildes iestatījumiem. Īss taimauts, kas nokopēts no DNS starpnieka, slikti atbilst VPN, kas paredz stundām ilgi apmainīties ar datagrammām, un kļūme izpaužas kā savienojums, kas klusi mirst, nevis tāds, kas atsakās sākt.

Izlasiet izvietošanas faktisko proxy_timeout un jebkuru atbilžu skaitīšanas iestatījumu, pēc tam salīdziniet tos ar keepalive uzvedību, ko VPN faktiski izmanto. Divi skaitļi, ko dažādi cilvēki ierakstījuši dažādos failos, ir strādājošas sistēmas normāls stāvoklis. Divi skaitļi, kas nekad nav salīdzināti, ir periodiski sabrūkošas sistēmas normāls stāvoklis. Ierakstiet abus pakalpojuma ierakstā, lai salīdzināšana notiktu vienreiz, dienasgaismā.

Ko starpnieks maina un ko ne

stream starpnieks neizbeidz OpenVPN TLS vadības kanālu un nepārvērš to HTTPS. Backend paliek VPN pakalpojums, un sertifikāta attiecības paliek starp klientu un šo pakalpojumu. Paredzētās backend identitātes saglabāšana joprojām ir klienta un servera darbs.

Parastā starpniekošana maina arī avota adresi, ko redz backend. Žurnāli rādīs starpnieku, un jebkurš uz IP balstīts piekļuves noteikums VPN serverī novērtēs šo adresi, nevis klienta. Caurspīdīga avota saglabāšana ir atsevišķs maršrutēšanas un privilēģiju dizains, nevis kaut kas, kas izriet no udp pievienošanas klausītājam. Plānojiet to pirms politikas, kas atkarīga no klienta adreses, rakstīšanas.

Pārbaudiet no klienta, ne no porta

Vietēja pārbaude, ka UDP ports ir atvērts, pierāda, ka klausītājs pastāv. Tā nepierāda, ka klients var autentificēties caur to vai turpināt apmainīties ar trafiku. Pabeidziet reālu savienojumu no apstiprināta klienta, tad apstipriniet, ka sesija saglabājas pietiekami ilgi, lai tam būtu nozīme.

Kad kāds ziņo, ka Nginx nevar UDP, jo tā vietā nostrādāja vienkāršs starpnieka rīks, šie divi fakti nav saistīti. Rīks pierādīja, ka backend atbild; tas neko neteica par to, ko atbalsta priekšējā daļa. Abi var būt patiesi, un tikai viens no tiem ir šīs izvietošanas konfigurācija.