Ruhusu muunganisho wa TLS passthrough katika muktadha wa stream wa NGINX

NGINX inaweza kukataa upelekaji wa TCP TLS bila kumaliza TLS. Weka kanuni ya ruhusa katika stream, si katika HTTP location, na angalia ni anwani gani ya peer inayofika.

Kupeleka baiti zilizosimbwa bila kushikilia cheti kamwe ndilo tendo la relay ya TLS passthrough, na mpangilio huu ni rahisi na unachanganya kidogo kwa wakati mmoja. Kwa kuwa hakuna kinachosimbuliwa, hakuna kitu chenye umbo la HTTP cha kuchuja, kwa hiyo kizuizi cha location cha kawaida na kanuni zake za ufikiaji hazina maana hapa. Uamuzi ambao NGINX inao unahusu muunganisho wenyewe: ni peer gani wa mtandao aliyegonga, na kama peer huyo anapaswa kupelekwa kabisa.

Uamuzi ni wa stream, si wa HTTP

Katika muktadha wa stream NGINX hufanya kazi na vikao vya TCP. Inaona anwani ya peer ya muunganisho na inaweza kutumia kanuni za allow na deny zilizopangwa juu yake kabla baiti yoyote kufika backend. Hii ni uamuzi kamili wa kukubali na hauhitaji ufunguo wa faragha, cheti au uchanganuzi wa 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

Mistari hiyo mitatu haibadilishani kamwe. Kunakili maagizo ya ufikiaji ya HTTP kwenye faili yoyote inayotaja bandari 443 hakubadilishi chochote, kwa sababu seva ya stream haisomi kamwe muktadha wa http.

Kubali muunganisho kabla ya kuupeleka

Chukulia kuna usakinishaji uliopo na moduli za stream na stream-access zinapatikana, wateja wa VPN wanahifadhi anwani za chanzo katika 10.90.0.0/24, na backend iko 192.168.50.20:443 ambayo tayari inatoa utambulisho wa HTTPS uliokusudiwa.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Soma hii kama kipande cha listener mpya, si kama mbadala wa moja kwa moja wa usanidi unaofanya kazi. Kagua kwanza listener na include zilizopo, kwa sababu listener ya pili kwenye bandari iliyokwisha kuchukuliwa hushindwa kwenye reload, si wakati wa ombi.

Angalia kinachokosekana: hakuna listen ... ssl, hakuna maagizo ya cheti. NGINX hupeleka mtiririko uliosimbwa, na backend humaliza TLS na kuwasilisha cheti ambacho mteja huthibitisha. Mteja asiyefanikiwa kwenye allowlist hukataliwa kikao chake cha TCP, si ukurasa wa HTTP 403, na chombo chochote kinachotarajia msimbo wa hali kitaripoti kitu kisichofaa.

Kile allowlist inashughulikia na kisichoshughulikia

Ikiwa relay tayari inachagua backend kwa jina la seva, ssl_preread na map zinaweza kuendelea na kazi hiyo, mradi moduli inapatikana. Jina bado hutolewa na mteja, na hakuna kitu katika kuwasilisha jina kinachothibitisha kuwa mteja alijiunga na VPN.

Kanuni ya mfano inashughulikia listener yote ya stream. Hiyo inafanya isifae kwa sehemu moja ya kuingia inayohudumia mchanganyiko wa tovuti za umma na tovuti za VPN pekee, ambapo ubaguzi kwa kila jina ungehitajika; listener tofauti kwa kawaida huwa wazi zaidi kuliko sera inayotegemea jina ambayo hakuna mtu anayeweza kuisoma.

Vipengele viwili zaidi vya pengo vinafaa kutajwa. Ulinganifu wa prefix hausemi chochote kuhusu kiolesura ambacho pakiti ilikuja, na kanuni ya HTTP mahali pengine haiwezi kuzuia listener hii. Vyote viwili ni sababu za kuweka sera ya ingress katika ngazi ya host kwenye picha badala ya kuchukua mstari mmoja wa allow kama mpaka wote. Andika mpaka kama vidhibiti viwili vinavyopaswa kukubaliana, ili mabadiliko katika kimoja chochote yakaguliwe.

NGINX inaona anwani ya nani kwa kweli?

Kipangaji mzigo, proxy nyingine au source NAT zinaweza kuweka mpatanishi mbele ya NGINX, kwa hiyo peer inayoonekana si anwani ya ndani ya mteja wa VPN. Chunguza njia halisi kabla ya kuchagua prefix, kwa sababu allowlist iliyoandikwa kwa anwani isiyo sahihi ama inaruhusu kila mtu nyuma ya mtafsiri au hakuna mtu.

Itifaki ya PROXY na utunzaji wa IP halisi ni majibu halali, na yanapaswa kusanidiwa kwa watumaji wanaoendana na wanaotumainiwa waziwazi pekee. Mifumo yote miwili inaamini kile mtumaji anasema, na ndiyo sababu orodha ya watumaji inapaswa kuwa fupi. Kuamini kichwa cha utambulisho kutoka kwa mteja yeyote wa mtandao hakufanyi taarifa za chanzo kuwa za kuaminika tena; hubadilisha kataa sahihi kuwa kukubali kwa kughushi.

Jaribu matokeo yote mawili kabla ya reload

Thibitisha usanidi, fanya reload, kisha jaribu mara mbili: kikao kipya kilichoruhusiwa ambacho lazima kifanye kazi, na kilichokataliwa ambacho hakipaswi. Weka uthibitisho wa kawaida wa cheti cha backend kwenye jaribio lililoruhusiwa, kwa sababu relay inayounganisha lakini haiwezi kuthibitisha backend imetatua tatizo moja na kuunda lingine.

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

Angalia pia njia ya kufika backend na jibu kwa tofauti. Kupita allowlist kunathibitisha tu kuwa NGINX ilikubali kikao; haiwezi kulazimisha backend isiyofikika kujibu, na haiwezi kurekebisha njia ya kurudi iliyokosekana kabla ya kuanza.

Makala zinazohusiana