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 श्रोता वेब स्तराच्या पुन्हा सुरुवातीला देखील टिकतो, जे साइट वारंवार पुन्हा तैनात होणाऱ्या मशीनवर महत्त्वाचे आहे। वापरकर्ते जिथे बसले आहेत त्या नेटवर्कमधून चाचणी करा, कारण सर्व्हरवरील shell फक्त सर्व्हर स्वतःपर्यंत पोहोचू शकतो हेच सिद्ध करते।
सर्व्हर कॉन्फिगरेशनमध्ये आणि क्लायंट प्रोफाइलमध्ये वाहतूक एकत्र बदला। अजूनही 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 ला स्पर्श करणाऱ्या पुढील व्यक्तीला कोणती प्रक्रिया स्वीकारते आणि दुसरा प्रोटोकॉल कुठे गेला हे कळेल। संपादनाचा उद्देश काय होता यावर विश्वास ठेवण्याऐवजी बदलानंतर मालकीची पुष्टी करा।