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। यदि तपाईंको अनुपालन दायरा अनुप्रयोगमा टुंगिन्छ भने, सुरुङ यातायात हो र प्रमाणपत्र अझै नियन्त्रण हो।
डिजाइन समीक्षाअघि चार जवाफ लेख्नुहोस्, प्रत्येक एक लाइनमा। तीमध्ये दुई विरोधाभासी हुँदा — उदाहरणका लागि, प्रयोगकर्ता-प्रमाणित क्लाइन्ट डिजाइन र शाखा-आकारको राउटिङ आवश्यकता — त्यही विरोधाभास निष्कर्ष हो, र कटओभरको बेला देख्नुभन्दा अहिले देख्नु सस्तो पर्छ।