Вашиот клиент е поставен на 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.

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

Таймаутите на сесијата не се таймаути на барањето

stream проксито чува состојба за UDP сесија и ја отфрла според својот таймаут и поставките за одговор. Краток таймаут копиран од DNS реле не одговара на VPN што очекува да разменува датаграми со часови, а дефектот се појавува како врска што тивко умира, а не како онаа што одбива да започне.

Прочитајте го ефективниот proxy_timeout на распоредувањето и секоја поставка за броење одговори, потоа споредете ги со однесувањето keepalive што VPN-от навистина го користи. Два броја напишани во различни датотеки од различни луѓе се нормална состојба на систем што работи. Два броја што никогаш не биле споредени се нормална состојба на систем што повремено откажува. Запишете ги двата во сервисниот запис за споредбата да се случи еднаш, на дневна светлина.

Што менува релето, а што не

stream проксито не го завршува TLS контролниот канал на OpenVPN и не го претвора во HTTPS. Backend-от останува VPN услугата, а односот со сертификатот останува меѓу клиентот и таа услуга. Зачувувањето на предвидениот backend идентитет е сѐ уште работа на клиентот и серверот.

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

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

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

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

Поврзани статии