कहीं भी SysAdmin: दूरस्थ डेस्कटॉप को लागू करने के लिए UDP होल पंचिंग का उपयोग करना

परिचय

सिस्टम प्रशासक स्वभाव से आलसी लोग होते हैं। वे एक ही काम को सौ बार करना पसंद नहीं करते हैं। वे सब कुछ स्वचालित करना चाहते हैं ताकि यह न्यूनतम हस्तक्षेप के साथ काम करे। और मैं ऐसा ही हूं।

अपने और अपनी तरह के जीवन को आसान बनाने के लिए, एक कार्यक्रम बनाया गया था जो कि सरल नाम SysAdmin के साथ एक उत्पाद में प्रशासनिक उपकरणों को संयुक्त करता है। इसमें मल्टी-डोमेन नेटवर्क समर्थन, रिपोर्ट, इन्वेंट्री और कई अन्य उपयोगी चीजें शामिल हैं जो विभिन्न एमएमसी में बिखरे हुए हैं या तीसरे पक्ष के उत्पादों में शामिल हैं। काम बहुत अधिक सुविधाजनक हो गया है। यह कार्यक्रम पहले से ही 5.3 संस्करण तक बढ़ गया है, इंटरफ़ेस को मेट्रो-शैली में बदल दिया है। लेकिन, दुर्भाग्य से, कंप्यूटर को डोमेन में शामिल नहीं करने का कोई तरीका नहीं है।

हालाँकि, मैं और अधिक चाहता था:

• पूरी तरह से दूरस्थ कंप्यूटर का प्रशासन;
• दूरस्थ पक्ष पर एक व्यक्तिगत उपस्थिति के बिना और दूरस्थ पक्ष से योग्य कर्मचारी की उपस्थिति के बिना कॉन्फ़िगर करें;
• राउटर पर पोर्ट न खोलें;
• यदि व्यक्तिगत रूप से उपस्थित होना असंभव है, तो इंटरनेट से राउटर तक पहुंच न खोलें;
• यदि आपको दूरस्थ नेटवर्क पर एक से अधिक कंप्यूटर तक पहुँच की आवश्यकता है, तो तकनीकी समाधान को जटिल न करें:
• प्रत्येक कंप्यूटर के लिए राउटर पर पोर्ट न खोलें;
• राउटर पर सर्वर तक पहुंच न खोलें, और इसे कंप्यूटर से (इसमें हमेशा सर्वर की आवश्यकता नहीं होती है, और इसे रिमोट एक्सेस के साधन के रूप में पेश करना आर्थिक रूप से संभव नहीं है);
• एक पोर्ट न खोलें और हर बार दूसरे कंप्यूटर को एक्सेस करने के लिए राउटर को फिर से कॉन्फ़िगर न करें;
• वीपीएन मत बढ़ाओ।

अनुभव से:
काम के लिए, पूरे देश में स्थित क्षेत्रीय कार्यालयों के साथ वीपीएन नेटवर्क बनाना आवश्यक था। केंद्रीय कार्यालय में शक्तिशाली वीपीएन उपकरण स्थापित किए गए थे, और उसी कंपनी के उपकरणों की स्थानीय स्तर पर योजना बनाई गई थी, लेकिन यह आसान था। उनके इंटरनेट कनेक्शन, स्थानीय क्षेत्र नेटवर्क, स्थापित उपकरण, आदि के बारे में सब कुछ पता लगाना आवश्यक था। वीपीएन उपकरण तैयार करें और इसे कनेक्ट करने के लिए उन्हें भेजें और यह काम करता है। स्थिति की ख़ासियत यह थी कि वास्तव में मेरे लिए यह करना था, कोई व्यापार यात्राएं नहीं थीं, और जमीन पर उपयोगकर्ताओं का स्तर बहुत विविध था। बेशक, सब कुछ लागू किया गया था, लेकिन पत्राचार और टेलीफोन वार्तालाप के लिए बहुत समय लगा।

पहले से सूचीबद्ध प्रतिबंधों के कारण, कार्यान्वयन के लिए एक मध्यस्थ की आवश्यकता थी। क्लाइंट कंप्यूटर को दूरस्थ कंप्यूटर पर स्थापित किया गया है, जो कि मध्यस्थ के साथ एक कनेक्शन बनाता है जो फ़ायरवॉल द्वारा अवरुद्ध नहीं है, क्योंकि यह सबसे रिमोट मशीन द्वारा शुरू किया गया है। एक व्यवस्थापक को केवल मध्यस्थ से पता करने के लिए इसे कनेक्ट करने और दूरस्थ कंप्यूटर तक पहुंच प्राप्त करने की आवश्यकता है। ऐसे मध्यस्थ के लिए धन्यवाद, हमें कई फायदे मिलते हैं:

