दो 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 में दिखें, तो चयनक गायब है, गलत कॉन्फ़िगर नहीं, और उपाय वह पता या पोर्ट है जिसे क्लाइंट लक्ष्य कर सके। रूटिंग नियम संपादित करने से मदद नहीं मिलेगी, क्योंकि नियम को कभी रूट करने के लिए कुछ दिया ही नहीं गया। बँटवारा वास्तविक हो जाने पर उसे प्रोफ़ाइलों के पास लिख दें ताकि अगला व्यक्ति दूसरा उपनाम जोड़कर उससे काम की अपेक्षा न करे।