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 डीफॉल्ट मार्ग हा याचा दुष्परिणाम नव्हे, स्वतःच्या अधिकृततेसह वेगळा निर्णय आहे.

संबंधित लेख