OpenVPN और HTTPS पोर्ट 443 पर: श्रोता किसका है?
TCP और UDP 443 अलग सॉकेट हैं। एक TCP श्रोता साझा करने के लिए मालिक चाहिए, और OpenVPN का पोर्ट साझाकरण एक संकीर्ण व्यवस्था है, प्रॉक्सी की चाल नहीं।
दो सेवाएँ बिना कभी प्रतिस्पर्धा किए दोनों पोर्ट 443 पर उत्तर दे सकती हैं, क्योंकि श्रोता परिवहन, पता और पोर्ट तीनों से मिलकर तय होता है, केवल संख्या से नहीं। एक ही मशीन पर वेब सर्वर और OpenVPN रखें, और पहले उत्तर देने योग्य एकमात्र प्रश्न यह है कि प्रत्येक प्रक्रिया कर्नेल से कौन-सा सॉकेट माँगती है। कॉन्फ़िगरेशन संपादित करने से पहले वह सूची लिख लें, और अधिकांश «पता पहले से उपयोग में है» त्रुटियाँ स्वयं समझा देती हैं। सूची के बाद सब कुछ UDP श्रोता, साझा TCP सॉकेट या प्रोटोकॉल के अनुसार मार्गित करने वाले फ्रंट एंड के बीच चुनाव है।
उस सॉकेट से शुरू करें जो प्रत्येक प्रक्रिया माँगती है
bind उसी त्रिक पर सफल या असफल होता है, इसलिए दो डेमन केवल तब टकराते हैं जब तीनों भाग मिल जाएँ। इसीलिए TCP 443 पर एक वेबसाइट UDP 443 पर OpenVPN श्रोता के साथ अनिश्चित काल तक सहअस्तित्व में रहती है, और इसीलिए उनमें से एक को उसी होस्ट पर दूसरे स्थानीय पते पर ले जाने से भी विवाद समाप्त हो जाता है। जीवित श्रोताओं को पढ़ें, उन फ़ाइलों को नहीं जिन्हें उन्हें बनाना था, क्योंकि पुराना include या भूला हुआ unit फ़ाइल उस संपादन से अधिक टिकता है जो आपको याद है कि आपने किया था।
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root के रूप में ss -lntup चलाएँ और 443 का उल्लेख करने वाली हर पंक्ति पढ़ें, IPv6 प्रविष्टियों सहित। सामान्यतः वाइल्डकार्ड v6 श्रोता v4 ट्रैफ़िक भी स्वीकार करता है, और इसी तरह भूला हुआ श्रोता उस फ़ाइल को बदलने के बाद भी पोर्ट पर कब्ज़ा बनाए रखता है जिसे आप ज़िम्मेदार मानते थे। यदि प्रक्रिया का नाम आपको चौंकाए, तो कुछ भी छूने से पहले ss -lntup 'sport = :443' से आउटपुट सीमित करें।
जब नेटवर्क अनुमति दे तो टनल को UDP पर ले जाएँ
UDP श्रोता टकराव को पूरी तरह बचाता है और सामान्यतः सबसे छोटा उपाय होता है, क्योंकि कोई सॉकेट साझा नहीं होता और पथ में कोई अतिरिक्त उत्पाद नहीं जुड़ता। पर यह मुफ़्त नहीं है। कुछ क्लाइंट नेटवर्क reset भेजे बिना UDP 443 गिरा देते हैं, इसलिए टनल bind में विफल होने के बजाय स्थापित होना बंद कर देता है, और उपयोगकर्ता पढ़ने योग्य किसी त्रुटि के बिना VPN बंद होने की सूचना देता है। UDP श्रोता वेब परत के पुनःआरंभ से भी बचा रहता है, जो ऐसी मशीन पर मायने रखता है जिसकी साइट बार-बार फिर से तैनात होती है। उसी नेटवर्क से परीक्षण करें जहाँ उपयोगकर्ता बैठे हैं, क्योंकि सर्वर पर शेल केवल यह सिद्ध करता है कि सर्वर स्वयं तक पहुँच सकता है।
सर्वर कॉन्फ़िगरेशन और क्लाइंट प्रोफ़ाइल में परिवहन एक साथ बदलें। जो प्रोफ़ाइल अभी भी TCP माँगती है वह केवल UDP श्रोता के सामने पुनःकनेक्शन के चक्र में घूमेगी, और दोनों फ़ाइलों की तुलना करने तक यह नेटवर्क खराबी जैसा लगता है।
VPN प्रक्रिया को TCP 443 का मालिक बनने दें और बाकी आगे भेजें
TCP सर्वर मोड में Community OpenVPN आने वाले कनेक्शन के पहले बाइट पढ़ता है और जो उसका अपना प्रोटोकॉल नहीं है उसे HTTPS बैकएंड पर भेजता है, port-share निर्देश इसी के लिए है। बैकएंड TLS सक्षम एक सामान्य वेब सर्वर है, जिसे उस निर्देश में URL से नहीं बल्कि होस्ट और पोर्ट से नाम दिया जाता है।
port-share 10.0.0.5 8080
जिस मशीन में साइट का दूसरा निजी पता हो, वहाँ वह पंक्ति गैर-VPN ट्रैफ़िक 10.0.0.5:8080 पर भेजती है, इसलिए HTTPS वर्चुअल होस्ट वहीं बाइंड होना चाहिए और फ़ायरवॉल को स्थानीय छलांग की अनुमति देनी चाहिए। वेब सर्वर को स्वयं TLS समाप्त करना होगा, क्योंकि आने वाले बाइट ब्राउज़र का मूल हैंडशेक हैं और बीच में किसी ने उन्हें डिक्रिप्ट नहीं किया है। निर्देश को सादे HTTP श्रोता की ओर मोड़ें और ब्राउज़र को अमान्य विधि की त्रुटि मिलेगी, जो टूटी साइट जैसी पढ़ी जाती है, गलत जगह रखे बैकएंड जैसी नहीं। निर्देश केवल TCP सर्वर मोड में मौजूद है, और UDP श्रोता के पास जाँचने के लिए कोई स्ट्रीम नहीं है।
चूँकि VPN प्रक्रिया हर कनेक्शन स्वीकार करती है, वेब एप्लिकेशन आगे भेजे गए अनुरोध को आगंतुक से नहीं बल्कि होस्ट के अपने किसी पते से आते देखता है। जिसे वास्तविक क्लाइंट पता चाहिए वह बैकएंड में PROXY प्रोटोकॉल समर्थन या उसे जोड़ने वाले फ्रंट एंड पर निर्भर है। बैकएंड को दूसरे स्थानीय पते पर ले जाने से आगंतुक का पता वापस नहीं आता; यह केवल बदलता है कि साइट होस्ट के किन पतों को दर्ज करती है। विश्लेषण रिपोर्ट प्रश्न उठाने से पहले यह सीमा तैनाती नोट्स में लिखें।
रिवर्स प्रॉक्सी गलत औज़ार है; लेयर-चार राउटर नहीं
HTTP रिवर्स प्रॉक्सी अनुरोध पढ़ने के लिए TLS समाप्त करता है, यानी वह OpenVPN स्ट्रीम को अछूता पार नहीं कर सकता। SNI या पहले पैकेट के निरीक्षण से आगे भेजने वाला लेयर-चार राउटर दोनों के आगे खड़ा हो सकता है, बशर्ते वह उस सत्र को समाप्त न करे जिस पर VPN निर्भर है। दोनों उपकरण आरेख में एक जैसे दिखते हैं और सॉकेट पर पूरी तरह अलग व्यवहार करते हैं।
व्यावसायिक Access Server अपनी पोर्ट-साझाकरण सेटिंग्स लेकर आता है, और वे समुदाय निर्देश से एक-से-एक मेल नहीं खातीं। दूसरे के लिए लिखी गाइड अपनाने से पहले उत्पाद और संस्करण पहचानें। चुपचाप अनदेखी की गई नकल की गई सेटिंग सेटिंग न होने से भी बुरी है, क्योंकि उसके बाद भी श्रोताओं की सूची विश्वसनीय दिखती है।
वेबसाइट और टनल को दो अलग मार्गों के रूप में परखें
साइट लोड करें और टनल जोड़ें, फिर श्रोताओं की सूची दोबारा पढ़ें कि अब 443 का मालिक कौन-सी प्रक्रिया है। लोड होता पृष्ठ VPN के बारे में कुछ सिद्ध नहीं करता, और जुड़ती टनल साइट के बारे में कुछ सिद्ध नहीं करती, भले ही दोनों एक ही संख्या उपयोग करते हैं। नीचे दिए तीन कमांड क्रमशः साझा सॉकेट, वेब मार्ग और VPN सेवा जाँचते हैं।
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
उसी क्षण के लिए बैकएंड के एक्सेस लॉग में क्लाइंट पता की तुलना VPN लॉग वाले से करें। यदि साइट हर आगंतुक को होस्ट स्वयं के रूप में दर्ज करती है, तो अग्रेषण काम करता है और पता प्रबंधन नहीं। यदि दोनों लॉग चुप रहें, तो फ्रंट एंड ने कभी कनेक्शन सौंपा ही नहीं। किसी भी तरह, श्रोताओं की सूची तय करती है कि सॉकेट कौन स्वीकार करता है, और दूसरी फ़ाइल बदलने से पहले यही पुष्टि करने योग्य तथ्य है।
वह श्रोता-नक्शा कॉन्फ़िगरेशन के पास छोड़ दें ताकि 443 को छूने वाला अगला व्यक्ति जान सके कि कौन-सी प्रक्रिया स्वीकार करती है और दूसरा प्रोटोकॉल कहाँ गया। संपादन का इरादा क्या था इस पर भरोसा करने के बजाय बदलाव के बाद स्वामित्व की पुष्टि करें।