NGINX stream контекстинде TLS passthrough байланышына жол берүү

NGINX TLSди бүтпөстөн TCP TLS релесин четке кага алат. Уруксат эрежесин HTTP locationга эмес, streamге коюңуз жана кайсы peer дареги келерин текшериңиз.

Шифрленген байттарды сертификатты эч качан кармабастан өткөрүп берүү — TLS passthrough релесинин иши, жана бул түзүлүш ыңгайлуу жана бир аз баш айлантат. Эч нерсе дешифрленбегендиктен, фильтрлөө үчүн HTTP формасындагы эч нерсе жок, ошондуктан кадимки location блогу жана анын кирүү эрежелери бул жерде эч пайда бербейт. NGINXдин колундагы чечим байланыштын өзүнө тиешелүү: кайсы тармактык peer кагылды жана аны такыр өткөрүп берүү керекпи.

Чечим HTTPде эмес, streamде

stream контекстинде NGINX TCP сессиялары менен иштейт. Ал байланыштын peer дарегин көрөт жана кандайдыр бир байт backendге жетпестен мурун ага иреттелген allow жана deny эрежелерин колдоно алат. Бул толук кабыл алуу чечими жана жеке ачкыч, сертификат же 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 ичинде кармайт, ал эми 192.168.50.20:443 дарегиндеги backend күтүлгөн 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 сабын бүткүл чек ара деп эсептөөнүн ордуна хост деңгээлиндеги ingress саясатын көз алдында кармоонун себеби. Чек араны макулдашууга тийиш болгон эки көзөмөл катары жазыңыз, ошондо алардын кайсынысы болбосун өзгөрүүсү каралат.

NGINX чындыгында кимдин дарегин көрөт?

Жүктөм теңдештиргич, башка proxy же source NAT NGINXдин алдына ортомчу коюшу мүмкүн, ошондуктан байкалган peer VPN кардарынын ички дареги эмес. Префиксти тандоодон мурун чыныгы жолду текшериңиз, анткени туура эмес дарекке жазылган allowlist же котормочунун артындагы баарын киргизет, же эч кимди.

PROXY протоколу жана чыныгы IP менен иштөө мыйзамдуу жооптор жана алар шайкеш, ачык ишенимдүү жөнөтүүчүлөр үчүн гана конфигурацияланышы керек. Эки механизм тең жөнөтүүчүнүн айтканына ишенет, ошондуктан жөнөтүүчүлөрдүн тизмеси кыска болушу керек. Каалаган интернет кардарынан келген инсандык аталышына ишенүү булак маалыматын кайра ишенимдүү кылбайт; ал туура баш тартууну жасалма кабыл алууга айландырат.

reload алдында эки жыйынтыкты тең текшериңиз

Конфигурацияны текшериңиз, reload жасаңыз, анан эки жолу текшериңиз: иштеши керек болгон жаңы уруксат берилген сессия жана иштебеши керек болгон четке кагылган сессия. Уруксат берилген тестте кадимки backend сертификатын текшерүүнү сактаңыз, анткени туташкан, бирок backendди текшере албаган реле бир маселени чечип, экинчисин жараткан.

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

Backend маршрутун жана жоопту өзүнчө текшериңиз. allowlistтен өтүү NGINX сессияны кабыл алганын гана далилдейт; ал жетүү мүмкүн болбогон backendди жооп берүүгө мажбурлай албайт жана сиз баштаардан мурун жок болгон кайтаруу жолун оңдой албайт.

Тектеш макалалар