OpenVPN UDP के लिए Nginx stream रिले: यह क्या बदलता है

UDP, HTTP location में नहीं आता। इसे stream परत पर ले जाएँ, VPN के लिए सत्र की समय-सीमा तय करें, और स्रोत के रूप में प्रॉक्सी की अपेक्षा रखें।

आपका क्लाइंट UDP पर सेट है, Nginx सर्वर में VPN पोर्ट की ओर इशारा करने वाला location ब्लॉक है, और कुछ भी नहीं पहुँचता। यह अपेक्षित है: HTTP location कोई UDP डेटाग्राम नहीं ढो सकता, फ़्रंट एंड को कोई भी नाम दिया जाए। इसके लिए Nginx को एक stream श्रोता चाहिए, और कॉन्फ़िगरेशन वहाँ ले जाने के बाद दूसरा विवरण-समूह तय करता है कि सत्र बचेगा या नहीं।

प्रॉक्सी परत पते से पहले आती है

Nginx का stream मॉड्यूल HTTP पार्स किए बिना TCP और UDP को प्रॉक्सी करता है। इसका HTTP मॉड्यूल अनुरोध पंक्ति, हेडर और प्रतिक्रिया की अपेक्षा करता है, जिनमें से कोई भी मूल OpenVPN डेटाग्राम में नहीं होता। इसलिए परत चुनना पहला निर्णय है, और यह इस पर निर्भर नहीं करता कि श्रोता IPv4 है या IPv6।

TCP OpenVPN के साथ काम करता दिखने वाला कॉन्फ़िगरेशन UDP मामले के बारे में कुछ नहीं कहता। यहाँ परिवहन प्रोटोकॉल का हिस्सा है, तैनाती का विवरण नहीं।

श्रोता और बैकएंड

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

कुछ भी संपादित करने से पहले पुष्टि करें कि बिल्ड में stream मॉड्यूल है; वितरण पैकेज इसे अलग मॉड्यूल में बाँट सकता है, और अनुपस्थित मॉड्यूल टनल के बजाय कॉन्फ़िगरेशन त्रुटि देता है। ब्लॉक को मुख्य कॉन्फ़िगरेशन संदर्भ में रखें, http के अंदर नहीं, और दस्तावेज़ीकरण पते को वास्तविक बैकएंड से बदलें।

दोनों मार्गों और दोनों फ़ायरवॉल को डेटाग्राम की अनुमति देनी होगी: श्रोता तक का रास्ता और प्रॉक्सी से बैकएंड तक का रास्ता। IPv6 श्रोता IPv4 मार्ग भी नहीं बनाता, इसलिए यदि कुछ क्लाइंट अब भी IPv4 इस्तेमाल करते हैं, तो वह श्रोता अपनी अलग जाँच वाली अलग प्रविष्टि है। बैकएंड के अपने फ़ायरवॉल को प्रॉक्सी के पते से जाँचें, अपने लैपटॉप से नहीं।

सत्र की समय-सीमाएँ अनुरोध की समय-सीमाएँ नहीं हैं

stream प्रॉक्सी UDP सत्र के लिए स्थिति रखता है और अपनी समय-सीमा और प्रतिक्रिया सेटिंग्स के अनुसार उसे छोड़ देता है। DNS रिले से नकल की गई छोटी समय-सीमा घंटों तक डेटाग्राम बदलने की अपेक्षा रखने वाले VPN के लिए ठीक नहीं बैठती, और विफलता शुरू होने से इनकार करने वाले कनेक्शन के बजाय चुपचाप मरने वाले कनेक्शन के रूप में दिखती है।

तैनाती का प्रभावी proxy_timeout और प्रतिक्रिया-गणना की कोई भी सेटिंग पढ़ें, फिर उनकी तुलना VPN के वास्तविक keepalive व्यवहार से करें। अलग-अलग लोगों द्वारा अलग-अलग फ़ाइलों में लिखे गए दो नंबर काम करती प्रणाली की सामान्य स्थिति हैं। कभी तुलना न किए गए दो नंबर रुक-रुक कर चलती प्रणाली की सामान्य स्थिति हैं। दोनों को सेवा रिकॉर्ड में लिखें ताकि तुलना एक बार, दिन के उजाले में हो।

रिले क्या बदलता है और क्या नहीं

stream प्रॉक्सी OpenVPN की TLS नियंत्रण चैनल को समाप्त नहीं करता और न ही उसे HTTPS में बदलता है। बैकएंड ही VPN सेवा रहता है, और प्रमाणपत्र का संबंध क्लाइंट और उस सेवा के बीच ही रहता है। इच्छित बैकएंड पहचान बनाए रखना अब भी क्लाइंट और सर्वर का काम है।

सामान्य प्रॉक्सीिंग बैकएंड जो स्रोत पता देखता है उसे भी बदल देती है। लॉग प्रॉक्सी दिखाएँगे, और VPN सर्वर पर IP-आधारित कोई भी पहुँच नियम क्लाइंट के पते के बजाय उसी पते का मूल्यांकन करेगा। पारदर्शी स्रोत संरक्षण अलग रूटिंग और विशेषाधिकार डिज़ाइन है, श्रोता में udp जोड़ने से मिलने वाली चीज़ नहीं। क्लाइंट पते पर निर्भर नीति लिखे जाने से पहले इसकी योजना बनाएँ।

क्लाइंट से सत्यापित करें, पोर्ट से नहीं

UDP पोर्ट खुला होने की स्थानीय जाँच साबित करती है कि श्रोता मौजूद है। यह साबित नहीं करती कि कोई क्लाइंट उसके ज़रिए प्रमाणित कर सकता है या ट्रैफ़िक बदलना जारी रख सकता है। स्वीकृत क्लाइंट से वास्तविक कनेक्शन पूरा करें, फिर पुष्टि करें कि सत्र इतनी देर टिकता है कि मायने रखे।

जब कोई बताता है कि Nginx UDP नहीं कर सकता क्योंकि उसकी जगह एक सादा रिले टूल काम कर गया, तो ये दो तथ्य असंबंधित हैं। टूल ने साबित किया कि बैकएंड जवाब देता है; इसने फ़्रंट एंड क्या समर्थन देता है, इस पर कुछ नहीं कहा। दोनों सच हो सकते हैं, और इनमें से सिर्फ़ एक इस तैनाती का कॉन्फ़िगरेशन है।

संबंधित लेख