• राउटर पर पोर्ट खोलने की आवश्यकता नहीं है। सुरक्षा बढ़ जाती है, उपयोगकर्ता की आवश्यक योग्यता का स्तर कम हो जाता है;
• व्यवस्थापक के पास एक ब्राउज़र के माध्यम से क्लाउड में स्थित नियंत्रण कक्ष तक पहुंच है जो एक सुरक्षित कनेक्शन के माध्यम से Microsoft सिल्वरलाइट का समर्थन करता है;
• क्लाउड सेवा का उपयोग करने वाले व्यवस्थापक से कमांड को दूरस्थ कंप्यूटर पर भेजा जाता है। प्रतिक्रिया व्यवस्थापक को उसी तरह प्रेषित की जाती है;
• दूरस्थ कंप्यूटर ऑनलाइन है, इसलिए उपयोगकर्ता की उपस्थिति की कोई आवश्यकता नहीं है;
• क्लाउड में डेटा स्टोरेज के साथ अतिरिक्त सेवाएं (इन्वेंट्री, सर्विस डेस्क, रिपोर्ट, लाइसेंस अकाउंटिंग, आर्काइविंग, मॉनिटरिंग, आदि) और उस तक पहुंच, भले ही रिमोट कंप्यूटर इंटरनेट से जुड़ा न हो;
• रिमोट डेस्कटॉप (VNC)
• मोबाइल फोन से विंडोज फोन तक पहुंच।

हमें लंबे समय तक मध्यस्थ के लिए एक मंच की तलाश नहीं करनी पड़ी। वैसे, Microsoft Azure इसके लिए उपयुक्त था। इसके अलावा, प्रयोगों के लिए 30-दिवसीय पहुंच प्राप्त करना संभव था।

ऐसा हुआ कि इस समय तक मैंने अपना ध्यान सिस्टम एडमिनिस्ट्रेशन से प्रोग्रामिंग में बदल दिया था। इसलिए, मैंने स्वयं सेवा बनाने का फैसला किया।
मेरे सहयोगी ने मेरा साथ दिया, और साथ में हमने एक प्रोटोटाइप सेवा विकसित करना शुरू किया। दूरस्थ ग्राहक और क्लाउड सेवा के बीच परस्पर क्रियात्मक मॉडल बनाने के लिए हमें परीक्षण अवधि के दौरान कार्य का सामना करना पड़ा। आगे विकास Azure SDK का उपयोग करके जारी रखा जा सकता है।



सबसे मुश्किल काम दूरस्थ कंप्यूटर और क्लाउड सेवा के बीच एक स्थायी कनेक्शन को व्यवस्थित करना था। लंबे और थकाऊ प्रयोगों (बादल को तैनात करने में मूर्त समय लगता है) के परिणामस्वरूप, एक कार्यशील समाधान दिखाई दिया जिसने लक्ष्य को प्राप्त करने का विश्वास दिया।

हम नेटवर्क उपकरण से कुछ भी कॉन्फ़िगर किए बिना दूरस्थ कंप्यूटर को क्लाउड से कनेक्ट करने में सक्षम थे। हमारे लिए, यह एक सफलता थी।

अब कार्य था कमांड को प्रशासक से क्लाउड में स्थानांतरित करना, और फिर कंप्यूटर पर और उससे उत्तर प्राप्त करना। हम इस तथ्य पर बसे हैं कि WMI का उपयोग करने के लिए एक सार्वभौमिक समाधान होगा। इसके अलावा, WMI के बारे में क्लाउड सेवा को कुछ भी पता नहीं होना चाहिए। इसका कार्य अग्रेषित कर रहा है। यह कल्पना की गई थी कि क्लाउड सेवा को और दूरस्थ कंप्यूटर पर क्लाइंट सॉफ़्टवेयर को शायद ही कभी अपडेट किया जा सके (अब यह कंसोल में एक बटन दबाकर नवीनतम संस्करण में अपडेट किया गया है)।

