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 लाई जवाफ दिन बाध्य पार्न सक्दैन, र तपाईं सुरु गर्नुअघि हराएको फिर्ती मार्ग सुधार्न सक्दैन।