Nginx stream-relay OpenVPN UDP-hez: mit változtat

A kliense UDP-re van állítva, az Nginx kiszolgálón van egy location blokk, amely a VPN portjára mutat, és mégsem érkezik semmi. Ez várható: egy HTTP location nem tud UDP-datagramot szállítani, bármilyen nevet is kap a front end. Az Nginxnek ehhez stream-figyelőre van szüksége, és miután a konfigurációt odaköltözteti, a részletek második csoportja dönti el, túlél-e a munkamenet.

A proxy réteg megelőzi a címet

Az Nginx stream modulja HTTP-elemzés nélkül proxyz TCP-t és UDP-t. A HTTP modulja kérés sort, fejléceket és választ vár, és ezek egyike sem található egy natív OpenVPN datagramban. A réteg kiválasztása tehát az első döntés, és független attól, hogy a figyelő IPv4 vagy IPv6.

Egy konfiguráció, amely TCP OpenVPN-nel működni látszik, semmit sem mond az UDP esetéről. A szállítás itt a protokoll része, nem a telepítés részlete.

A figyelő és a backend

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

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

Mielőtt bármit szerkesztene, ellenőrizze, hogy a build tartalmazza-e a stream modult; egy disztribúciós csomag külön modulba teheti, és a hiányzó modul konfigurációs hibát okoz, nem alagutat. Helyezze a blokkot a fő konfigurációs környezetbe, ne a http belsejébe, és cserélje ki a dokumentációs címet a valódi backendre.

Mindkét útvonalnak és mindkét tűzfalnak át kell engednie a datagramokat: a figyelőhöz vezető útnak és a proxytól a backendig vezető útnak. Az IPv6 figyelő sem hoz létre IPv4 utat, tehát ha egyes kliensek még IPv4-et használnak, az a figyelő külön bejegyzés a saját tesztelésével. A backend saját tűzfalát a proxy címéről ellenőrizze, ne a laptopjáról.

A munkamenet időtúllépései nem kérés-időtúllépések

A stream proxy állapotot tart egy UDP munkamenethez, és azt az időtúllépése és válaszbeállításai szerint dobja el. A DNS-relayből másolt rövid időtúllépés rosszul illik egy VPN-hez, amely órákon át akar datagramokat cserélni, és a hiba csendben meghaló kapcsolatként jelenik meg, nem olyanként, amely megtagadja az indulást.

Olvassa el a telepítés tényleges proxy_timeout értékét és bármilyen válaszszámláló beállítást, majd hasonlítsa össze őket azzal a keepalive-viselkedéssel, amelyet a VPN valóban használ. Két szám, amelyet különböző emberek különböző fájlokba írtak, egy működő rendszer normál állapota. Két szám, amelyet soha nem hasonlítottak össze, egy szakaszosan akadozó rendszer normál állapota. Írja mindkettőt a szolgáltatási nyilvántartásba, hogy az összehasonlítás egyszer, napvilágnál megtörténjen.

Mit változtat a relay, és mit nem

A stream proxy nem bontja le az OpenVPN TLS vezérlőcsatornáját, és nem alakítja HTTPS-sé. A backend marad a VPN szolgáltatás, és a tanúsítvány kapcsolata a kliens és e szolgáltatás között marad. A szándékolt backend-identitás megőrzése továbbra is a kliens és a kiszolgáló feladata.

A szokásos proxyzás a backend által látott forráscímet is megváltoztatja. A naplók a proxyt mutatják, és a VPN-kiszolgáló bármely IP-alapú hozzáférési szabálya ezt a címet értékeli a kliensé helyett. Az átlátható forrásmegőrzés külön útvonalválasztási és jogosultsági tervezés, nem pedig valami, ami a udp figyelőhöz adásából következik. Tervezze meg, mielőtt olyan szabályzatot írnak, amely a kliens címétől függ.

A kliensről ellenőrizze, ne a portról

Egy helyi ellenőrzés, hogy az UDP port nyitva van, bizonyítja, hogy a figyelő létezik. Nem bizonyítja, hogy egy kliens képes rajta keresztül hitelesíteni vagy tovább cserélni a forgalmat. Hozzon létre valódi kapcsolatot egy jóváhagyott kliensről, majd erősítse meg, hogy a munkamenet elég sokáig fennmarad, hogy számítson.

Amikor valaki azt jelenti, hogy az Nginx nem tud UDP-t, mert helyette egy egyszerű relay-eszköz működött, a két tény nem függ össze. Az eszköz bebizonyította, hogy a backend válaszol; semmit nem mondott arról, mit támogat a front end. Mindkettő igaz lehet, és közülük csak az egyik konfiguráció ehhez a telepítéshez.