एक उदाहरण:
स्थापित सेवाओं की सूची के लिए प्रशासक से एक अनुरोध भेजा जाता है (चयन करें * Win32_Service से) प्लस उन क्षेत्रों का एक सेट जिनके मूल्यों की हमें आवश्यकता है। यह सब JSON द्वारा क्रमबद्ध है, पैक किया जाता है, एन्क्रिप्ट किया जाता है और क्लाउड में प्रेषित होता है। क्लाउड में, डेटा को कतार में लिखा जाता है और फिर उस सेवा से इसे निकाल लिया जाता है जिससे दूरस्थ कंप्यूटर कनेक्ट होता है।
ग्राहक, अनुरोध प्राप्त करने के बाद, इसे पूरा करता है। परिणाम JSON द्वारा क्रमांकित किया जाता है, पैक किया जाता है, एन्क्रिप्ट किया जाता है, और व्यवस्थापक को रिवर्स ऑर्डर में पारित किया जाता है।

WMI का उपयोग केवल एक अनुरोध तक सीमित नहीं है, कार्यों और प्रक्रियाओं की कॉल को लागू किया जाता है। उदाहरण के लिए, किसी भी सेवा को रोका जा सकता है।



ऐसा लगता है कि सब कुछ सरल है, लेकिन यह मत भूलो कि अगर हम एक स्केलेबल समाधान बनाने की योजना बनाते हैं, तो हम क्लाउड में अपनी सेवा के कई उदाहरणों के साथ काम किए बिना नहीं कर सकते। उनके साथ काम करने के लिए विकास में अपने अनुभव के कुछ संशोधन की आवश्यकता होती है। आपको हमेशा ध्यान रखना चाहिए कि एक उदाहरण नहीं है, लेकिन कई हैं, और वे समानांतर में काम करते हैं। यदि आप कुछ विशेष करना चाहते हैं - इसके बारे में बाकी प्रतियों को सूचित करना न भूलें। उदाहरण के लिए, बिलिंग। जब प्रत्येक उदाहरण डेटाबेस के माध्यम से जाता है और ग्राहक के संतुलन की गणना करता है, तो इसे हर बार कम करना बेहद अप्रिय होगा। यह विकल्प उदाहरण के रूप में दिखाया गया है कि क्या हो सकता है, हालांकि हम वर्तमान में भविष्य में इस समस्या को खत्म करने के लिए काम कर रहे हैं।



सेवा बनाते समय, हम इस तथ्य से आगे बढ़े कि ज्यादातर मामलों में दूरस्थ डेस्कटॉप तक पहुंच होना आवश्यक नहीं है। प्रक्रियाओं, सेवाओं आदि का सीधा नियंत्रण पर्याप्त है। यह वेब इंटरफ़ेस के माध्यम से तेज़ और आसान है।



फिर भी, दूरस्थ डेस्कटॉप बहुत लोकप्रिय है और इसके कार्यान्वयन के लिए कंप्यूटर के बीच एक सीधा संबंध आवश्यक है। क्लाउड के माध्यम से इस तरह की जानकारी को स्थानांतरित करना तर्कहीन है, क्योंकि स्क्रीन को अपडेट करने में देरी कई सेकंड तक पहुंच सकती है।

यूडीपी होल पंचिंग को लागू करना

सबसे दिलचस्प काम रिमोट डेस्कटॉप एक्सेस सिस्टम का कार्यान्वयन था। समय बचाने के लिए, एक तैयार वीएनसी कार्यान्वयन लेने का निर्णय लिया गया था, जो, हालांकि, अपनी समस्याओं को हल करता है: क्लाइंट और वीएनसी सर्वर को सीधे कनेक्ट करना असंभव था। एकमात्र समाधान बिचौलियों का निर्माण करना था जिनका कार्य यातायात को रिले करना है। इस प्रकार, वीएनसी क्लाइंट और सर्वर "सोचेंगे" कि वे स्थानीय रूप से काम करते हैं, जब वास्तव में उनके बीच का सारा ट्रैफ़िक हम इंटरनेट पर प्रसारित करेंगे।

नेट ट्रावल

सवाल खुला रहा: बिचौलियों के बीच सूचना कैसे हस्तांतरित की जाए? पहला विकल्प जो दिमाग में आता है - बादल के माध्यम से सब कुछ चलाने के लिए - कितना महंगा है यह एक अप्रभावी तरीका है। हर चीज को सीधे कनेक्ट करना ज्यादा बेहतर है। यह वह जगह है जहाँ हम मानक NAT ट्रैवर्सल समस्या के पार आते हैं।



नेटवर्क एड्रेस ट्रांसलेशन (NAT) क्लाइंट के बीच सीधा संबंध स्थापित करना असंभव बनाता है। NAT स्थानीय पतों का अनुवाद करने की प्रक्रिया है जो इंटरनेट से बाहरी लोगों के लिए सुलभ नहीं हैं। NAT को बायपास करने के कई मानक तरीके हैं: एक पोर्ट खोलें, एक वीपीएन बढ़ाएँ।

