AWS Client VPN स्प्लिट टनेल: कुन रुटहरू प्रकाशित गर्नुपर्छ

कन्सोलले स्प्लिट टनेलका लागि टगल दिन्छ, त्यसैले निर्णय चेकबक्स जस्तो लाग्छ। त्यस्तो होइन। क्लाइन्टसम्म वास्तवमा पुग्ने कुरा एन्डपोइन्टको प्रकाशित रुट सेट हो, र त्यही सूचीले कुन निजी प्रिफिक्सहरूले टनेल प्रयोग गर्ने, सामान्य इन्टरनेट ट्राफिक स्थानीय रहने वा AWS बाट बाहिर जाने, र क्लाइन्टले अझै कुन रिजोल्भरसँग बोल्न सक्ने निर्धारण गर्छ। तीन प्रश्नले डिजाइन टुंग्याउँछन्, र प्रत्येकको जवाफ नराम्रोसँग दिन सकिन्छ जबकि जडान अझै सफल हुन्छ।

स्प्लिट टनेल झन्डा गन्तव्यहरूको सूची होइन

AWS ले स्प्लिट टनेलिङलाई जडान स्थापना हुँदा एन्डपोइन्टका रुटहरू क्लाइन्टको रुट तालिकामा थप्ने काम भनी वर्णन गर्छ। निजी VPC का लागि रुटले टनेललाई त्यही गन्तव्यमा सीमित गर्छ; बाँकी सबै क्लाइन्टको सामान्य बाटो पछ्याउँछ। पूर्वनिर्धारित रुट फरक प्रभाव भएको फरक निर्देश हो, त्यसैले स्प्लिट टनेलको कागजात यो मोडका लागि कन्फिगर गरिएको एन्डपोइन्टमा 0.0.0.0/0 प्रकाशित गर्न विरुद्ध चेतावनी दिन्छ: यसले जडान विस्तार गर्नुको सट्टा प्रायः तोड्छ। एन्डपोइन्ट रुट तालिका नीति हो, र क्लाइन्ट रुट तालिका तपाईंले जाँच्न सक्ने नतिजा हो।

एन्डपोइन्ट रुट तालिका र क्लाइन्टमा स्थापित रुटहरू सँगै पढ्नुहोस्। लेबलले मनसाय बताउँछ; रुटहरूले के हुन्छ बताउँछन्।

पहिलो निर्णय: सामान्य इन्टरनेट ट्राफिक स्थानीय रहनुपर्छ?

यदि ब्राउजिङले प्रयोगकर्ताको आफ्नै जडान प्रयोग गर्नुपर्ने हो भने, कामलाई आवश्यक निजी गन्तव्यहरू मात्र प्रकाशित गर्नुहोस् र त्यहीँ रोक्नुहोस्। पूर्ण टनेलको ट्युटोरियलमा एउटा थियो भनेर इन्टरनेट रुट नथप्नुहोस्, र अतिरिक्त रुटले सुरक्षा सुधार्छ भनी नमान्नुहोस्। यसले बाटो बदल्छ, नीति थप्दैन, र सामान्यतया तपाईंले बजेट नगरेको ढिलाइ लिन्छ।

यदि इन्टरनेट ट्राफिक AWS बाट बाहिर जानुपर्ने हो भने, कागजात गरिएको इन्टरनेट पहुँच वास्तुकला बनाउनुहोस्: एन्डपोइन्ट रुट, अधिकार नियम, सम्बन्धित सबनेटको बाटो, सुरक्षा नीति र काम गर्ने माथिल्लो निकास। केवल पूर्वनिर्धारित रुटले यीमध्ये केही पनि दिँदैन।

दोस्रो निर्णय: कुन निजी प्रिफिक्सहरू, र कसको अधिकारबाट?

वास्तविक कार्यभारलाई सेवा दिने सबैभन्दा सानो गन्तव्य सेट प्रकाशित गर्नुहोस्, र प्रत्येक सम्बन्धित सबनेटले तिनीहरूतर्फ रुट गर्न सक्छ भनी जाँच्नुहोस्. एन्डपोइन्टको रुट लक्ष्य र सबनेटको VPC रुटिङ फरक तह हुन्, र एउटामा भएको रुट अर्कोको प्रमाण होइन। अधिकार फेरि छुट्टै छ: गन्तव्य पुग्न सकिने भए पनि अस्वीकार हुन सक्छ, किनकि क्लाइन्टको समूहसँग त्यसलाई अनुमति दिने नियम छैन।

एक सफल सत्र परीक्षण गर्नुले एउटा मात्र बाटो प्रमाणित गर्छ। प्रत्येक सम्बन्धित सबनेट जाँच्नुहोस्, किनकि पछि थपिएको सबनेट सम्बन्ध नै हराएको रुट सामान्यतया बस्ने ठाउँ हो।

गन्तव्य नामबाट पुग्नुपर्ने हुँदा, अर्को प्रश्न रुटको होइन, नाम रिजोल्युसनको हो भन्ने ध्यान दिनुहोस्।

तेस्रो निर्णय: कुन रिजोल्भरले टनेल पछ्याउँछ?

क्लाइन्टले VPN बाट मात्र पुग्न सकिने DNS सर्भर पाउन सक्छ, र त्यो रिजोल्भर त्यसको ठेगाना आफै अधिकृत रुटभित्र भएमा मात्र काम गर्छ। दुवै आधा जाँच्नुहोस्: रिजोल्भरको ठेगानाले प्रकाशित रुट पछ्याउँछ, र सर्भरले एप्लिकेसनले सोध्ने नामहरूको जवाफ दिन्छ। ठेगानाले सफल तर होस्टनामले असफल हुने अनुरोधले नामकरणतर्फ संकेत गर्छ, रुटिङतर्फ होइन, र त्यो अवस्थामा टनेल डिबग गर्नु दिउँसो बर्बाद गर्छ।

सार्वजनिक नामहरू जडान अघिको जस्तै रिजोल्भ हुनुपर्छ, जुन तपाईंले के प्रकाशित गर्नुहुन्छ त्यसबारे सटीक हुनुको अर्को कारण हो।

रुट सेट परिवर्तन गर्नुहोस्, त्यसपछि दुवै संसार जाँच्नुहोस्

स्प्लिट टनेल एन्डपोइन्टमा रुट परिवर्तन गर्दा क्लाइन्ट जडानहरू रिसेट हुन्छन् भनी AWS ले कागजात गर्छ। त्यो ध्यानमा राखेर परिवर्तन योजना गर्नुहोस्: लागू गर्नुहोस्, समर्थित क्लाइन्टबाट फेरि जडान गर्नुहोस्, र सम्पादन अघि लागू गरिएको अवस्थामा भरोसा गर्नुको सट्टा स्थापित रुटहरू फेरि पढ्नुहोस्। पुरानो लागू अवस्था नै सही परिवर्तन बिग्रिएको देखिनुको सबैभन्दा सामान्य कारण हो।

एउटा निजी स्रोत र एउटा सार्वजनिक गन्तव्य दुवैले इच्छाएअनुसार व्यवहार गरेमा मात्र डिजाइन स्वीकार गर्नुहोस्, नाम र ठेगानाले, तपाईंले वास्तवमा समर्थन गर्ने ठेगाना परिवारहरूमा। प्रमाणीकरण गर्ने टनेल ठीकसँग विभाजन गर्ने टनेलसँग एउटै होइन।

रुट सूची तर्कको छेउमा रनबुकमा लेख्नुहोस्, ताकि अर्को व्यक्तिले जानाजान गरिएको बहिष्करण र बिर्सिएको बहिष्करण छुट्याउन सकोस्।