AWS Client VPN जोडिएको छ तर इन्टरनेट छैन: रुट जाँच

AWS Client VPN जोडिएको छ तर इन्टरनेट पहुँच छैन? क्लाइन्ट रुट, इन्डपोइन्ट अनुमति, सबनेट निकास र DNS यही क्रममा जाँच्नुहोस्।

तपाईं AWS Client VPN इन्डपोइन्टमा जोडिनुभएको छ, निजी सबनेटले जवाफ दिन्छ, र तैपनि हरेक सार्वजनिक पृष्ठ समय सकिएर अन्त्य हुन्छ। यो संयोजनले समस्यालाई व्यवस्थित पक्षका तीनमध्ये एउटा वस्तुमा सीमित गर्छ: क्लाइन्टले स्थापना गर्ने रुट, इन्डपोइन्टको रुट र त्यसको अनुमति नियम, वा सम्बन्धित सबनेटको अर्को हप। म तिनलाई यही क्रममा जाँच्छु, किनकि हरेक विफलता क्लाइन्टबाट फरक देखिन्छ। यो मार्गदर्शन VPC सँग सम्बन्धित व्यवस्थित इन्डपोइन्टका लागि हो, EC2 इन्स्टेन्समा OpenVPN सर्भर वा Cloud WAN वा Transit Gateway जडानका लागि होइन।

क्लाइन्टले वास्तवमा के रुट गर्छ त्यसबाट सुरु गर्नुहोस्

जोडिएको अवस्थाले TLS सत्र र क्लाइन्टलाई CIDR तोकिएको कुरा प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन. टनेल चालु हुँदा सार्वजनिक ठेगाना कहाँ जान्छ भनी अपरेटिङ सिस्टमलाई सोध्नुहोस्। Linux मा ip route get 1.1.1.1 ले टनेल इन्टरफेसको नाम बताउनुपर्छ; macOS मा netstat -rn -f inet | head -5 ले पूर्वनिर्धारित प्रविष्टि देखाउँछ; Windows मा Find-NetRoute -RemoteIPAddress 1.1.1.1 ले छानिएको इन्टरफेस र अर्को हप देखाउँछ।

त्यसपछि स्प्लिट-टनेल झन्डा पढ्नुहोस्, किनकि इन्डपोइन्टले प्रकाशित गरेका रुटहरू नै क्लाइन्टले टनेलमा पठाउने एकमात्र गन्तव्य हुन् कि होइन भन्ने यसले तय गर्छ:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

जब SplitTunnel true हुन्छ, सार्वजनिक गन्तव्यले टनेल प्रयोग गर्छ केवल जब इन्डपोइन्टले त्यसलाई ढाक्ने रुट प्रकाशित गर्छ, त्यसैले नभएको 0.0.0.0/0 ले त्यो ट्राफिक स्थानीय इन्टरफेसमा छाड्छ। यदि false छ भने, क्लाइन्टले ट्राफिक समात्छ, तर इन्डपोइन्टले अझै रुट र अनुमति दिनुपर्छ; नत्र प्याकेट टनेलभित्र पस्छ र त्यहीँ रोकिन्छ। दुईमध्ये कुनै पनि सेटिङ बदलेपछि क्लाइन्ट फेरि जोड्नुहोस्, किनकि रुट र DNS सर्भर जोडिने बेलामा दिइन्छ र चलिरहेको क्लाइन्टले पुरानो सेट राख्न सक्छ।

इन्डपोइन्ट रुट र अनुमति नियम अलग-अलग पढ्नुहोस्

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

हरेक रुटको ठ्याक्कै एउटा लक्ष्य सबनेट हुन्छ, त्यसैले तीन सम्बन्धलाई प्रत्येकका लागि मिल्ने पूर्वनिर्धारित रुट चाहिन्छ। AWS ले यो कभरेज आवश्यकता अभिलेख गर्छ, र कमीको व्यावहारिक लक्षण भनेको एउटा सबनेटबाट काम गर्ने र अर्कोबाट अड्किने प्रयोगकर्ता हो, जसलाई हराएको रुटको सट्टा बेलाबेलामा आउने खराबीका रूपमा पढिन्छ। आधिकारिक Client VPN परिदृश्य कागजात ले यी रुटहरू पर्ने सार्वजनिक सबनेट व्यवस्थाको वर्णन गर्छ।

