Stream relay v Nginx pro OpenVPN UDP: co mění

UDP nepatří do HTTP location. Přesuňte ho do vrstvy stream, nastavte časový limit relace pro VPN a počítejte s proxy jako zdrojem.

Klient je nastaven na UDP, server Nginx má blok location ukazující na port VPN a nic nedorazí. To se dá čekat: HTTP location nemůže přenést UDP datagram, ať se front end jmenuje jakkoli. Nginx na to potřebuje stream listener a jakmile tam konfiguraci přesunete, o tom, zda relace přežije, rozhoduje druhá sada detailů.

Proxy vrstva přichází před adresou

Modul stream v Nginx proxuje TCP i UDP, aniž by parsoval HTTP. Jeho HTTP modul očekává požadavek, hlavičky a odpověď, což v nativním OpenVPN datagramu není. Volba vrstvy je proto první rozhodnutí a nezávisí na tom, zda je listener IPv4, nebo IPv6.

Konfigurace, která vypadá, že funguje s TCP OpenVPN, o případě UDP neříká nic. Transport je tu součástí protokolu, ne detailem nasazení.

Listener a backend

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

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

Než cokoli upravíte, ověřte, že build obsahuje modul stream; distribuční balíček ho může rozdělit do samostatného modulu a chybějící modul vyprodukuje chybu konfigurace, nikoli tunel. Umístěte blok do hlavního kontextu konfigurace, ne dovnitř http, a dokumentační adresu nahraďte skutečným backendem.

Obě trasy i oba firewally musí datagramy propustit: cestu k listeneru a cestu z proxy do backendu. Listener IPv6 také nevytváří cestu IPv4, takže pokud někteří klienti stále používají IPv4, je takový listener samostatná položka s vlastním testováním. Firewall samotného backendu ověřte z adresy proxy, ne ze svého notebooku.

Časové limity relace nejsou časovými limity požadavku

Proxy stream drží stav UDP relace a zahazuje ho podle svého časového limitu a nastavení odpovědí. Krátký limit zkopírovaný z DNS relaye se k VPN, která chce vyměňovat datagramy celé hodiny, nehodí, a selhání se projeví jako spojení, které tiše umírá, nikoli jako to, které odmítá začít.

Přečtěte si efektivní proxy_timeout nasazení a jakékoli nastavení počtu odpovědí, pak je porovnejte s chováním keepalive, které VPN skutečně používá. Dvě čísla napsaná v různých souborech různými lidmi jsou normálním stavem fungujícího systému. Dvě čísla, která se nikdy neporovnala, jsou normálním stavem občasně selhávajícího systému. Zapište obě do servisního záznamu, aby se porovnání stalo jednou, za denního světla.

Co relay mění a co ne

Proxy stream neukončuje řídicí kanál TLS OpenVPN ani ho nemění na HTTPS. Backend zůstává službou VPN a vztah certifikátů zůstává mezi klientem a touto službou. Zachování zamýšlené identity backendu je stále úkolem klienta a serveru.

Běžné proxování také mění zdrojovou adresu, kterou backend vidí. Logy ukážou proxy a jakékoli pravidlo přístupu podle IP na serveru VPN vyhodnotí tuto adresu místo adresy klienta. Transparentní zachování zdroje je samostatný návrh routingu a oprávnění, ne něco, co plyne z přidání udp k listeneru. Naplánujte to dřív, než vznikne politika závislá na adrese klienta.

Ověřujte z klienta, ne z portu

Místní kontrola, že je UDP port otevřený, dokazuje, že listener existuje. Nedokazuje, že se přes něj klient dokáže autentizovat nebo dál vyměňovat provoz. Dokončete skutečné spojení ze schváleného klienta a pak potvrďte, že relace vydrží dost dlouho, aby to mělo význam.

Když někdo hlásí, že Nginx neumí UDP, protože místo něj fungoval jednoduchý relay nástroj, obě skutečnosti spolu nesouvisejí. Nástroj dokázal, že backend odpovídá; neřekl nic o tom, co podporuje front end. Obě může být pravda a jen jedna z nich je konfigurace pro toto nasazení.

Související články