AWS Client VPN स्प्लिट टनेल: कोणते मार्ग प्रकाशित करावे

कन्सोल स्प्लिट टनेलसाठी टॉगल देते, त्यामुळे निर्णय चेकबॉक्ससारखा वाटतो. तसा नाही. क्लायंटपर्यंत प्रत्यक्षात एंडपॉइंटचा प्रकाशित मार्गसंच पोहोचतो, आणि तीच यादी ठरवते की कोणते खाजगी प्रीफिक्स टनेल वापरतात, सामान्य इंटरनेट रहदारी स्थानिक राहते की AWS मधून बाहेर पडते, आणि क्लायंट अजून कोणत्या रिझॉल्व्हरशी बोलू शकतो. तीन प्रश्न रचना ठरवतात, आणि प्रत्येकाला वाईट उत्तर देता येते तरीही कनेक्शन यशस्वी होते.

स्प्लिट टनेल ध्वज ही गंतव्यांची यादी नाही

AWS स्प्लिट टनेलिंगचे वर्णन कनेक्शन स्थापित होताना एंडपॉइंट मार्ग क्लायंटच्या मार्ग तक्त्यात जोडणे असे करते. खाजगी VPC साठीचा मार्ग टनेल त्या गंतव्यापुरता मर्यादित करतो; बाकी सर्व क्लायंटच्या नेहमीच्या मार्गाने जाते. डीफॉल्ट मार्ग वेगळ्या परिणामाची वेगळी सूचना आहे, म्हणूनच स्प्लिट टनेल दस्तऐवज या मोडसाठी संरचित केलेल्या एंडपॉइंटवर 0.0.0.0/0 प्रकाशित करण्याविरुद्ध इशारा देतो: ते कनेक्टिव्हिटी वाढवण्याऐवजी सहसा तोडते. एंडपॉइंट मार्ग तक्ता हे धोरण आहे, आणि क्लायंट मार्ग तक्ता हा तुम्ही तपासू शकता असा निकाल.

एंडपॉइंट मार्ग तक्ता आणि क्लायंटवर स्थापित मार्ग एकत्र वाचा. लेबल हेतू सांगते; मार्ग काय घडते ते सांगतात.

पहिला निर्णय: सामान्य इंटरनेट रहदारी स्थानिक राहावी का?

ब्राउझिंगने वापरकर्त्याचे स्वतःचे कनेक्शन वापरायचे असेल, तर कामाला आवश्यक असलेली खाजगी गंतव्येच प्रकाशित करा आणि तिथेच थांबा. पूर्ण टनेलच्या ट्युटोरियलमध्ये एक होते म्हणून इंटरनेट मार्ग जोडू नका, आणि अतिरिक्त मार्ग सुरक्षा सुधारतो असे गृहीत धरू नका. तो मार्ग बदलतो, धोरण जोडत नाही, आणि सहसा तुम्ही बजेट न केलेला विलंब घेतो.

इंटरनेट रहदारी AWS मधून बाहेर पडायची असेल, तर दस्तऐवजीकृत इंटरनेट प्रवेश रचना तयार करा: एंडपॉइंट मार्ग, अधिकृतता नियम, संबंधित सबनेटचा मार्ग, सुरक्षा धोरण आणि कार्यरत अपस्ट्रीम एग्रेस. केवळ डीफॉल्ट मार्ग यातले काहीही देत नाही.

दुसरा निर्णय: कोणते खाजगी प्रीफिक्स आणि कोणाच्या अधिकाराने?

खऱ्या कामाच्या भाराला सेवा देणारा सर्वात लहान गंतव्यसंच प्रकाशित करा, आणि प्रत्येक संबंधित सबनेट तिथे मार्ग करू शकतो का ते तपासा. एंडपॉइंटचे मार्ग लक्ष्य आणि सबनेटचे VPC मार्गनिर्देशन वेगवेगळे स्तर आहेत, आणि एकात असलेला मार्ग दुसऱ्याबद्दल पुरावा नाही. अधिकृतता पुन्हा वेगळी: गंतव्य पोहोचण्यायोग्य असूनही नाकारले जाऊ शकते, कारण क्लायंटच्या गटाकडे ते अनुमती देणारा नियम नाही.

एक यशस्वी सत्र तपासणे एकच मार्ग सिद्ध करते. प्रत्येक संबंधित सबनेट तपासा, कारण नंतर जोडलेले सबनेट संबंध हेच गहाळ मार्ग सहसा असतो ते ठिकाण.

गंतव्य नावाने पोहोचण्यायोग्य असावे लागल्यास, पुढील प्रश्न मार्गाचा नाही तर नाव निराकरणाचा आहे हे लक्षात घ्या.

तिसरा निर्णय: कोणता रिझॉल्व्हर टनेलच्या मागे जातो?

क्लायंटला फक्त VPN मधून पोहोचण्यायोग्य DNS सर्व्हर मिळू शकतो, आणि तो रिझॉल्व्हर त्याचा पत्ता स्वतः अधिकृत मार्गात असेल तरच काम करतो. दोन्ही अर्धे तपासा: रिझॉल्व्हरचा पत्ता प्रकाशित मार्गाच्या मागे जातो, आणि सर्व्हर अनुप्रयोग विचारतो त्या नावांना उत्तर देतो. पत्त्याने यशस्वी पण होस्टनावाने अयशस्वी होणारी विनंती नावांकनाकडे निर्देश करते, मार्गनिर्देशनाकडे नाही, आणि त्या स्थितीत टनेल डीबग करणे दुपार वाया घालवते.

सार्वजनिक नावे कनेक्शनपूर्वीप्रमाणेच सोडवली जावीत, जे तुम्ही काय प्रकाशित करता याबद्दल अचूक राहण्याचे आणखी एक कारण आहे.

मार्गसंच बदला, नंतर दोन्ही जगे तपासा

स्प्लिट टनेल एंडपॉइंटवर मार्ग बदलल्यास क्लायंट कनेक्शन रीसेट होतात असे AWS दस्तऐवजीकरण करते. हे लक्षात घेऊन बदलाची योजना करा: तो लागू करा, समर्थित क्लायंटद्वारे पुन्हा कनेक्ट व्हा, आणि संपादनापूर्वी लागू केलेल्या स्थितीवर विश्वास ठेवण्याऐवजी स्थापित मार्ग पुन्हा वाचा. जुनी लागू स्थिती हेच योग्य बदल तुटलेला दिसण्याचे सर्वात सामान्य कारण आहे.

एक खाजगी संसाधन आणि एक सार्वजनिक गंतव्य दोन्ही हेतूप्रमाणे वागल्यासच रचना स्वीकारा, नावाने आणि पत्त्याने, तुम्ही खरोखर समर्थन देता त्या पत्ता कुटुंबांमध्ये. प्रमाणीकरण करणारे टनेल योग्य विभाजन करणाऱ्या टनेलसारखे नसते.

मार्ग यादी तर्काच्या शेजारी रनबुकमध्ये लिहा, जेणेकरून पुढची व्यक्ती जाणीवपूर्वक वगळणे आणि विसरलेले वगळणे यात फरक करू शकेल.