NGINX stream சூழலில் TLS passthrough இணைப்பை அனுமதிக்கவும்
NGINX TLS-ஐ முடிக்காமலேயே TCP TLS ரிலேவை நிராகரிக்க முடியும். அனுமதி விதியை HTTP location-இல் அல்ல, stream-இல் வைக்கவும், எந்த peer முகவரி வருகிறது என்பதைச் சரிபார்க்கவும்.
சான்றிதழை ஒருபோதும் வைத்திருக்காமல் என்க்ரிப்ட் செய்யப்பட்ட பைட்டுகளை அனுப்புவதே TLS passthrough ரிலே செய்வது, இந்த ஏற்பாடு வசதியானதும் சற்று குழப்பமானதும் ஆகும். எதுவும் டீக்ரிப்ட் செய்யப்படாததால், வடிகட்ட HTTP வடிவில் எதுவும் இல்லை, எனவே வழக்கமான location தொகுதியும் அதன் அணுகல் விதிகளும் இங்கு பயன்படாது. NGINX-இடம் உள்ள முடிவு இணைப்பைப் பற்றியது: எந்த நெட்வொர்க் peer தட்டியது, அந்த peer முழுவதுமாக அனுப்பப்பட வேண்டுமா.
முடிவு HTTP-இல் அல்ல, stream-இல் உள்ளது
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 வரியை முழு எல்லையாகக் கருதுவதற்குப் பதிலாக host நிலை 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-ஐப் பதிலளிக்க வைக்க முடியாது, நீங்கள் தொடங்குவதற்கு முன் இல்லாத திரும்பும் பாதையைச் சரிசெய்யவும் முடியாது.