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