AWS Client VPN वर अधूनमधून प्रवेश: प्रत्येक जोडलेल्या सबनेटचे ऑडिट करा
काही AWS Client VPN सत्रे ॲपच्या VPC पर्यंत पोहोचतात तर काही वेळ संपून जातात. प्रथम प्रत्येक असोसिएशनच्या VPC रूट टेबलशी एंडपॉइंट रूटची तुलना करा.
एक वापरकर्ता कनेक्ट होतो, अंतर्गत ॲप उघडतो आणि उत्तर मिळवतो; त्याच एंडपॉइंटवरील सहकारी त्याच Wi-Fi वरील एकसारख्या लॅपटॉपवरून वेळ संपलेली पाहतो. हा नमुना एकापेक्षा जास्त जोडलेल्या सबनेट असलेल्या client VPN एंडपॉइंटचा ठसा आहे, जिथे मार्ग समान नाहीत. मी हे कन्सोलपासून बाहेरच्या दिशेने तपासतो, कारण उर्वरित तपासणी करण्यासारखी आहे की नाही हे दोन टॅब ठरवतात. क्लायंट कॉन्फिगरेशनमध्ये हे स्पष्ट करणारे काहीही नाही.
एंडपॉइंटपासून सुरुवात करा आणि असोसिएशनची यादी करा
VPC कन्सोलमध्ये Client VPN endpoints उघडा, एंडपॉइंट निवडा आणि Associations टॅब वाचा. प्रत्येक असोसिएशन हे उपलब्धता क्षेत्रातील सबनेट आहे, आणि कनेक्शन तयार होताना सेवा जे निवडते त्या सबनेटवर क्लायंट उतरतो. सबनेट ID आणि प्रत्येक प्रत्यक्षात वापरत असलेले रूट टेबल नोंदवा, कारण त्या दोन याद्या हीच तुम्ही करणार असलेली तुलना आहे.
एंडपॉइंट फक्त एक असोसिएशन दाखवत असेल, तर हा सिद्धांत चुकीचा आहे आणि क्लायंट हा अधिक चांगला संशयित आहे.
एंडपॉइंट रूट टेबलची प्रत्येक असोसिएशनशी तुलना करा
त्याच एंडपॉइंटवर Route table टॅब उघडा. तिथल्या प्रत्येक गंतव्य CIDR ला एक लक्ष्य असते, आणि client VPN मध्ये लक्ष्य हे गेटवे नसून असोसिएशन असते. AWS प्रत्येक जोडलेल्या सबनेटसाठी गंतव्य नोंद मागतो, त्यामुळे त्यापैकी फक्त एकाला लक्ष्य करणारा रूट प्रवेश सत्र कुठे उतरले यावर अवलंबून करतो. तुम्हाला खरोखर महत्त्वाचे असलेले गंतव्य तपासा, नंतर त्याचा अधिकृतता नियम तपासा, कारण रूट मार्ग देतो आणि नियम कोण वापरू शकतो हे ठरवतो.
दोन्ही स्तर तक्त्यात आणल्यावर बिघाड दिसणे टाळणे कठीण आहे.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
बहुतेक तिकिटांमध्ये दुसरी ओळ हीच संपूर्ण बग आहे. एंडपॉइंट रूट आहे, त्यामुळे कोणी पुढे पाहत नाही, आणि पॅकेट एका हॉपनंतर VPC च्या आत मरतो.
प्रत्येक सबनेटचा त्याच्या प्रभावी रूट टेबलपर्यंत मागोवा घ्या
स्पष्ट रूट टेबल असोसिएशन नसलेला सबनेट VPC चे मुख्य टेबल वारसाहक्काने घेतो. प्रत्यक्षात लागू असलेले टेबल वाचा, नाव बरोबर दिसणारे नाही, आणि ओळीवरील लेबलऐवजी गंतव्य व लक्ष्य यांची तुलना करा.
AWS चे अधूनमधून प्रवेश मार्गदर्शक हे असोसिएशनभर रूट कव्हरेज म्हणून मांडते, जे योग्य मॉडेल आहे. एंडपॉइंट पॅकेट सबनेटपर्यंत पोहोचवतो, आणि त्या सबनेटच्या टेबलला अजूनही ॲप्लिकेशन नेटवर्क कुठे आहे हे माहीत असणे आवश्यक आहे.
गहाळ ओळ तिच्या मालकीच्या टेबलमध्ये दुरुस्त करा. कार्यरत सबनेटमधून संपूर्ण रूट टेबल कॉपी केल्यास या सबनेटसाठी कधीच हेतू नसलेले इंटरनेट, उपकरण आणि अलगीकरणाचे पर्यायही कॉपी होतात, आणि ही देवाणघेवाण सहसा तुम्ही सुरू केलेल्या व्यत्ययापेक्षा वाईट असते.
अधिकृतता नियम तपासा, नंतर परतीचा मार्ग
अधिकृतता नियम प्रत्येक गंतव्यासाठी आणि प्रत्येक गटासाठी असतात, आणि रूटपासून वेगळे मूल्यमापन होतात. सर्वत्र रूट असूनही वापरकर्त्याच्या गटासाठी नियम नसलेले गंतव्य निरोगी दिसणाऱ्या रूट टेबलसह काळ्या छिद्रासारखे वागते.
परतीचा मार्गही तितक्याच लक्षणीय आहे. peering कनेक्शनला ॲप्लिकेशन VPC मध्ये क्लायंट CIDR कडे परत जाणारा रूट, दोन्ही टोकांना रहदारीला परवानगी देणारे सुरक्षा गट नियम आणि ती टाकून न देणारे नेटवर्क ACL लागतात. एकेरी पोहोच, म्हणजे ping चालते पण TCP हस्तांदोलन चालत नाही, सहसा VPN कडे नाही तर ACL किंवा सुरक्षा गटाकडे निर्देश करते.
एंडपॉइंटचे स्वतःचे सुरक्षा गट असोसिएशनच्या लवचिक नेटवर्क इंटरफेसवर असतात, त्यामुळे क्लायंट CIDR वरून ॲप्लिकेशन पोर्टला परवानगी देणारा नियम केवळ इन्स्टन्सशी नाही तर असोसिएशनशी जोडावा लागतो.
एका भाग्यवान विनंतीने नाही, पुन्हा कनेक्ट करून पडताळा
split tunnel सह, कनेक्शन प्रस्थापित होताना एंडपॉइंट रूट पाठवले जातात, त्यामुळे बदललेला रूट संच जोडलेला राहणाऱ्या क्लायंटपर्यंत कधीही पोहोचत नाही. समर्थित क्लायंटद्वारे डिस्कनेक्ट करा आणि पुन्हा कनेक्ट करा, नंतर नवीन रूट मशीनवर आहेत याची खात्री करा.
शेवटी, कनेक्शन लॉगची क्लायंटला मिळालेल्या पत्त्याशी जुळणी करा, आणि एकापेक्षा जास्त असोसिएशनपर्यंत पोहोचण्यासाठी पुरेशा वेळा चाचणीची पुनरावृत्ती करा. दुरुस्तीनंतरची एक यशस्वी विनंती एक मार्ग चालतो हे सिद्ध करते, आणि तिकीट दुसऱ्याबद्दल होते.