दोन DNS नावे, एक OpenVPN पोर्ट: प्रत्यक्षात काय निवडते

दोन A रेकॉर्ड, एक पत्ता, एक डेमन: वापरकर्ता कोणतेही नाव टाइप करो, येणारे पॅकेट एकसारखे असते, आणि पोर्ट 1194 ला बांधलेल्या प्रक्रियेकडे दोन्हींत फरक करण्यासाठी काहीही नाही. हे दुरुस्तीच्या प्रतीक्षेत असलेले चुकीचे कॉन्फिगरेशन नाही; ही नाव-शोध व्यक्त करू शकते त्याची मर्यादा आहे. दोन OpenVPN इन्स्टन्समधून निवडणारी कोणतीही गोष्ट अशी मूल्य असली पाहिजे जी क्लायंट कनेक्शनमध्ये ठेवतो आणि जी फ्रंटएंड परत वाचू शकते, आणि सामान्य OpenVPN क्लायंट असे मूल्य उघडपणे ठेवत नाही. पुढे हे आहे की यामुळे तुम्ही कुठे राहता, आणि कोणती व्यवस्था ट्रॅफिकची खरी विभागणी करते.

रिझोल्व्हर जे परत देतो त्यापासून सुरुवात करा

क्लायंट vpn-a.example मागतो आणि पत्ता मिळवतो; तो पत्ता आणि पोर्ट हे त्याचे पूर्ण डायलिंग आहे. नाव शोधादरम्यान स्थानिक पातळीवर खर्च होते आणि ते कधीही तारेवरचे फील्ड होत नाही, म्हणून दुसऱ्या टोकाचा श्रोता कोणते लेबल वापरले गेले हे पाहू शकत नाही. vpn-a.example आणि vpn-b.example एकाच होस्टकडे निर्देश करा, दोन्ही शोध एकच गंतव्य देतात, म्हणूनच डेमन कोणताही फरक नोंदविल्याशिवाय दोन्ही कनेक्शन एकाच इन्स्टन्समध्ये शोषून घेतो. पत्त्यावर आधारित प्रोफाइल्स त्याच कारणामुळे नावावर आधारित प्रोफाइल्ससारखीच वागतात.

हे मोहक पर्यायी मार्गांचे कुटुंबही बंद करते: अतिरिक्त टोपणनावे, एकाच सॉकेटवर प्रत्येक नावासाठी प्रमाणपत्र निवडणे, किंवा विचारलेल्या नावाशी बांधलेला फायरवॉल नियम. यापैकी कोणतेही पहिले पॅकेट क्लायंट सोडण्यापूर्वीच टाकून दिलेल्या माहितीवर कार्य करू शकत नाही. दोन सर्व्हर वेगळे राहिलेच पाहिजेत तर, विभागणी कनेक्शनसोबतच प्रवास करायला हवी, म्हणजे पत्ता, पोर्ट, किंवा प्रोटोकॉलने परिभाषित केलेले पेलोड फील्ड.

गणण्यात येणारा एकमेव निवडक पॅकेटच्या आत जातो

HTTP हे Host हेडरने हाताळते, आणि TLS ClientHello मधील सर्व्हर नाव विस्ताराने, आणि अशा प्रकारे एक पत्ता एका श्रोत्यामागे अनेक साइट्सना सेवा देतो. दोन्ही कार्य करतात कारण तारेवरचा प्रोटोकॉल विशिष्ट सेवेसाठी विनंती वाहतो. OpenVPN बद्दलची संबंधित गोष्ट म्हणजे मध्यस्थ बॉक्स तपासतो त्या स्तरावर यापैकी कोणतेही फील्ड नाही.

सामान्य व्यवस्थेत नियंत्रण चॅनेलचे रक्षण करणारे TLS हँडशेक बाहेरील सत्र स्थापन झाल्यानंतर होते आणि त्याच्या आत वाहून नेले जाते, म्हणून ते सत्र संपवले नाही असा श्रोता अपारदर्शक प्रवाह पाहतो. तो अजूनही म्हणू शकतो की हे OpenVPN आहे, कारण सुरुवातीच्या बाइटमधील ऑपकोड आणि फ्रेमिंग ओळखता येते, पण सर्व्हरचे नाव, असल्यास, एन्क्रिप्टेड भागात बसते. बाहेरील पॅकेटमधून व्हर्च्युअल होस्ट वाचण्याची अपेक्षा करणारी रचना प्रोटोकॉल कधीही तिथे न लिहिणारे फील्ड वाचत असते. हे बोगदा कसा बांधला आहे त्यातून येते, अधिक हुशार नमुना जुळणी बंद करू शकेल अशा फटीतून नाही.

प्रोटोकॉल विभाजक कुठे थांबतो

sslh प्रकल्प दस्तऐवजीकरण करतो त्या प्रकारचा मल्टिप्लेक्सर एका पोर्टवर ऐकतो, सुरुवातीचे बाइट तपासतो, आणि ओळखलेला प्रोटोकॉल बोलणाऱ्या बॅकएंडकडे कनेक्शन सोपवतो. एकाच पोर्टला SSH, HTTPS आणि OpenVPN एकत्र सेवा द्यायची असल्यास हे खरे मूल्य आहे.

