EC2 Windows: VPN क्लाइंट, VPN सर्वर या AWS गेटवे?
Windows EC2 इंस्टेंस VPN सॉफ़्टवेयर चला सकता है, लेकिन क्लाइंट, स्व-प्रबंधित सर्वर और AWS गेटवे अलग भूमिकाएँ हैं जिनके मालिक भी अलग हैं।
एक टीम को Windows EC2 इंस्टेंस पर चल रहे ऐप के लिए VPN कनेक्टिविटी चाहिए, वह संगत क्लाइंट सॉफ़्टवेयर ढूँढती है, उसे इंस्टॉल करती है और फिर पूछती है कि VPC का बाकी हिस्सा उसका उपयोग क्यों नहीं कर सकता। इंस्टॉल काम कर गया; भूमिका कभी तय ही नहीं हुई। गेस्ट के अंदर चलने वाला सॉफ़्टवेयर ऐसा क्लाइंट हो सकता है जो किसी और के नेटवर्क में शामिल हो, ऐसा सर्वर हो सकता है जो अन्य क्लाइंट स्वीकार करे, या AWS-प्रबंधित VPN उत्पादों में से कोई भी न हो, और हर भूमिका आपके लिए अलग काम छोड़ती है।
लक्षण आमतौर पर गलत भूमिका होता है
आम लक्षण एक काम करती सुरंग है जो गलत समस्या हल करती है। VM के अंदर का क्लाइंट उस VM को बाहर जाने का रास्ता देता है; यह आपके लैपटॉप, दफ़्तर या किसी अन्य सबनेट को अंदर आने का रास्ता नहीं देता। VM के अंदर का सर्वर दूसरों को अंदर आने का रास्ता देता है, लेकिन अब लिसनर, प्रमाणीकरण और फ़ॉरवर्डिंग आपके पास है।
प्रबंधित सेवाएँ सेवा का संचालन AWS पर ले जाती हैं और डिज़ाइन आपके पास छोड़ देती हैं। Site-to-Site VPN नेटवर्क को ग्राहक गेटवे और AWS गेटवे के ज़रिए जोड़ता है, और Client VPN दूरस्थ उपकरणों को प्रबंधित एंडपॉइंट देता है। दोनों स्थितियों में रूट, प्राधिकरण नियम और पहचान का स्रोत आपका कॉन्फ़िगरेशन हैं, और दोनों में से कोई भी उत्पाद Windows गेस्ट के अंदर सामान्य-उद्देश्य वाला क्लाइंट इंस्टॉल नहीं करता।
चार रूप संभव हैं, और तालिका उन्हें इस आधार पर अलग करती है कि क्या किससे जुड़ता है और परिचालन का बोझ कौन उठाता है।
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
उत्पाद का नाम नहीं, पंक्ति पढ़ें: वही Windows इंस्टेंस उसमें चल रहे सॉफ़्टवेयर के आधार पर दो अलग पंक्तियों में हो सकता है।
VM के अंदर क्लाइंट: VM किसी नेटवर्क में शामिल होता है
बाहर जाने वाले क्लाइंट को कुछ भी इंस्टॉल करने से पहले Windows बिल्ड, आर्किटेक्चर और ड्राइवर आवश्यकताओं की जाँच करनी होती है। क्लाइंट इंस्टेंस पर रूट और DNS बदलेगा, जिससे वहाँ पहले से चल रही सेवाएँ प्रभावित हो सकती हैं, जिनमें दूरस्थ प्रशासन के लिए उपयोग किया जाने वाला रास्ता भी शामिल है। एडाप्टर का नाम और क्लाइंट द्वारा सेट किया गया इंटरफ़ेस मीट्रिक दर्ज करें, क्योंकि नया इंटरफ़ेस मौजूदा पर प्राथमिकता ले सकता है। यदि इंस्टेंस SSH या RDP के बजाय सत्र प्रबंधक से प्रबंधित है, तो पुष्टि करें कि क्लाइंट जुड़ने के बाद भी वह रास्ता काम करता है।
क्लाइंट को सक्षम करने से पहले तय करें कि उसे कौन-सा ट्रैफ़िक ले जाना चाहिए। पूरी सुरंग प्रबंधन सत्र को पकड़ सकती है और आपको बाहर बंद कर सकती है, और विभाजित सुरंग इंस्टेंस को निजी नेटवर्क तक पहुँचने दे सकती है जबकि उसका अन्य ट्रैफ़िक दूसरे रास्ते से जाता है। दूसरा प्रबंधन रास्ता उपलब्ध रखकर परीक्षण करें, और क्लाइंट द्वारा इंस्टॉल किए गए रूट दर्ज करें ताकि बाद का बदलाव समझाया जा सके।
VM के अंदर सर्वर: अन्य क्लाइंट उसमें शामिल होते हैं
स्व-प्रबंधित सर्वर के लिए लिसनर, प्रमाणपत्र या कुंजी सामग्री, उपयोगकर्ता डेटाबेस और फ़ॉरवर्डिंग नियम आपके हैं। यदि सर्वर अन्य क्लाइंट के लिए ट्रैफ़िक फ़ॉरवर्ड करता है, तो इंस्टेंस राउटर बन जाता है, और इसके लिए गेस्ट-स्तरीय फ़ॉरवर्डिंग के साथ AWS-स्तर पर रूट और सुरक्षा समूह में बदलाव आवश्यक हैं।
गेस्ट से लिसनर जाँचें और फिर किसी अन्य सबनेट से, फिर उस होस्ट को जाँचें जिसके लिए इंस्टेंस फ़ॉरवर्ड करता है। स्वस्थ स्थानीय सेवा फ़ॉरवर्ड किए गए रास्ते के बारे में कुछ सिद्ध नहीं करती, इसलिए दोनों परिणाम बदलाव नोट में दर्ज करें।
प्रबंधित गेटवे सेवा रखते हैं, आपका एक्सेस डिज़ाइन नहीं
AWS Site-to-Site VPN ग्राहक-गेटवे और AWS-गेटवे सुरंग भूमिकाओं का दस्तावेज़ीकरण करता है, और वह कनेक्शन खरीदने से हर दूरस्थ-एक्सेस डिज़ाइन प्रतिस्थापित नहीं होता। Client VPN क्लाइंट पर्सोना के साथ प्रबंधित एंडपॉइंट का दस्तावेज़ीकरण करता है, जबकि प्राधिकरण नियम और लक्ष्य रूट आपके ही रहते हैं। AWS एंडपॉइंट और उसके प्रमाणपत्र चालू रखता है; कौन किस ऐप तक पहुँच सकता है, यह अब भी वह प्राधिकरण नियम है जिसे आप लिखते और बनाए रखते हैं।
पाँच अक्षों पर उत्पादों में से चुनें: हर एक कौन-सी भूमिका निभाता है, कौन-से प्रोटोकॉल स्वीकार करता है, किस पहचान स्रोत की अपेक्षा करता है, ट्रैफ़िक कैसे फ़ॉरवर्ड होता है और उपलब्धता कैसे दी जाती है। फ़ोरम थ्रेड में उद्धृत किसी भी एकल थ्रूपुट आंकड़े को अनदेखा करें, क्योंकि प्रकाशित क्षमता सेवा के साथ बदलती है। और यह न मानें कि प्रबंधित सुरंग जोड़ी किसी मनमाने गेस्ट क्लाइंट का व्यवहार बदल देती है।
उत्पाद से पहले भूमिका चुनें
एक वाक्य लिखें जो दिशा बताए: यह VM किसी नेटवर्क में शामिल होता है, यह VM क्लाइंट स्वीकार करता है, या कोई AWS गेटवे परिभाषित नेटवर्क जोड़ता है।
वह वाक्य उत्पादों की छोटी सूची, सॉफ़्टवेयर का मालिक और वे विफलता मोड तय करता है जिन्हें आप डीबग करेंगे। यदि आवश्यकता दूरस्थ उपयोगकर्ताओं के किसी ऐप तक पहुँचने की है, तो ऐप के VM में इंस्टॉल क्लाइंट गलत रूप है। यदि आवश्यकता एक VM के साझेदार नेटवर्क तक पहुँचने की है, तो प्रबंधित साइट-से-साइट गेटवे कार्य की आवश्यकता से अधिक मशीनरी है। दोनों उत्तर वैध हैं; उनमें से केवल एक आपके लिखे वाक्य से मेल खाता है।