NGINX stream संदर्भ में TLS passthrough कनेक्शन स्वीकार करें
NGINX TLS समाप्त किए बिना TCP TLS रिले को अस्वीकार कर सकता है। अनुमति नियम को HTTP location में नहीं, stream में रखें, और जाँचें कि कौन-सा peer पता आता है।
एन्क्रिप्टेड बाइट्स को आगे भेजना पर प्रमाणपत्र कभी न रखना वही है जो TLS passthrough रिले करता है, और यह व्यवस्था सुविधाजनक भी है और थोड़ी उलझाने वाली भी। चूँकि कुछ भी डिक्रिप्ट नहीं होता, फ़िल्टर करने के लिए 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 का टुकड़ा मानकर पढ़ें, चालू कॉन्फ़िगरेशन का सीधा प्रतिस्थापन नहीं। पहले मौजूदा listeners और includes की समीक्षा करें, क्योंकि पहले से बँधे पोर्ट पर दूसरा listener अनुरोध के समय नहीं, reload पर विफल होता है।
ध्यान दें कि क्या अनुपस्थित है: कोई listen ... ssl नहीं, कोई प्रमाणपत्र निर्देश नहीं। NGINX एन्क्रिप्टेड प्रवाह आगे भेजता है, और backend TLS समाप्त करता है और वह प्रमाणपत्र प्रस्तुत करता है जिसे क्लाइंट सत्यापित करता है। allowlist में विफल क्लाइंट का TCP सत्र अस्वीकार हो जाता है, HTTP 403 पृष्ठ नहीं, और स्थिति कोड की अपेक्षा करने वाला कोई भी उपकरण कुछ बेकार बताएगा।
allowlist क्या कवर करती है और क्या नहीं
यदि रिले पहले से सर्वर नाम से backends चुनता है, तो मॉड्यूल उपलब्ध होने पर ssl_preread और map वह काम जारी रख सकते हैं। नाम अभी भी क्लाइंट देता है, और नाम प्रस्तुत करने से यह सिद्ध नहीं होता कि क्लाइंट VPN में शामिल हुआ है।
उदाहरण नियम पूरे stream listener को कवर करता है। इससे यह एक ऐसे प्रवेश बिंदु के लिए अनुपयुक्त हो जाता है जो सार्वजनिक और केवल-VPN साइटों का मिश्रण परोसता है, जहाँ प्रति नाम अपवाद की आवश्यकता होगी; अलग listeners आमतौर पर नाम-निर्भर नीति से अधिक स्पष्ट होते हैं जिसे कोई पढ़ नहीं सकता।
दो और अंतराल नामित करने योग्य हैं। 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 को उत्तर देने के लिए बाध्य नहीं कर सकता, और आपके शुरू करने से पहले जो वापसी मार्ग गायब था उसे ठीक नहीं कर सकता।