sslh प्रत्येक प्रोटोकॉलसाठी वेगळी तपासणी ठेवतो, आणि त्याची TLS तपासणी खऱ्या ClientHello मधून सर्व्हर नाव किंवा ALPN मूल्य काढू शकते. मूळ OpenVPN ओळखणे हे TLS विस्तार वाचण्यापेक्षा वेगळे वर्गीकरण आहे, आणि दोन्ही एकत्र चालत नाहीत, कारण ऐकणाऱ्या सॉकेटवर कधीही ClientHello न पाठवणारा क्लायंट तपासणीला वाचण्यासाठी काहीही न देता सोडतो. म्हणून OpenVPN शी जुळणारा नियम “हा OpenVPN क्लायंट आहे” असे उत्तर देतो आणि पुढे जात नाही. त्या नियमामागील दोन OpenVPN बॅकएंड वेगळे ओळखता येत नाहीत, फ्रंटएंडकडे निवडीसाठी आधार नाही, आणि प्रत्येक सत्र एकाच ठिकाणी उतरते. मल्टिप्लेक्सिंग एक पोर्ट वेगवेगळ्या सेवांमध्ये वाटते; ते एका सेवेच्या आत व्हर्च्युअल होस्टिंग करत नाही.

दोन सर्व्हर खरेच वेगळे करणाऱ्या व्यवस्था

सर्वात स्वस्त प्रामाणिक विभागणी दुसरा सार्वजनिक पत्ता आहे, प्रत्येक इन्स्टन्ससाठी एक, आणि विद्यमान प्रोफाइल्स आधीच आवश्यक ते घेऊन येतात कारण ती वेगवेगळ्या पत्त्यांकडे निर्देश करतात. पुढील म्हणजे त्याच पत्त्यावर वेगळा पोर्ट, ज्यासाठी प्रत्येक प्रोफाइलमधील एका संख्येपेक्षा जास्त काही खर्च होत नाही. TCP आणि UDP वेगवेगळी पोर्ट सारणी ठेवतात, म्हणून 1194/tcp आणि 1194/udp असंबंधित सॉकेट आहेत आणि प्रत्येकातील एक एकाच होस्टवर एकत्र राहू शकतो; हे नाव-राउटिंग नसून वाहतूक विभाजन आहे, आणि त्याच्याशी अनेकदा गल्लत होते. दोन्ही पर्याय फायरवॉल पुनरावलोकनातून जातात, कारण नियम पॅकेटमध्ये खरोखर असलेल्या गोष्टीशी जुळतो.

तुम्हाला हवी असलेली सीमा दोन अंमलबजावणींमध्ये नाही तर वापरकर्ता गटांमध्ये असते, तर वेगवेगळी क्लायंट कॉन्फिगरेशन, स्वतःची प्रमाणपत्र हाताळणी आणि स्पष्ट प्रवेश धोरण असलेला एक इन्स्टन्स ती झाकू शकतो. यातून सर्व्हरच्या आतले धोरण मिळते, सर्व्हरमधील अलगाव नाही, आणि या दोन वेगळ्या गरजा आहेत. तडजोडीखाली टिकायचा अलगाव अजूनही पत्ता किंवा फायरवॉलची धार मागतो.

OpenVPN समोर ठेवलेला TLS अंतक शक्य फ्रंटएंडसमोर खरे सर्व्हर नाव उघड करू शकतो, पण क्लायंट बाजूही त्या अतिरिक्त स्तरासाठी कॉन्फिगर केलेली असेल तरच. विद्यमान प्रोफाइल्स त्याच पत्त्याकडे निर्देश करून हे वर्तन मिळवत नाहीत.

बांधण्यापूर्वी निवडक सिद्ध करा

बॅकएंड ओळखणारे फील्ड नावाने सांगा, नंतर क्लायंट खरोखर ते पाठवतो याची खात्री करा; उत्तर पत्ता असेल तर योजना टिकते, आणि ते श्रोत्यापर्यंत कधीही न पोहोचणाऱ्या हँडशेकमधील सर्व्हर नाव असेल तर कोणतेही DNS कार्य ते वाचवणार नाही. तीन आदेश ऐकणाऱ्या बाजूचा निर्णय लवकर करतात.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl ओळ प्रमाणपत्र फक्त तिथे देते जिथे त्या पत्त्यावर काहीतरी TLS संपवते; मूळ OpenVPN श्रोत्यासमोर ती अडकते किंवा अयशस्वी होते, आणि हेच बाहेरील स्तर काय उघड करते याचे उत्तर आहे. journal ओळ, प्रत्येक बॅकएंडवर वाचल्यास, कोणत्या इन्स्टन्सने सत्र स्वीकारले ते दाखवते. फ्रंटएंड लॉग काय वर्गीकृत झाले ते लिहितात आणि कधीही काय अभिप्रेत होते ते नाही, म्हणून वापरकर्ता कुठे उतरला याबाबत बॅकएंड हाच एकमेव अधिकारी राहतो.

वेगवेगळ्या सर्व्हरपर्यंत पोहोचण्यासाठी ठेवलेल्या दोन प्रोफाइल्ससह समाप्त करा, ती एकामागून एक जोडा आणि प्रत्येकासाठी बॅकएंड लॉग नोंदवा. जर दोन्ही सत्रे एकाच journal मध्ये दिसली, तर निवडक चुकीच्या पद्धतीने कॉन्फिगर झालेला नसून गायब आहे, आणि उपाय म्हणजे क्लायंट लक्ष्य करू शकेल असा पत्ता किंवा पोर्ट. राउटिंग नियम संपादित केल्याने मदत होणार नाही, कारण नियमाला कधीही राउट करण्यासाठी काही दिलेले नाही. विभागणी खरी झाल्यावर पुढच्या व्यक्तीने दुसरे टोपणनाव जोडून त्याकडून कामाची अपेक्षा करू नये म्हणून ती प्रोफाइल्सच्या शेजारी लिहा.