Stream релеј у Nginx-у за OpenVPN UDP: шта мења

UDP не припада HTTP location-у. Преместите га у слој stream, одредите тајмаут сесије за VPN и рачунајте на прокси као извор.

Ваш клијент је подешен на UDP, Nginx сервер има location блок који показује на VPN порт, а ништа не стиже. То је очекивано: HTTP location не може да пренесе UDP датаграм, како год да се зове предња страна. За то је Nginx-у потребан stream ослушкивач, и након што конфигурацију преместите тамо, о томе да ли ће сесија преживети одлучује други скуп детаља.

Прокси слој долази пре адресе

Stream модул Nginx-а проксира TCP и UDP без рашчлањивања HTTP-а. Његов HTTP модул очекује линију захтева, заглавља и одговор, а ничега од тога нема у изворном OpenVPN датаграму. Избор слоја је зато прва одлука и не зависи од тога да ли је ослушкивач IPv4 или IPv6.

Конфигурација која изгледа да ради са TCP OpenVPN не говори ништа о случају UDP. Транспорт је овде део протокола, а не детаљ распоређивања.

Ослушкивач и backend

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

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

Пре него што било шта измените, потврдите да build укључује stream модул; дистрибутивни пакет га може издвојити у засебан модул, а модул који недостаје даје грешку конфигурације, а не тунел. Ставите блок у главни контекст конфигурације, а не унутар http, и замените документациону адресу правим backend-ом.

И оба пута и оба заштитна зида морају да пропусте датаграме: пут до ослушкивача и пут од проксија до backend-а. Ослушкивач IPv6 такође не ствара IPv4 пут, па ако неки клијенти још користе IPv4, тај ослушкивач је засебан запис са сопственим тестирањем. Проверите заштитни зид самог backend-а са адресе проксија, а не са свог лаптопа.

Тајмаути сесије нису тајмаути захтева

Stream прокси чува стање UDP сесије и одбацује га према свом тајмауту и подешавањима одговора. Кратак тајмаут копиран са DNS релеја лоше одговара VPN-у који очекује размену датаграма сатима, а квар се појављује као веза која тихо умире, а не као она која одбија да почне.

Прочитајте стварни proxy_timeout распоређивања и свако подешавање броја одговора, затим их упоредите са keepalive понашањем које VPN заиста користи. Два броја која су различити људи написали у различитим датотекама нормално су стање система који ради. Два броја која никада нису упоређена нормално су стање система који повремено заказује. Упишите оба у сервисни запис да се поређење догоди једном, на дневном светлу.

Шта релеј мења, а шта не

Stream прокси не завршава TLS контролни канал OpenVPN-а и не претвара га у HTTPS. Backend остаје VPN услуга, а однос сертификата остаје између клијента и те услуге. Очување предвиђеног backend идентитета и даље је посао клијента и сервера.

Обично проксирање мења и изворну адресу коју backend види. Дневници ће приказати прокси, и свако правило приступа засновано на IP-у на VPN серверу оцењиваће ту адресу уместо клијентове. Транспарентно очување извора је засебан дизајн усмеравања и привилегија, а не нешто што следи из додавања udp ослушкивачу. Планирајте то пре него што се напише политика која зависи од адресе клијента.

Проверавајте са клијента, а не са порта

Локална провера да је UDP порт отворен доказује да ослушкивач постоји. Она не доказује да клијент може да се аутентификује кроз њега или да настави да размењује саобраћај. Завршите праву везу са одобреног клијента, затим потврдите да сесија остаје довољно дуго да то има значења.

Када неко пријави да Nginx не може UDP јер је уместо тога радио једноставан релеј алат, те две чињенице нису повезане. Алат је доказао да backend одговара; није рекао ништа о томе шта подржава предња страна. Обе могу бити истините, и само једна од њих је конфигурација за ово распоређивање.

Повезани чланци