Рэлей stream у Nginx для OpenVPN UDP: што ён змяняе

UDP не месца ў location HTTP. Перанясіце яго ў пласт stream, падбярыце тайм-аўт сеансу для VPN і чакайце, што крыніцай будзе проксі.

Ваш кліент настроены на UDP, на серверы Nginx ёсць блок location, які паказвае на порт VPN, але нічога не прыходзіць. Гэта чакана: location HTTP не можа перадаць датаграму UDP, як бы ні называўся знешні бок. Для гэтага Nginx патрэбны слухач stream, і пасля пераносу канфігурацыі туды пра тое, ці выжыве сеанс, вырашае другі набор дэталяў.

Пласт проксі ідзе перад адрасам

Модуль stream у Nginx праксіруе TCP і UDP, не разбіраючы HTTP. Модуль HTTP чакае радок запыту, загалоўкі і адказ, і нічога з гэтага няма ў OpenVPN датаграме. Таму выбар пласта — гэта першае рашэнне, і яно не залежыць ад таго, ці слухач IPv4, ці IPv6.

Канфігурацыя, якая выглядае працоўнай з TCP OpenVPN, нічога не кажа пра выпадак UDP. Тут транспарт — частка пратакола, а не дэталь разгортвання.

Слухач і бэкенд

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

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

Пераканайцеся, што зборка ўключае модуль stream, перш чым нешта рэдагаваць; дыстрыбутыўны пакет можа вынесці яго ў асобны модуль, і адсутнасць модуля дае памылку канфігурацыі, а не тунель. Змясціце блок у асноўны кантэкст канфігурацыі, а не ўнутры http, і заменіце дакументацыйны адрас на сапраўдны бэкенд.

Абодва маршруты і абодва файрволы павінны прапускаць датаграмы: шлях да слухача і шлях ад проксі да бэкенда. Слухач IPv6 таксама не стварае шлях IPv4, таму калі частка кліентаў усё яшчэ карыстаецца IPv4, такі слухач — асобны пункт з уласным тэставаннем. Праверце ўласны файрвол бэкенда з адраса проксі, а не са свайго ноўтбука.

Тайм-аўты сеансу — не тайм-аўты запыту

Проксі stream захоўвае стан сеансу UDP і адкідвае яго згодна са сваім тайм-аўтам і наладамі адказу. Кароткі тайм-аўт, скапіяваны з рэлея DNS, дрэнна падыходзіць для VPN, які разлічвае абменьвацца датаграмамі гадзінамі, і збой выглядае як злучэнне, што ціха памірае, а не як тое, што адмаўляецца запускацца.

Прачытайце фактычны proxy_timeout разгортвання і любы параметр колькасці адказаў, затым параўнайце іх з паводзінамі keepalive, якія VPN фактычна выкарыстоўвае. Два лікі, запісаныя рознымі людзьмі ў розных файлах, — звычайны стан працоўнай сістэмы. Два лікі, якія ніколі не параўноўвалі, — звычайны стан сістэмы з перапынкамі. Запішыце абодва ў запіс службы, каб параўнанне адбылося адзін раз, пры дзённым святле.

Што рэлей змяняе, а што не

Проксі stream не завяршае кантрольны канал TLS OpenVPN і не пераўтварае яго ў HTTPS. Бэкенд застаецца службай VPN, а сувязь сертыфіката застаецца паміж кліентам і гэтай службай. Захаванне патрэбнай ідэнтычнасці бэкенда па-ранейшаму абавязак кліента і сервера.

Звычайнае праксіраванне таксама змяняе адрас крыніцы, які бачыць бэкенд. У журналах будзе проксі, і любое правіла доступу па IP на серверы VPN будзе ацэньваць менавіта гэты адрас, а не кліенцкі. Празрыстае захаванне крыніцы — асобны дызайн маршрутызацыі і прывілеяў, а не тое, што вынікае з дадання udp да слухача. Сплануйце гэта, перш чым будзе напісана палітыка, якая залежыць ад адраса кліента.

Правярайце з кліента, а не з порта

Лакальная праверка, што порт UDP адкрыты, даказвае існаванне слухача. Яна не даказвае, што кліент можа аўтэнтыфікавацца праз яго або працягваць абмен трафікам. Завяршыце рэальнае злучэнне з дазволенага кліента, затым пераканайцеся, што сеанс трымаецца дастаткова доўга, каб гэта мела значэнне.

Калі хтосьці кажа, што Nginx не можа UDP, бо просты інструмент рэлея спрацаваў замест яго, гэтыя два факты не звязаны. Інструмент даказаў, што бэкенд адказвае; ён нічога не сказаў пра тое, што падтрымлівае знешні бок. Абодва могуць быць праўдай, і толькі адно з іх — канфігурацыя для гэтага разгортвання.

Падобныя артыкулы