Nginx stream-relay OpenVPN UDP jaoks: mis muutub

UDP ei kuulu HTTP location'isse. Liigutage see stream-kihile, mõõtke sessiooni aegumine VPN-i jaoks ja oodake, et proxy on allikaks.

Teie klient on seatud UDP-le, Nginx serveril on VPN-pordile osutav location-plokk ja midagi ei saabu. See on ootuspärane: HTTP location ei saa UDP-datagrammi kanda, ükskõik kuidas liidest nimetatakse. Selleks vajab Nginx stream-kuulajat ja kui te konfiguratsiooni sinna viite, otsustab teine detailsuste kogum, kas sessioon jääb püsima.

Proxy-kiht tuleb enne aadressi

Nginx stream-moodul proxy'ib TCP-d ja UDP-d ilma HTTP-d parsides. Selle HTTP-moodul ootab päringurida, päiseid ja vastust, ja ühtegi neist ei sisalda tavaline OpenVPN datagramm. Kihi valimine on seega esimene otsus ja see ei sõltu sellest, kas kuulaja on IPv4 või IPv6.

Konfiguratsioon, mis näib töötavat TCP OpenVPN-iga, ei ütle UDP juhu kohta midagi. Transport on siin protokolli osa, mitte juurutuse detail.

Kuulaja ja backend

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

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

Enne millegi muutmist veenduge, et build sisaldab stream-moodulit; distributsioonipakett võib selle eraldi moodulisse jagada ja puuduv moodul annab konfiguratsioonivea, mitte tunnel. Asetage plokk põhikonfiguratsiooni konteksti, mitte http sisse, ja asendage dokumentatsiooni aadress tegeliku backendiga.

Nii mõlemad marsruudid kui ka mõlemad tulemüürid peavad datagrammid läbi laskma: tee kuulajani ja tee proxy'st backendini. IPv6 kuulaja ei loo ka IPv4 teed, nii et kui mõned kliendid kasutavad veel IPv4, on see kuulaja eraldi kirje oma testimisega. Kontrollige backendi enda tulemüüri proxy aadressilt, mitte sülearvutist.

Sessiooni aegumised ei ole päringu aegumised

Stream-proxy hoiab UDP sessiooni olekut ja heidab selle kõrvale oma aegumise ja vastuse seadete järgi. DNS-releest kopeeritud lühike aegumine sobib halvasti VPN-ile, mis loodab datagramme tunde vahetada, ja rike ilmneb ühendusena, mis sureb vaikselt, mitte sellena, mis keeldub käivitumast.

Lugege juurutuse tegelikku proxy_timeout väärtust ja kõiki vastuste arvu seadeid ning võrrelge neid keepalive-käitumisega, mida VPN tegelikult kasutab. Kaks arvu, mille erinevad inimesed erinevatesse failidesse kirjutasid, on töötava süsteemi tavaline seisund. Kaks arvu, mida kunagi ei võrreldud, on katkendliku süsteemi tavaline seisund. Kirjutage mõlemad teenusekirjesse, et võrdlus toimuks üks kord, päevavalguses.

Mida relay muudab ja mida mitte

Stream-proxy ei lõpeta OpenVPN-i TLS juhtkanalit ega muuda seda HTTPS-iks. Backend jääb VPN-teenuseks ja sertifikaadisuhe jääb kliendi ning selle teenuse vahele. Kavatsetud backendi identiteedi hoidmine on endiselt kliendi ja serveri ülesanne.

Tavaline proxy'imine muudab ka allikaaadressi, mida backend näeb. Logid näitavad proxy't ja iga IP-põhine juurdepääsureegel VPN-serveris hindab seda aadressi, mitte kliendi oma. Läbipaistev allika säilitamine on eraldi marsruutimise ja õiguste disain, mitte miski, mis tuleneb udp lisamisest kuulajale. Planeerige seda enne, kui kirjutatakse poliitika, mis sõltub kliendi aadressist.

Kontrollige kliendist, mitte pordist

Kohalik kontroll, et UDP-port on avatud, tõestab, et kuulaja on olemas. See ei tõesta, et klient saab selle kaudu autentida või liiklust edasi vahetada. Tehke tõeline ühendus heakskiidetud kliendist ja kinnitage seejärel, et sessioon püsib piisavalt kaua, et olla oluline.

Kui keegi teatab, et Nginx ei oska UDP-d, sest lihtne relay-tööriist töötas selle asemel, ei ole need kaks fakti seotud. Tööriist tõestas, et backend vastab; see ei öelnud midagi selle kohta, mida liides toetab. Mõlemad võivad olla tõsi ja ainult üks neist on selle juurutuse konfiguratsioon.

Seotud artiklid