Nginxin stream-välitys OpenVPN UDP:lle: mitä se muuttaa

Asiakkaasi on asetettu UDP:hen, Nginx-palvelimella on VPN-porttiin osoittava location-lohko, eikä mitään saavu. Se on odotettua: HTTP location ei voi kuljettaa UDP-datagrammia, millä nimellä etupää sitten kulkeekin. Siihen Nginx tarvitsee stream-kuuntelijan, ja kun siirrät kokoonpanon sinne, toinen yksityiskohtien joukko ratkaisee, selviääkö istunto.

Proxy-kerros tulee ennen osoitetta

Nginxin stream-moduuli välittää TCP:tä ja UDP:tä jäsentämättä HTTP:tä. Sen HTTP-moduuli odottaa pyyntöriviä, otsakkeita ja vastausta, eikä mitään niistä ole natiivissa OpenVPN-datagrammissa. Kerroksen valinta on siksi ensimmäinen päätös, eikä se riipu siitä, onko kuuntelija IPv4 vai IPv6.

Kokoonpano, joka näyttää toimivan TCP OpenVPN:n kanssa, ei kerro mitään UDP-tapauksesta. Siirto on tässä osa protokollaa, ei käyttöönoton yksityiskohta.

Kuuntelija ja backend

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

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

Varmista ennen muokkaamista, että build sisältää stream-moduulin; jakelupaketti voi erottaa sen omaksi moduulikseen, ja puuttuva moduuli tuottaa kokoonpanovirheen eikä tunnelia. Sijoita lohko pääkokoonpanon kontekstiin, ei http sisään, ja korvaa dokumentaatio-osoite oikealla backendillä.

Sekä molempien reittien että molempien palomuurien on sallittava datagrammit: polku kuuntelijalle ja polku proxylta backendille. IPv6-kuuntelija ei myöskään luo IPv4-polkua, joten jos jotkin asiakkaat käyttävät yhä IPv4:ää, kyseinen kuuntelija on erillinen merkintä omine testeineen. Tarkista backendarin oma palomuuri proxyn osoitteesta, älä kannettavaltasi.

Istunnon aikakatkaisut eivät ole pyynnön aikakatkaisuja

Stream-proxy pitää UDP-istunnon tilaa ja hylkää sen aikakatkaisunsa ja vastausasetustensa mukaisesti. DNS-välityksestä kopioitu lyhyt aikakatkaisu sopii huonosti VPN:lle, joka odottaa vaihtavansa datagrammeja tunteja, ja vika näkyy yhteytenä, joka kuolee hiljaa, eikä sellaisena, joka kieltäytyy käynnistymästä.

Lue käyttöönoton tehokas proxy_timeout ja mahdollinen vastausmäärän asetus ja vertaa niitä keepalive-käyttäytymiseen, jota VPN todella käyttää. Kaksi lukua, jotka eri ihmiset kirjoittivat eri tiedostoihin, on toimivan järjestelmän normaali tila. Kaksi lukua, joita ei koskaan verrattu, on ajoittain pettävän järjestelmän normaali tila. Kirjoita molemmat palvelukirjaan, jotta vertailu tapahtuu kerran, päivänvalossa.

Mitä välitys muuttaa ja mitä ei

Stream-proxy ei lopeta OpenVPN:n TLS-ohjauskanavaa eikä muunna sitä HTTPS:ksi. Backend on edelleen VPN-palvelu, ja sertifikaattisuhde pysyy asiakkaan ja tuon palvelun välillä. Aiottuun backendarin identiteettiin pitäytyminen on edelleen asiakkaan ja palvelimen työtä.

Tavallinen välitys muuttaa myös sitä lähdeosoitetta, jonka backend näkee. Lokit näyttävät proxyn, ja mikä tahansa IP-perusteinen käyttösääntö VPN-palvelimella arvioi tuota osoitetta asiakkaan osoitteen sijaan. Lähteen läpinäkyvä säilyttäminen on erillinen reititys- ja käyttöoikeussuunnitelma, ei jotain, mikä seuraa udp lisäämisestä kuuntelijalle. Suunnittele se ennen kuin kirjoitetaan käytäntö, joka riippuu asiakkaan osoitteesta.

Varmista asiakkaalta, älä portilta

Paikallinen tarkistus siitä, että UDP-portti on auki, todistaa kuuntelijan olemassaolon. Se ei todista, että asiakas voi tunnistautua sen kautta tai jatkaa liikenteen vaihtamista. Tee todellinen yhteys hyväksytystä asiakkaasta ja vahvista sitten, että istunto pysyy pystyssä riittävän kauan ollakseen merkityksellinen.

Kun joku kertoo, että Nginx ei osaa UDP:tä, koska yksinkertainen välitystyökalu toimi sen sijaan, nämä kaksi tosiasiaa eivät liity toisiinsa. Työkalu todisti, että backend vastaa; se ei sanonut mitään siitä, mitä etupää tukee. Molemmat voivat olla totta, ja vain toinen niistä on tämän käyttöönoton kokoonpano.