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 डिफ़ॉल्ट रूट अपने स्वयं के प्राधिकरण वाला अलग निर्णय है, इसका दुष्प्रभाव नहीं।

संबंधित लेख