Stream-relajso en Nginx por OpenVPN UDP: kion ĝi ŝanĝas

UDP ne apartenas al HTTP-location. Movu ĝin en la tavolon stream, aranĝu la seanco-tempon por VPN, kaj atendu, ke la prokurilo estos la fonto.

Via kliento estas agordita por UDP, la Nginx-servilo havas location-blokon montrantan al la VPN-pordo, kaj nenio alvenas. Tio estas atendebla: HTTP-location ne povas transporti UDP-datagramon, kiel ajn la fasado nomiĝas. Por tio Nginx bezonas stream-auskulton, kaj post kiam vi movas la agordon tien, dua aro da detaloj decidas, ĉu seanco postvivos.

La prokurila tavolo venas antaŭ la adreso

La stream-modulo de Nginx prokuras TCP kaj UDP sen analizi HTTP. Ĝia HTTP-modulo atendas petlinion, kapliniojn kaj respondon, kaj neniom el tio troviĝas en OpenVPN datagramo. Elekti la tavolon do estas la unua decido, kaj ĝi sendependas de tio, ĉu la auskulto estas IPv4 aŭ IPv6.

Agordo, kiu ŝajnas funkcii kun TCP OpenVPN, diras nenion pri la UDP-kazo. La transporto estas ĉi tie parto de la protokolo, ne detalo de la deplojo.

La auskulto kaj la backend

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

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

Konfirmu, ke la konstruaĵo enhavas la stream-modulon antaŭ ol redakti ion; distribua pakaĵo povas apartigi ĝin en apartan modulon, kaj mankanta modulo kaŭzas agordan eraron anstataŭ tunelon. Metu la blokon en la ĉefan agordan kuntekston, ne ene de http, kaj anstataŭigu la dokumentan adreson per la reala backend.

Kaj ambaŭ itineroj kaj ambaŭ fajroŝirmiloj devas permesi la datagramojn: la vojo al la auskulto kaj la vojo de la prokurilo al la backend. IPv6-auskulto ankaŭ ne kreas IPv4-vojon, do se iuj klientoj ankoraŭ uzas IPv4, tiu auskulto estas aparta enskribo kun sia propra testado. Kontrolu la fajroŝirmilon de la backend mem de la adreso de la prokurilo, ne de via tekkomputilo.

Seancaj limtempoj ne estas petaj limtempoj

La stream-prokurilo konservas staton por UDP-seanco kaj forĵetas ĝin laŭ sia limtempo kaj respondaj agordoj. Mallonga limtempo kopiita de DNS-relajso malbone taŭgas por VPN, kiu atendas interŝanĝi datagramojn dum horoj, kaj la paneo aperas kiel konekto, kiu kviete mortas, anstataŭ unu, kiu rifuzas ekfunkcii.

Legu la efektivan proxy_timeout de la deplojo kaj ĉiun agordon pri nombrado de respondoj, poste komparu ilin kun la keepalive-konduto, kiun la VPN efektive uzas. Du nombroj skribitaj en malsamaj dosieroj de malsamaj homoj estas la normala stato de funkcianta sistemo. Du nombroj, kiuj neniam estis komparitaj, estas la normala stato de sistemo kun interrompoj. Skribu ambaŭ en la servan registron, por ke la komparo okazu unufoje, en taglumo.

Kion la relajso ŝanĝas, kaj kion ne

La stream-prokurilo ne finas la TLS-kontrolkanalon de OpenVPN nek konvertas ĝin al HTTPS. La backend restas la VPN-servo, kaj la atestila rilato restas inter la kliento kaj tiu servo. Konservi la celitan backend-identecon restas la tasko de la kliento kaj la servilo.

Ordinara prokurado ankaŭ ŝanĝas la fontan adreson, kiun la backend vidas. Protokoloj montros la prokurilon, kaj ajna IP-bazita alirregulo sur la VPN-servilo taksos tiun adreson anstataŭ tiun de la kliento. Travidebla konservo de la fonto estas aparta projektado de itineroj kaj privilegioj, ne io, kio sekvas el aldono de udp al auskulto. Planu ĝin antaŭ ol politiko dependanta de la klienta adreso estos skribita.

Kontrolu de la kliento, ne de la pordo

Loka kontrolo, ke la UDP-pordo estas malfermita, pruvas, ke la auskulto ekzistas. Ĝi ne pruvas, ke kliento povas aŭtentigi tra ĝi aŭ daŭrigi interŝanĝi trafikon. Plenumu realan konekton de aprobita kliento, poste konfirmu, ke la seanco restas sufiĉe longe por havi signifon.

Kiam iu raportas, ke Nginx ne povas UDP ĉar simpla relajsa ilo funkciis anstataŭe, la du faktoj estas nerilataj. La ilo pruvis, ke la backend respondas; ĝi diris nenion pri tio, kion subtenas la fasado. Ambaŭ povas esti veraj, kaj nur unu el ili estas agordo por ĉi tiu deplojo.

Rilataj artikoloj