Nginx stream-relay fyrir OpenVPN UDP: hvað það breytir

Biðlarinn þinn er stilltur á UDP, Nginx-þjónninn er með location-blokk sem bendir á VPN-portið, og ekkert kemur. Það er viðbúið: HTTP-location getur ekki flutt UDP-datagram, hvað sem framendinn heitir. Nginx þarf stream-hlustun fyrir þetta, og þegar þú færir stillingarnar þangað ákveður önnur röð smáatriða hvort lotan lifir af.

Proxy-lagið kemur á undan vistfanginu

stream-eining Nginx proxyar TCP og UDP án þess að þátta HTTP. HTTP-einingin býst við beiðnilínu, hausum og svari, og ekkert þess er í OpenVPN datagrami. Að velja lagið er því fyrsta ákvörðunin, og hún er óháð því hvort hlustunin er IPv4 eða IPv6.

Stilling sem virðist virka með TCP OpenVPN segir ekkert um UDP-tilvikið. Flutningurinn er hér hluti af samskiptareglunum, ekki smáatriði í uppsetningunni.

Hlustunin og bakendinn

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

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

Staðfestu að smíðin innihaldi stream-eininguna áður en þú breytir nokkru; dreifingarpakki getur skipt henni út í aðra einingu, og eining sem vantar gefur stillingarvillu frekar en göng. Settu blokkina í aðalstillingarsamhengið, ekki inni í http, og skiptu skjölunar-vistfanginu út fyrir raunverulega bakendann.

Bæði leiðirnar og báðir eldveggirnir verða að hleypa datagrammunum í gegn: leiðin að hlustuninni og leiðin frá proxýinu að bakendanum. IPv6-hlustun býr heldur ekki til IPv4-leið, svo ef sumir biðlarar nota enn IPv4 er sú hlustun sérstök færsla með eigin prófun. Athugaðu eldvegg bakendans sjálfs frá vistfangi proxýsins, ekki frá fartölvunni þinni.

Lotutímar eru ekki beiðnitímar

stream-proxy heldur stöðu fyrir UDP-lotu og hendir henni samkvæmt tímanum og svarstillingunum. Stuttur tími sem afritaður er frá DNS-relay hentar illa fyrir VPN sem ætlar að skiptast á datagrammum í klukkustundir, og bilunin birtist sem tenging sem deyr hljóðlega frekar en sú sem neitar að byrja.

Lestu raunverulega proxy_timeout uppsetningarinnar og hvaða stillingu sem er fyrir fjölda svara, og berðu þær svo saman við keepalive-hegðunina sem VPNið notar í raun. Tvær tölur sem ólíkir einstaklingar skrifuðu í ólíkar skrár eru eðlilegt ástand kerfis sem virkar. Tvær tölur sem aldrei voru bornar saman eru eðlilegt ástand kerfis sem slitnar. Skrifaðu báðar í þjónustuskrána svo samanburðurinn eigi sér stað einu sinni, í dagsljósi.

Hvað relayið breytir og hvað ekki

stream-proxyð lýkur ekki TLS-stýrikerfi OpenVPN og breytir því ekki í HTTPS. Bakendinn er áfram VPN-þjónustan, og skírteinissambandið er áfram milli biðlarans og þeirrar þjónustu. Að varðveita fyrirhugaða auðkenni bakendans er áfram verk biðlarans og þjónsins.

Venjulegt proxýing breytir líka upprunavistfanginu sem bakendinn sér. Annálar munu sýna proxýið, og hver IP-tengd aðgangsregla á VPN-þjóninum metur það vistfang í stað biðlarans. Gagnsæ varðveisla uppruna er sérstök hönnun leiðar og réttinda, ekki eitthvað sem leiðir af því að bæta udp við hlustun. Skipuleggðu það áður en stefna sem byggir á vistfangi biðlarans er skrifuð.

Sannreynið frá biðlinum, ekki frá portinu

Staðbundin athugun á því að UDP-portið sé opið sannar að hlustunin sé til. Hún sannar ekki að biðlari geti auðkennt sig í gegnum hana eða haldið áfram að skiptast á umferð. Ljúktu raunverulegri tengingu frá samþykktum biðlara og staðfestu síðan að lotan haldist nógu lengi til að skipta máli.

Þegar einhver segir að Nginx geti ekki UDP vegna þess að einfalt relay-tól virkaði í staðinn eru þessar tvær staðreyndir ótengdar. Tólið sannaði að bakendinn svarar; það sagði ekkert um hvað framendinn styður. Bæði geta verið satt, og aðeins annað þeirra er stilling fyrir þessa uppsetningu.