EC2 मा Access Server पूर्ण टनेल: एउटा चेकबक्स किन पर्याप्त छैन

EC2 इन्स्ट्यान्समा स्रोत र गन्तव्य जाँच बन्द गर्नु Access Server को इन्टरनेट निकासबारे सोधिने प्रश्नको सबैभन्दा धेरै दोहोरिने उत्तर हो, र एक्लैले तपाईंका ग्राहकका लागि केही गर्दैन। जाँच AWS को फर्वार्डिङ सीमा हो: यसले इन्स्ट्यान्सलाई आफ्नै ठेगाना नभएको स्रोत वा गन्तव्य भएका प्याकेट स्वीकार गर्न दिन्छ। यसले ग्राहकलाई इन्टरनेट ट्राफिक टनेलबाट पठाउन भन्दैन, माथितिर मार्ग बनाउँदैन र NAT थप्दैन। चेकबक्स नै सुविधा हो भन्ने भ्रम हो।

जाँचले वास्तवमा के नियन्त्रण गर्छ

प्रत्येक EC2 नेटवर्क इन्टरफेसले आफूतिर नपठाइएको ट्राफिक फाल्छ, जबसम्म इन्स्ट्यान्स राउटर, NAT उपकरण वा VPN गेटवेका रूपमा काम गर्दैन र तपाईंले त्यो जाँच बन्द गर्नुहुन्न। बन्द गर्नाले फर्वार्ड गर्ने अनुमति दिन्छ। अनुमति कन्फिगरेसन होइन: इन्स्ट्यान्सलाई अझै इन्टरनेट गेटवे वा NAT उपकरणसम्म मार्ग चाहिन्छ, VPC मार्ग तालिकालाई अझै मिल्ने प्रविष्टि चाहिन्छ, सुरक्षा समूहले अझै प्रवाहलाई अनुमति दिनुपर्छ, र सर्भरले अझै फर्कने ट्राफिक अनुवाद वा मार्गनिर्देशन गर्नुपर्छ।

केही बदल्नु अघि aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck प्रयोग गरी हालको मान जाँच्नुहोस्। यदि तपाईंले कन्सोलमा बदल्नुभयो भने, ग्राहक इन्टरनेटमा नपुगेकोले होइन, इन्स्ट्यान्सले अरूका लागि फर्वार्ड गर्ने भएकाले बदल्नुहोस्।

ग्राहकको मार्ग नीति Access Server को हो

Access Server 3 मा Access Controls खोल्नुहोस् र Internet Access and DNS खण्ड खोज्नुहोस्। Internet Gateway विकल्पले पूर्ण वा विभाजित टनेल दिन्छ; पूर्ण टनेलले ग्राहकलाई आफ्नो पूर्वनिर्धारित ट्राफिक VPN भित्र मार्ग गर्न भन्छ, विभाजित टनेलले इन्टरनेट ट्राफिक ग्राहकको स्थानीय मार्गमा राख्छ। उत्पादनको कार्यप्रवाहबाट सुरक्षित र लागू गर्नुहोस्, त्यसपछि परीक्षण ग्राहक पुन: जोड्नुहोस्, किनकि नीति जडानको समयमा दिइन्छ।

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

टनेलपछि प्याकेट ट्रेस गर्नुहोस्

ग्राहकले इन्टरनेट ट्राफिक टनेलमा पठाएपछि सर्भरले त्यो फर्वार्ड गर्नुपर्छ र सामान्यतया अनुवाद गर्नुपर्छ। Access Server ले आफ्नै NAT र मार्ग नियमहरू व्यवस्थापन गर्छ, त्यसैले उत्पन्न फाइलहरूमा Community OpenVPN नियम थप्नुको सट्टा प्रभावकारी कन्फिगरेसन पढ्नुहोस्; व्यवस्थापन नगरिएका नियमहरू अर्को उत्पादन अद्यावधिकमा अधिलेखन हुन्छन् वा ठोक्किन्छन्। sudo iptables -t nat -L -n -v वा nftables को बराबरले वास्तवमा के अनुवाद भइरहेको छ देखाउँछ।

AWS पक्ष छुट्टै मार्ग हो। सार्वजनिक सबनेटको इन्स्ट्यान्स इन्टरनेट गेटवेमा सिधै पुग्छ र आफ्नो सार्वजनिक ठेगाना वा लचिलो IP राख्छ। निजी सबनेटको इन्स्ट्यान्सलाई NAT गेटवे वा NAT इन्स्ट्यान्ससम्म मार्ग चाहिन्छ, र NAT उपकरणलाई आफ्नै इन्टरनेट गेटवेसम्म मार्ग चाहिन्छ। इन्टरनेट गेटवे VPC मा जोड्दा एक्लैले कुनै निजी स्रोतलाई सार्वजनिक फर्कने ठेगाना दिँदैन, त्यसैले एउटै Access Server सेटअप एउटा सबनेटमा काम गर्छ र अर्कोमा चुपचाप असफल हुन्छ।

इन्स्ट्यान्सको सबनेटसँग जोडिएको मार्ग तालिका जाँच्नुहोस्, VPC को मुख्य तालिका मात्र होइन। सबनेट सम्बन्धहरूले मुख्य तालिकालाई जित्छन्, र पुरानो सम्बन्ध काम गरिरहेको कन्फिगरेसन पुनर्निर्माणपछि रोकिने सामान्य कारण हो।

IP निकास र DNS छुट्टै राख्नुहोस्

एउटै ग्राहक एपबाट पहिले ठेगानाको शाब्दिक रूप र त्यसपछि नाम परीक्षण गर्नुहोस्। यदि curl -4 https://checkip.amazonaws.com ले सार्वजनिक ठेगाना फर्काउँछ तर होस्टनाम असफल हुन्छ भने टनेल र NAT मार्ग काम गरिरहेको छ र समस्या DNS मा छ: पठाइएको रिजोल्भर, ग्राहकको रिजोल्भर अवस्था, वा रिजोल्भर अवरोध गर्ने सुरक्षा समूह। Access Server को DNS सेटिङ त्यही Internet Access क्षेत्रमा छ, तर तिनीहरू फरक कोड मार्गबाट जान्छन्।

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

एउटा चेकबक्सले अनुसन्धान बन्द गर्न नदिनुहोस्

IPv6 छुट्टै निर्णय हो। IPv4 का लागि पूर्ण टनेल नीतिले IPv6 बोकिन्छ, रोकिन्छ वा चुहिन्छ भन्नेबारे केही भन्दैन, र दोहोरो स्ट्याक ग्राहकले IPv4 टनेलमा हुँदा आफ्नो स्थानीय IPv6 मार्ग प्रयोग गरिरहन सक्छ। तपाईंलाई साँच्चै महत्त्वपूर्ण ठेगाना परिवार परीक्षण गर्नुहोस्, र अर्को बन्द गर्नुपर्छ कि भन्ने स्पष्ट निर्णय गर्नुहोस्।

अन्तमा, विच्छेदित अवस्था परीक्षण गर्नुहोस्। पूर्ण टनेल चयनले जोडिएको अवस्थाको मार्ग नीति वर्णन गर्छ, टनेल खस्दा के हुन्छ भन्ने होइन। यदि आवश्यकता VPN बाहिर कुनै ट्राफिक भाग्न नहुने हो भने, त्यो kill-switch र फायरवालको प्रश्न हो, र मार्ग तालिकाबाट अनुमान गर्नुको सट्टा आफ्नै परीक्षण चाहिन्छ।