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ने भागीदार नेटवर्कपर्यंत पोहोचणे असेल, तर व्यवस्थापित साइट-ते-साइट गेटवे कामाच्या गरजेपेक्षा जास्त यंत्रणा आहे. दोन्ही उत्तरे वैध आहेत; त्यातील फक्त एकच तुम्ही लिहिलेल्या वाक्याशी जुळते.