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;
    }
}

काहीही संपादित करण्यापूर्वी 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 करू शकत नाही कारण त्याऐवजी साधे रिले साधन चालले, तेव्हा ती दोन तथ्ये संबंधित नाहीत. साधनाने बॅकएंड उत्तर देतो हे सिद्ध केले; दर्शनी भाग काय समर्थन देतो याबद्दल ते काहीही म्हणाले नाही. दोन्ही खरे असू शकतात, आणि त्यापैकी फक्त एकच या तैनातीसाठीचे कॉन्फिगरेशन आहे.

संबंधित लेख