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, защото прост инструмент за релей е свършил работа вместо него, двата факта са несвързани. Инструментът доказа, че бекендът отговаря; той не каза нищо за това какво поддържа фронтендът. И двете могат да са верни и само едното от тях е конфигурация за това внедряване.

Подобни статии