OpenVPN UDP का लागि Nginx stream रिले: के बदलिन्छ

तपाईंको क्लाइन्ट 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;
    }
}

केही सम्पादन गर्नुअघि build मा stream मोड्युल छ भनी पुष्टि गर्नुहोस्; वितरण प्याकेजले यसलाई छुट्टै मोड्युलमा विभाजन गर्न सक्छ, र मोड्युल नभए टनेलको सट्टा कन्फिगरेसन त्रुटि आउँछ। ब्लक मुख्य कन्फिगरेसन सन्दर्भमा राख्नुहोस्, http भित्र होइन, र कागजातको ठेगाना वास्तविक ब्याकएन्डले बदल्नुहोस्।

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

सत्रका समय-सीमा अनुरोधका समय-सीमा होइनन्

stream प्रोक्सीले UDP सत्रका लागि स्थिति राख्छ र आफ्नो समय-सीमा तथा प्रतिक्रिया सेटिङअनुसार त्यसलाई फालिदिन्छ। DNS रिलेबाट प्रतिलिपि गरिएको छोटो समय-सीमा घण्टौंसम्म डेटाग्राम साटासाट गर्ने अपेक्षा गर्ने VPN का लागि राम्रोसँग मिल्दैन, र असफलता सुरु गर्न इन्कार गर्ने जडानको सट्टा चुपचाप मर्ने जडानका रूपमा देखिन्छ।

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

रिलेले के बदल्छ, र के बदल्दैन

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

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

पोर्टबाट होइन, क्लाइन्टबाट प्रमाणित गर्नुहोस्

UDP पोर्ट खुला छ भन्ने स्थानीय जाँचले श्रोता अवस्थित छ भनी प्रमाणित गर्छ। क्लाइन्टले यसबाट प्रमाणीकरण गर्न वा ट्राफिक साटासाट जारी राख्न सक्छ भनी यसले प्रमाणित गर्दैन। स्वीकृत क्लाइन्टबाट वास्तविक जडान पूरा गर्नुहोस्, त्यसपछि सत्र अर्थपूर्ण हुने गरी लामो समय टिक्छ भनी पुष्टि गर्नुहोस्।

कसैले Nginx ले UDP गर्न सक्दैन भनी रिपोर्ट गर्दा, किनभने यसको सट्टा साधारण रिले उपकरणले काम गर्यो, ती दुई तथ्य सम्बन्धित छैनन्। उपकरणले ब्याकएन्ड जवाफ दिन्छ भनी प्रमाणित गर्यो; अगाडिको भागले के समर्थन गर्छ भन्नेबारे यसले केही भनेन। दुवै सत्य हुन सक्छन्, र तीमध्ये एउटा मात्र यो तैनाथीको कन्फिगरेसन हो।