अनुमति दोस्रो वस्तु हो। जब कुनै नियमले सार्वजनिक गन्तव्य ढाक्दैन, टनेलले प्याकेट बोक्छ र सेवाले त्यसलाई फाल्छ, त्यसैले निजी स्रोतहरू चलिरहन्छन् तर इन्टरनेट चल्दैन:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR का लागि नियमले 0.0.0.0/0 बारे केही भन्दैन। पूरा टनेलका लागि छुटेका भाग थप्नु भनेको हरेक सम्बन्धित सबनेटका लागि एउटा रुट र पछि लेखापरीक्षण गर्न सकिने अनुमति नियम:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all ले इन्डपोइन्टका हरेक क्लाइन्टलाई गन्तव्य दिन्छ, त्यसैले टनेल पूरा हुनुपर्ने बेलासम्म मात्र राख्नुहोस्; जोड्न समूह भए डाइरेक्टरी समूहमा बाँधिएको नियम राम्रो हुन्छ।

प्याकेटलाई सम्बन्धित सबनेटबाट बाहिर पछ्याउनुहोस्

इन्डपोइन्ट रुटले AWS ले त्यो प्याकेट त्यो सबनेटलाई दिन्छ भन्ने तय गर्छ। त्यसपछिको अर्को हप यसले तय गर्दैन, त्यो सबनेटको आफ्नै VPC रुट तालिकामा हुन्छ:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

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

यो हपमा दुई फिल्टर बसेका छन्। लक्ष्य सञ्जाल सम्बन्धमा लगाइएको सुरक्षा समूहले सार्वजनिक गन्तव्यतर्फ जाने बाहिरी ट्राफिकलाई अनुमति दिनुपर्छ, र लागू हुने कुनै पनि सञ्जाल ACL ले अनुरोध र अल्पकालीन पोर्टमा फर्कने ट्राफिकलाई अनुमति दिनुपर्छ। निर्बन्धक सम्बन्ध सुरक्षा समूह निजी पहुँच चल्ने तर सार्वजनिक नचल्ने सामान्य कारण हो।

तीनवटै एकैपटक नबदली लक्षणबाट पहिलो तह छान्नुहोस्:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS विफलतालाई मृत रुटबाट अलग गर्नुहोस्

नाम विश्लेषण अग्रेषणभन्दा फरक तरिकाले असफल हुन्छ, र पूरा टनेलले यो भिन्नतालाई महत्त्वपूर्ण बनाउँछ किनकि धकेलिएको रिजोल्भरमा अब टनेलबाट पुगिन्छ। यदि इन्डपोइन्टले VPC DNS सर्भर तोक्छ भने, तिनका ठेगानालाई अरू कुनै गन्तव्यजस्तै रुट कभरेज र अनुमति चाहिन्छ। कुन विफलता छ हेर्न रिजोल्भरलाई सिधै सोध्नुहोस्: dig +short example.com @10.0.0.2, वा nslookup example.com 10.0.0.2 Windows मा।

जब सङ्ख्यात्मक URL ले जवाफ दिन्छ र नाम भएकोले दिँदैन, पूर्वनिर्धारित रुट सम्पादन रोक्नुहोस् र DNS मा काम गर्नुहोस्। IP ठेगानामा गरिएको अनुरोधले नाम भएको भर्चुअल होस्ट र त्यसको प्रमाणपत्रबारे केही प्रमाणित गर्दैन, त्यसैले अन्तिम जाँचमा एउटा नाम भएको परीक्षण राख्नुहोस्।

समयले मद्दत गर्छ। केही सेकेन्डभित्र जवाफ नपाउने TCP जडानले रुटिङ वा फिल्टरतर्फ संकेत गर्छ, जबकि नाम खोजभित्र अड्किएको अनुरोधले रिजोल्भरतर्फ संकेत गर्छ। रिजोल्भर पुग्न नसक्ने बेला पूर्वनिर्धारित रुट बदल्नाले सामान्यतया एउटा विफलता दुई बन्छ।

सफा रूपमा फर्काउनुहोस्, त्यसपछि निकास बाटो प्रमाणित गर्नुहोस्

दुवै वस्तु थपिने प्रकृतिका थिए, त्यसैले फर्काउनु भनेको मर्मत होइन, मेट्नु हो:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

छोटो सूचीमा टुङ्ग्याउनुहोस् र अन्तिम बुँदालाई कागजात होइन, परिवर्तनको भाग ठान्नुहोस्:

  • हरेक सम्बन्धित सबनेटका लागि एउटा 0.0.0.0/0 इन्डपोइन्ट रुट।
  • तपाईं सेवा गर्न चाहनुभएका क्लाइन्टका लागि 0.0.0.0/0 ढाक्ने अनुमति नियम।
  • हरेक सम्बन्धित सबनेटमा blackhole नभएको VPC पूर्वनिर्धारित रुट।
  • सम्बन्ध सुरक्षा समूहको निकास, साथै ACL फर्कने ट्राफिक।
  • रिजोल्भर ठेगाना रुट र अनुमति भएको, नाम भएको अनुरोधले प्रमाणित।
  • रुट र नियमका लागि अभिलेख गरिएको रोलब्याक।

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

सम्बन्धित लेखहरू