Stream relay v Nginx pre OpenVPN UDP: čo mení

UDP nepatrí do HTTP location. Presuňte ho do vrstvy stream, nastavte časový limit relácie pre VPN a počítajte s tým, že zdrojom bude proxy.

Klient je nastavený na UDP, server Nginx má blok location ukazujúci na port VPN a nič neprichádza. To sa dá očakávať: HTTP location nemôže preniesť UDP datagram, nech sa front end volá akokoľvek. Nginx na to potrebuje stream listener a po presunutí konfigurácie tam o tom, či relácia prežije, rozhoduje druhá sada detailov.

Proxy vrstva prichádza pred adresou

Modul stream v Nginx proxuje TCP aj UDP bez parsovania HTTP. Jeho HTTP modul očakáva riadok požiadavky, hlavičky a odpoveď, a nič z toho nie je v natívnom OpenVPN datagrame. Voľba vrstvy je preto prvé rozhodnutie a nezávisí od toho, či je listener IPv4 alebo IPv6.

Konfigurácia, ktorá vyzerá, že funguje s TCP OpenVPN, o prípade UDP nehovorí nič. Transport je tu súčasťou protokolu, nie detailom nasadenia.

Listener a backend

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

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

Pred akoukoľvek úpravou overte, že build obsahuje modul stream; distribučný balík ho môže rozdeliť do samostatného modulu a chýbajúci modul vyprodukuje chybu konfigurácie, nie tunel. Umiestnite blok do hlavného kontextu konfigurácie, nie dovnútra http, a nahraďte dokumentačnú adresu skutočným backendom.

Obe trasy aj oba firewally musia prepustiť datagramy: cestu k listeneru a cestu z proxy do backendu. Listener IPv6 tiež nevytvára cestu IPv4, takže ak niektorí klienti stále používajú IPv4, je taký listener samostatná položka s vlastným testovaním. Firewall samotného backendu overte z adresy proxy, nie zo svojho notebooku.

Časové limity relácie nie sú časovými limitmi požiadavky

Proxy stream drží stav UDP relácie a zahadzuje ho podľa svojho časového limitu a nastavení odpovede. Krátky limit skopírovaný z DNS relay sa k VPN, ktorá chce vymieňať datagramy celé hodiny, nehodí, a zlyhanie sa prejaví ako spojenie, ktoré ticho umiera, nie ako to, ktoré odmieta začať.

Prečítajte si efektívny proxy_timeout nasadenia a akékoľvek nastavenie počtu odpovedí, potom ich porovnajte s chovaním keepalive, ktoré VPN skutočne používa. Dve čísla napísané v rôznych súboroch rôznymi ľuďmi sú normálnym stavom fungujúceho systému. Dve čísla, ktoré sa nikdy neporovnali, sú normálnym stavom občasne zlyhávajúceho systému. Zapíšte obe do servisného záznamu, aby sa porovnanie stalo raz, za denného svetla.

Čo relay mení a čo nie

Proxy stream neukončuje riadiaci kanál TLS OpenVPN ani ho nemení na HTTPS. Backend zostáva službou VPN a vzťah certifikátu zostáva medzi klientom a touto službou. Zachovanie zamýšľanej identity backendu je stále úlohou klienta a servera.

Bežné proxovanie mení aj zdrojovú adresu, ktorú backend vidí. Logy ukážu proxy a akékoľvek pravidlo prístupu podľa IP na serveri VPN vyhodnotí túto adresu namiesto adresy klienta. Transparentné zachovanie zdroja je samostatný návrh routingu a oprávnení, nie niečo, čo vyplýva z pridania udp k listeneru. Naplánujte to skôr, než vznikne politika závislá od adresy klienta.

Overujte z klienta, nie z portu

Miestna kontrola, že port UDP je otvorený, dokazuje, že listener existuje. Nedokazuje, že sa cez neho klient dokáže autentifikovať alebo ďalej vymieňať prevádzku. Dokončite skutočné spojenie zo schváleného klienta a potom potvrďte, že relácia vydrží dosť dlho na to, aby to malo význam.

Keď niekto hlási, že Nginx nevie UDP, pretože namiesto neho fungoval jednoduchý relay nástroj, oba fakty spolu nesúvisia. Nástroj dokázal, že backend odpovedá; nepovedal nič o tom, čo podporuje front end. Obe môžu byť pravda a len jedno z nich je konfigurácia pre toto nasadenie.

Súvisiace články