AWS Client VPN की Site-to-Site: कनेक्शन कोण उघडते ते तपासा
Client VPN उपकरण किंवा वापरकर्त्याची प्रमाणीकरण करते; Site-to-Site गेटवेला AWS शी जोडते. चार तपासण्या ठरवतात की तुमच्या लॅपटॉपला किंवा शाखेला प्रत्यक्षात कोणती हवी आहे.
हे चार तपासण्या ठरवतात, आणि त्यांपैकी एकही प्रोटोकॉलचे नाव नाही. कनेक्शन कोण उघडते, AWS काय प्रमाणीकरण करते, कनेक्शन तुमच्या नेटवर्कशी कसे जोडले जाते, आणि त्याबरोबर कोणते राउटिंग व धोरण येते. यांना क्रमाने उत्तर द्या आणि उत्पादनाची निवड सहसा स्वतःच होते; डिझाइन विकत घेतल्यानंतर उत्तर दिल्यास, समस्येचा चुकीचा अर्धा भाग सोडवणाऱ्या बोगद्याचे तुम्ही समर्थन कराल. चारांपैकी एकही तुम्हाला सिफर निवडायला सांगत नाही, म्हणूनच प्रोटोकॉलपासून सुरू होणारे डिझाइन हे आवश्यकता कधीही लिहिल्या गेल्या नाहीत याचे लक्षण असते.
प्रत्येक तपासणी तुम्ही वापरणार असलेल्या प्रत्यक्ष एंडपॉइंट, क्लायंट आणि पत्ता-कुटुंबावर करा, श्रेणीवर नाही. व्यवस्थापित VPN उत्पादने ती ज्यांच्यासारखी दिसतात त्या OpenVPN व IPsec बांधकाम ब्लॉक्सपेक्षा वेगळी आहेत.
पहिले, कनेक्शन कोण उघडते
ज्याला प्रवेश हवा आहे ते लॅपटॉप, फोन किंवा एका प्रशासकाचे कार्यस्थान असेल, तर कनेक्शन दूरच्या उपकरणापासून सुरू होते आणि डिझाइन दूरस्थ-क्लायंट प्रवेश आहे. ज्याला प्रवेश हवा आहे ते एका राउटरमागील यंत्रांनी भरलेली शाखा असेल, तर कनेक्शन त्या राउटरपासून सुरू होते आणि डिझाइन गेटवे-ते-गेटवे आहे. हीच तपासणी बहुतेक प्रकरणे निकाली काढते, आणि विक्रेत्याच्या सादरीकरणाने संवाद आधीच सिफरभोवती चौकटीत बसवला असेल तेव्हा लोक जी वगळतात तीही हीच.
सुरू करणाऱ्या घटकाचे नाव सांगता येत नसेल तर इथे थांबा. एका बोगद्याने दोन्ही प्रकरणे सांभाळण्याचा प्रयत्न करणारे डिझाइन सहसा स्वतःला गेटवे असल्याचे भासवणाऱ्या क्लायंट सत्रावर संपते.
दुसरे, AWS काय प्रमाणीकरण करते
Client VPN मध्ये AWS संरचित क्लायंट किंवा वापरकर्ता ओळखीचे प्रमाणीकरण करते: प्रमाणपत्रे, निर्देशिका किंवा संलग्न ओळख, सेटअपनुसार. Site-to-Site VPN मध्ये AWS गेटवे पीअरच्या ओळखीचे प्रमाणीकरण करते. तो फरक दर्शनी नाही. एक मॉडेल वापरकर्ते जोडून व त्यांची ओळखपत्रे रद्द करून प्रमाण वाढवते; दुसरे एका गेटवेमागील सर्वांवर विश्वास ठेवून प्रमाण वाढवते.
गेटवे प्रमाणीकरण त्यामागील प्रत्येक कर्मचारी किंवा अनुप्रयोगाचे प्रमाणीकरण करत नाही, म्हणून बोगदा स्वतः विश्वासार्ह असला तरी अनुप्रयोग ओळख्या आणि साधन-स्तरीय प्रवेश कायम ठेवा. ज्या शाखेच्या राउटरकडे वैध पीअर ओळख आहे तिला त्या इमारतीतील प्रत्येक टेबलाला अधिकृत केले आहे असे स्वयंचलितपणे वाचू नये.
तिसरे, कनेक्शन कसे जोडले जाते
Client VPN, VPC उपजाळ जोडण्या किंवा समर्थित थेट Transit Gateway जोडणीद्वारे जोडले जाते. Site-to-Site VPN, AWS VPN लक्ष्याशी, सहसा आभासी खाजगी गेटवे किंवा Transit Gateway शी जोडले जाते. Client VPN स्थापत्य मार्गदर्शक Transit Gateway पर्यायाचे दस्तऐवजीकरण करते, आणि त्याचे अस्तित्व लॅपटॉप सत्राचे शाखा गेटवे करत नाही किंवा वर वर्णन केलेले क्लायंट प्रमाणीकरण व अधिकृतता काढत नाही.
मार्ग रचण्यापूर्वी तुमचे खाते व प्रदेश प्रत्यक्षात कोणत्या जोडणीला समर्थन देतात ते तपासा, नंतर ती जोडणी कोणाची आहे ते तपासा. दस्तऐवजात असूनही तुम्ही संरचित करू शकत नाही अशा नेटवर्कवर असलेला पर्याय हा पर्याय नाही.
चौथे, त्याबरोबर कोणते राउटिंग व धोरण येते
Client VPN तुम्ही परवानगी देता त्या गंतव्य नेटवर्कसाठी क्लायंट कनेक्शन व्यवस्थापन व अधिकृतता नियम आणते. जोडलेल्या वापरकर्त्याला अजूनही इच्छित एंडपॉइंट मार्ग, तो परवानगी देणारा अधिकृतता नियम, आणि साधन स्वतः मागणारा प्रवेश लागतो. Site-to-Site VPN ग्राहक गेटवेद्वारे प्रतिनिधित्व केलेल्या नेटवर्कदरम्यान राउट करते, डिझाइननुसार समर्थित स्थिर मार्ग किंवा BGP वापरून, त्यामुळे शाखा राउटरमागील वैयक्तिक यंत्रांना प्रत्येकाला क्लायंट लॉगिन लागत नाही.
कोणत्याही दिशेने श्रेणीतून असमर्थित वर्तनाचा अंदाज करू नका. दूरस्थ-प्रवेश VPN सार्वत्रिकपणे परतीचा रहदारी वाहून नेण्यास किंवा गेटवे रचना समर्थन देण्यास असमर्थ नाहीत, आणि IPsec NAT कडून स्वयंचलितपणे अडवले जात नाही — AWS NAT प्रवास व ग्राहक-गेटवे आवश्यकता दस्तऐवजीकरण करते, आणि खरी मर्यादा समर्थित गेटवे संरचना आहे. क्लायंटकडे सुरू होणाऱ्या कनेक्शनची मागणी करण्यापूर्वी किंवा एका सत्रामागे LAN पुढे पाठवण्यापूर्वी तुमच्या एंडपॉइंटच्या मर्यादा तपासा. तीच सावधानता पत्ता-कुटुंबांनाही लागू आहे: IPv4 वर चालणारा एंडपॉइंट IPv6 मार्ग दर्शवत नाही, म्हणून तुमचा क्लायंट किंवा गेटवे प्रत्यक्षात ज्या कुटुंबावर वाटाघाटी करेल त्याची पुष्टी करा.
Site-to-Site VPN प्रत्येक कनेक्शनला दोन बोगदे देते, आणि ती पुनरावृत्ती गृहीत धरता येणारे वैशिष्ट्य नाही तर डिझाइनचे काम आहे. ग्राहक-गेटवेचे संचालन, मार्ग अपयश-हस्तांतरण आणि चाचणी व्याप्ती सर्वांचे नियोजन करावे लागते; एका लॅपटॉप सत्राची अमूर्त VPN सर्व्हरशी तुलना केल्याने दोन्हींपैकी कशाबद्दलही काही सिद्ध होत नाही.
दोन्ही डिझाइन भेटतात तिथे
सेवा परस्पर-अपवादात्मक नाहीत, आणि नेहमीचा उत्पादन आकार दोन्ही वापरतो: कर्मचारी Client VPN वर, शाखा नेटवर्क Site-to-Site वर, बोलणे आवश्यक असलेल्या गंतव्यांदरम्यान स्पष्ट मार्ग व प्रवेश धोरणासह. तक्ता चार तपासण्यांचा सारांश आहे, त्या करण्याचा पर्याय नाही.
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
दोन्ही उत्पादनांपैकी कोणीही बदलू शकत नाही अशी एक गोष्ट: एन्क्रिप्शनची आवश्यकता VPN एंडपॉइंटच्या पलीकडे जाणाऱ्या अनुप्रयोगासाठी TLS. तुमची अनुपालन व्याप्ती अनुप्रयोगावर संपत असेल, तर बोगदा वाहतूक आहे आणि प्रमाणपत्र अजूनही नियंत्रण आहे.
डिझाइन आढाव्यापूर्वी चार उत्तरे लिहून ठेवा, प्रत्येकी एका ओळीत. त्यांपैकी दोन विसंगत असतील — उदाहरणार्थ, वापरकर्ता-प्रमाणित क्लायंट डिझाइन आणि शाखा-आकाराची राउटिंग आवश्यकता — तर ती विसंगती हाच निष्कर्ष आहे, आणि कटओव्हरच्या वेळी पाहण्यापेक्षा आता पाहणे स्वस्त आहे.