दुर्भाग्य से, उनमें से कोई भी हमें सूट नहीं करता है, क्योंकि यह तुरंत सभी आवश्यक घटकों की स्थापना को जटिल बनाता है (और फिर भी हम चाहते हैं कि किसी इंस्टॉलेशन मशीन पर क्लाइंट इंस्टॉलेशन किसी व्यवस्थापक की सहायता से कम से कम उन्नत उपयोगकर्ताओं के लिए सुलभ हो)। इसलिए, हम यूडीपी होल पंचिंग तंत्र का उपयोग करेंगे।

यूडीपी होल पंचिंग

यूडीपी छेद छिद्रण दो कंप्यूटरों को सीधे जोड़ने के लिए एक विधि है जो NAT के पीछे हैं। कनेक्शन शुरू करने के लिए, एक तृतीय पक्ष की आवश्यकता होती है - एक सर्वर जो दोनों कंप्यूटरों को दिखाई देता है। आमतौर पर सार्वजनिक STUN सर्वर का उपयोग किया जाता है।

तो, हमारा काम क्लाइंट को रिमोट मशीन और कंसोल पर सीधे कनेक्ट करना है। ऐसा करने के लिए, आपको कई कदम उठाने होंगे:

• बाहरी आईपी और रिमोट मशीन के पोर्ट का पता लगाएं। ऐसा करने के लिए, हम STUN का उपयोग करते हैं, एक नेटवर्क प्रोटोकॉल जो आपको बाहरी आईपी पते को निर्धारित करने की अनुमति देता है।
• इस जानकारी को हमारे आवेदन में स्थानांतरित करें।
• एक कनेक्शन स्थापित करें और इसे डेटा एक्सचेंज के लिए आगे उपयोग करें

यह कोड में कैसे दिखता है?

सिद्धांत रूप में, सब कुछ सरल है। यह सब व्यवहार में कैसे दिखता है?



जैसा कि आप ऊपर की छवि से देख सकते हैं, थोड़ा और अधिक जटिल है। सबसे पहले, हम अपने आवेदन से एक कनेक्शन अनुरोध भेजते हैं, जो क्लाइंट मशीन (चरण 1 और 2) पर क्लाउड के माध्यम से एप्लिकेशन को प्रेषित किया जाता है। क्लाइंट मशीन अपने बाहरी पते और STUN सर्वर (चरण 3 और 4) से पोर्ट का अनुरोध करती है। नेटवर्क पर STUN प्रोटोकॉल के कई कार्यान्वयन हैं।

string address = String.Empty; udpClient = new UdpClient(); udpClient.AllowNatTraversal(true); ResultSTUN result = ClientSTUN.Query("stun.ekiga.net", 3478, udpClient.Client); if (result.NetType == UDP_BLOCKED) { /*   */ } else { address = result.PublicEndPoint.ToString(); } 

क्योंकि हमारा समाधान यूडीपी का उपयोग करता है, हम क्लाइंट से कनेक्ट करने के लिए एक ही सॉकेट का उपयोग कर सकते हैं (जो इसे टीसीपी से अलग करता है)।

इन सरल जोड़तोड़ के बाद, पते में ग्राहक मशीन का बाहरी पता और पोर्ट (या एक त्रुटि संदेश) होगा। यह मूल्यवान जानकारी क्लाउड (चरण 5 और 6) के माध्यम से प्रबंधन कंसोल को प्रेषित की जाती है। एक कनेक्शन बनाना, बंदरगाह और पते को जानना, पहले से ही एक तकनीकी मामला है। अब हम अपनी जरूरत की सारी जानकारी ट्रांसफर कर सकते हैं।

NAT ट्रेवर्सल का कार्य यूडीपी का उपयोग करके बस और सुरुचिपूर्ण ढंग से हल किया जाता है, लेकिन क्या होगा अगर हम टीसीपी के सभी फायदे चाहते हैं: गारंटी पैकेट वितरण, डेटा अखंडता, दोहराव की कमी, आदि? पहला विचार जो मन में आता है वह है यूडीपी के शीर्ष पर अपने प्रोटोकॉल को लिखना। स्वाभाविक रूप से, हम इस समस्या का सामना करने वाले पहले नहीं हैं। इसलिए, एक छोटी खोज के बाद, आप लिंडग्रेन.नेटवर्क जैसे समाधान पा सकते हैं, जो अंततः हमारे आवेदन में उपयोग किया जाता है।