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 ओळीला संपूर्ण सीमा मानण्याऐवजी होस्ट-स्तरीय 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 ला उत्तर देण्यास भाग पाडू शकत नाही आणि तुम्ही सुरू करण्यापूर्वी नसलेला परतीचा मार्ग दुरुस्त करू शकत नाही.