Дозволи TLS passthrough врска во NGINX stream контекст

NGINX може да одбие TCP TLS relay без да заврши TLS. Ставете го правилото за дозвола во stream, не во HTTP location, и проверете која peer адреса пристигнува.

Препраќање шифрирани бајти без некогаш да се држи сертификатот е она што го прави TLS passthrough relay, и овој распоред е удобен и истовремено малку збунувачки. Бидејќи ништо не се дешифрира, нема ништо во форма на HTTP за филтрирање, па вообичаениот location блок и неговите правила за пристап овде не помагаат. Одлуката што ја има NGINX се однесува на самата врска: кој мрежен peer чукна и дали тој peer воопшто треба да се препрати.

Одлуката и припаѓа на stream, не на HTTP

Во stream контекст NGINX работи со TCP сесии. Ја гледа peer адресата на врската и може да примени подредени allow и deny правила врз неа пред ниту еден бајт да стигне до backend. Тоа е целосна одлука за прием и не бара приватен клуч, сертификат или HTTP парсирање.

MechanismWhat it decidesWhere it lives
stream allow/denyWhether this TCP peer is relayedstream server block
ssl_preread mapWhich backend a named connection goes tostream, with the preread module
HTTP location ruleWhether an HTTP request is servedhttp server block

Тие три реда никогаш не се заменуваат еден со друг. Копирање на HTTP директива за пристап во која било датотека што го споменува портот 443 не менува ништо, бидејќи stream серверот никогаш не го чита http контекстот.

Примете ја врската пред да ја препратите

Претпоставете постоечка инсталација со достапни модули stream и stream-access, VPN клиенти што чуваат изворни адреси во 10.90.0.0/24, и backend на 192.168.50.20:443 што веќе го служи предвидениот HTTPS идентитет.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Читајте го ова како фрагмент од нов listener, не како директна замена на работна конфигурација. Прво прегледајте ги постоечките listener и include, бидејќи втор listener на веќе зафатен порт паѓа при reload, не во моментот на барањето.

Забележете што недостасува: нема listen ... ssl, нема директива за сертификат. NGINX ја препраќа шифрираната струја, а backend ја завршува TLS и го презентира сертификатот што клиентот го валидира. Клиент што нема да помине на allowlist добива одбиена TCP сесија, не HTTP 403 страница, и секоја алатка што очекува статусен код ќе пријави нешто бескорисно.

Што покрива allowlist, а што не

Ако relay веќе избира backend по име на сервер, ssl_preread и map можат да продолжат со таа работа, доколку модулот е достапен. Името се уште го дава клиентот, и ништо во презентирањето име не докажува дека клиентот се приклучил на VPN.

Примерното правило го покрива целиот stream listener. Тоа го прави несоодветен за една влезна точка што служи мешавина од јавни и само-VPN сајтови, каде што би бил потребен исклучок по име; одделни listener обично се појасни од политика зависна од име што никој не може да ја прочита.

Вреди да се именуваат уште две празнини. Совпаѓањето на префикс не кажува ништо за тоа низ кој интерфејс пристигнал пакетот, а HTTP правило на друго место не може да го ограничи овој listener. Двете се причини да се држи политиката за влез на ниво на хост во сликата, наместо еден allow ред да се смета за целата граница. Запишете ја границата како две контроли што мора да се согласат, за да биде прегледана секоја промена на која било од нив.

Чија адреса NGINX навистина ја гледа?

Балансер на оптоварување, друг proxy или source NAT можат да постават посредник пред NGINX, па peer-от што се гледа не е внатрешната адреса на VPN клиентот. Испитајте ја вистинската патека пред да изберете префикс, бидејќи allowlist напишан за погрешна адреса или ги пушта сите зад преведувачот или никого.

Протоколот PROXY и обработка на вистинска IP се легитимни одговори и мора да се конфигурираат само за компатибилни, експлицитно доверливи испраќачи. Двата механизми веруваат на она што го вели испраќачот, и токму затоа списокот на испраќачи мора да биде краток. Довербата на заглавие за идентитет од кој било интернет клиент не ги прави изворните информации повторно доверливи; тоа го претвора правилното одбивање во фалсификуван прием.

Тестирајте ги двата исхода пред reload

Валидирајте ја конфигурацијата, направете reload, потоа тестирајте двапати: нова дозволена сесија што мора да работи и одбиена што не смее. Задржете ја нормалната проверка на backend сертификатот во дозволениот тест, бидејќи relay што се поврзува но не може да го валидира backend решил еден проблем и создал друг.

nginx -t
ss -tnp | grep ':443'

Проверете ја и рутата до backend и одговорот одделно. Поминувањето на allowlist докажува само дека NGINX ја прифатил сесијата; не може да го натера недостапниот backend да одговори и не може да го поправи повратниот пат што недостасувал пред да почнете.

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