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

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

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

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

У stream контексту NGINX ради са TCP сесијама. Види адресу партнера везе и може на њу применити уређена правила 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 покрива, а шта не

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

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

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

Чију адресу NGINX заиста види?

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

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

Тестирајте оба исхода пре reload-а

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

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

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

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