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-ті жауап беруге мәжбүрлей алмайды және сіз бастамас бұрын жоқ болған қайтару жолын жөндей алмайды.

Қатысты мақалалар