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 |
एक चीज़ जिसे दोनों में से कोई उत्पाद प्रतिस्थापित नहीं करता: ऐसे एप्लिकेशन के लिए TLS जिसकी एन्क्रिप्शन आवश्यकता VPN एंडपॉइंट से आगे तक जाती है। यदि आपका अनुपालन दायरा एप्लिकेशन पर समाप्त होता है, तो सुरंग परिवहन है और प्रमाणपत्र अब भी नियंत्रण है।
डिज़ाइन समीक्षा से पहले चार उत्तर लिख लें, हर एक एक पंक्ति में। जब उनमें से दो परस्पर विरोधी हों — मान लीजिए, उपयोगकर्ता-प्रमाणित क्लाइंट डिज़ाइन के साथ शाखा-आकार की रूटिंग आवश्यकता — तो वही विरोध निष्कर्ष है, और कटओवर के दौरान देखने से अभी देखना सस्ता है।