NGINX stream સંદર્ભમાં TLS પાસથ્રુ કનેક્શન સ્વીકારો
NGINX TLS સમાપ્ત કર્યા વિના TCP TLS રિલે નકારી શકે છે. પરવાનગી નિયમ HTTP locationમાં નહીં, streamમાં મૂકો, અને કયું peer સરનામું આવે છે તે તપાસો.
એન્ક્રિપ્ટેડ બાઇટ્સ આગળ મોકલવી પણ પ્રમાણપત્ર ક્યારેય ન રાખવું એ TLS પાસથ્રુ રિલે કરે છે, અને આ ગોઠવણ અનુકૂળ અને થોડી ગૂંચવણભરી બંને છે. કારણ કે કંઈ ડિક્રિપ્ટ થતું નથી, ફિલ્ટર કરવા માટે HTTP આકારનું કંઈ નથી, તેથી સામાન્ય location બ્લોક અને તેના એક્સેસ નિયમોનો અહીં કોઈ ઉપયોગ નથી. NGINX પાસેનો નિર્ણય કનેક્શન પોતાના વિશે છે: કયા નેટવર્ક peerએ દરવાજો ખખડાવ્યો, અને તે peer સાચવવો જોઈએ કે નહીં.
નિર્ણય streamમાં છે, HTTPમાં નહીં
stream સંદર્ભમાં NGINX TCP સેશન સાથે કામ કરે છે. તે કનેક્શનનું peer સરનામું જુએ છે અને કોઈપણ બાઇટ backend સુધી પહોંચે તે પહેલાં તેના પર ક્રમિક allow અને deny નિયમો લાગુ કરી શકે છે. આ સંપૂર્ણ પ્રવેશ નિર્ણય છે અને તેને ખાનગી કી, પ્રમાણપત્ર કે HTTP પાર્સિંગની જરૂર નથી.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
તે ત્રણ પંક્તિઓ ક્યારેય એકબીજાનો વિકલ્પ બનતી નથી. 443 પોર્ટનો ઉલ્લેખ કરતી કોઈપણ ફાઇલમાં HTTP એક્સેસ નિર્દેશ કોપી કરવાથી કંઈ બદલાતું નથી, કારણ કે 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 સામાન્ય રીતે નામ-આધારિત નીતિ કરતાં વધુ સ્પષ્ટ હોય છે જે કોઈ વાંચી શકતું નથી.
બે વધુ ખાલી જગ્યાઓ નોંધવા યોગ્ય છે. prefix મેળ પેકેટ કયા ઇન્ટરફેસ પરથી આવ્યું તે કંઈ કહેતું નથી, અને બીજે ક્યાંયનો HTTP નિયમ આ listenerને મર્યાદિત કરી શકતો નથી. બંને એક allow લાઇનને આખી સીમા ગણવાને બદલે હોસ્ટ-સ્તરની ingress નીતિ ચાલુ રાખવાનાં કારણો છે. સીમાને બે નિયંત્રણો તરીકે લખો જે સંમત થવાં જોઈએ, જેથી બંનેમાંથી કોઈપણ ફેરફારની સમીક્ષા થાય.
NGINX ખરેખર કોનું સરનામું જુએ છે?
લોડ બેલેન્સર, બીજો proxy અથવા source NAT NGINXની સામે મધ્યસ્થ મૂકી શકે છે, તેથી જે peer દેખાય છે તે VPN ક્લાયન્ટનું આંતરિક સરનામું નથી. prefix પસંદ કરતા પહેલાં વાસ્તવિક માર્ગ તપાસો, કારણ કે ખોટા સરનામા માટે લખાયેલ allowlist કાં તો અનુવાદક પાછળના બધાને પ્રવેશ આપે છે કાં તો કોઈને નહીં.
PROXY પ્રોટોકોલ અને વાસ્તવિક IP હેન્ડલિંગ કાયદેસર જવાબો છે, અને તે ફક્ત સુસંગત, સ્પષ્ટ રીતે વિશ્વસનીય મોકલનારાઓ માટે ગોઠવવા જોઈએ. બંને પદ્ધતિઓ મોકલનાર જે કહે છે તે માને છે, અને તેથી જ મોકલનારાઓની યાદી ટૂંકી હોવી જોઈએ. કોઈપણ ઇન્ટરનેટ ક્લાયન્ટ તરફથી ઓળખ હેડર પર ભરોસો કરવાથી સ્રોત માહિતી ફરી વિશ્વસનીય બનતી નથી; તે સાચા ઇનકારને બનાવટી સ્વીકારમાં ફેરવે છે.
reload પહેલાં બંને પરિણામો ચકાસો
રૂપરેખા માન્ય કરો, reload કરો, પછી બે વાર ચકાસો: કામ કરવું જોઈએ તેવું નવું મંજૂર સેશન, અને કામ ન કરવું જોઈએ તેવું નકારેલું સેશન. મંજૂર પરીક્ષણમાં સામાન્ય backend પ્રમાણપત્ર ચકાસણી રાખો, કારણ કે જોડાય છે પણ backend ચકાસી શકતું નથી તેવું રિલે એક સમસ્યા ઉકેલીને બીજી ઊભી કરી છે.
nginx -t
ss -tnp | grep ':443'backend માર્ગ અને જવાબ પણ અલગથી તપાસો. allowlist પાસ કરવી એ ફક્ત સાબિત કરે છે કે NGINXએ સેશન સ્વીકાર્યું; તે અપ્રાપ્ય backendને જવાબ આપવા મજબૂર કરી શકતું નથી, અને તમે શરૂ કરતા પહેલાં ખૂटતો પરત માર્ગ સુધારી શકતું નથી.