स्रोत/गंतव्य तपासणी एक दरवाजा आहे, संपूर्ण VPN मार्ग नाही

VPN एका EC2 इन्स्टन्सवर संपते, तुम्ही त्या इन्स्टन्सच्या टनेल पत्त्यापर्यंत पोहोचू शकता, आणि दुसऱ्या खाजगी होस्टकडे त्यातून जायचे असलेले रहदारी गायब होते। ह्या दोन वेगळ्या चाचण्या आहेत आणि त्या एकत्र करणे तास वाया घालवते। पहिली विचारते की तुम्ही इन्स्टन्सपर्यंत पोहोचू शकता का; दुसरी मागते की तिने अशा गंतव्यासाठी रहदारी पुढे पाठवावी जे तिचे स्वतःचे नाही, ज्यासाठी Linux फॉरवर्डिंग, फायरवॉल धोरण, पलीकडे मार्ग आणि पाहुण्या ऑपरेटिंग सिस्टमशी काहीही संबंध नसलेली AWS पातळीवरील परवानगी लागते। कन्सोलमध्ये काहीही त्या फरकाकडे लक्ष वेधत नाही। लक्षण मार्गदर्शन बिघाडासारखे दिसते आणि सहसा तसे नसते।

काहीही बदलण्यापूर्वी दोन्ही चाचण्या वेगळ्या करा

गेटवेपर्यंत पोहोचणे टनेल, त्याच्या पत्त्यापर्यंतचा मार्ग आणि देवाणघेवाणीस परवानगी देणारा सुरक्षा गट सिद्ध करते। दुसऱ्या होस्टसाठी फॉरवर्डिंग यातील काहीही सिद्ध करत नाही: ते वेगळा स्रोत पत्ता, वेगळे गंतव्य आणि ज्यासाठी बांधले गेले नाही अशा भूमिकेत असलेले इन्स्टन्स वापरते। दोन्ही चाचण्या वेगळ्या लिहा आणि कोणती अयशस्वी होते ते नोंदवा, कारण प्रत्येकाची दुरुस्ती वेगळ्या कन्सोलमध्ये आहे। फक्त टनेल संपवण्यासाठी बांधलेल्या गेटवे इन्स्टन्सला दुसऱ्या कशासाठीही फॉरवर्ड करण्याचे कारण नाही आणि त्याची डीफॉल्ट मूल्ये तेच दाखवतात। म्हणून दुसऱ्या चाचणीला स्वतःची रचना लागते, पहिल्यातील छोटा बदल नाही।

गेटवेकडे काम करणारा ping आणि त्यापलीकडील होस्टकडे अयशस्वी होणारा ping ही अधूनमधून येणारी समस्या नाही। फॉरवर्ड करू शकते असे न सांगितलेल्या इन्स्टन्सचे हे अपेक्षित वर्तन आहे।

कोणत्याही सेटिंगला हात लावण्यापूर्वी मार्ग लिहून ठेवा

क्लायंट प्रीफिक्स, फॉरवर्डिंग इन्स्टन्स किंवा नेटवर्क इंटरफेस, लक्ष्य सबनेट आणि उत्तराचा मार्ग नोंदवा। इन्स्टन्सकडे निर्देश करणारी VPC मार्ग तक्त्यातील नोंद इन्स्टन्सच्या ऑपरेटिंग सिस्टमला फॉरवर्ड करण्यासाठी संरचित करत नाही आणि फॉरवर्डिंग सुरू असलेले पाहुणे कर्नेल VPC मार्ग तयार करत नाही। त्या नात्याची दोन्ही टोके असणे आवश्यक आहे आणि ती वेगवेगळ्या ठिकाणी वेगवेगळ्या प्रवेश असलेल्या लोकांकडून संपादित केली जातात।

नंतर स्रोत/गंतव्य तपासणीची सेटिंग खऱ्या फॉरवर्डिंग घटकावर तपासा, VPCमधील प्रत्येक इन्स्टन्सवर नाही। इतरांसाठी रहदारी फॉरवर्ड करणाऱ्या इन्स्टन्सला ही तपासणी बंद असणे का आवश्यक आहे आणि ही सेटिंग संपूर्ण VPCची डीफॉल्ट नसून प्रत्येक इन्स्टन्सचा निर्णय का आहे, हे AWS दस्तऐवजीकरण करते।

चार सीमा आणि तपासणी त्यातील फक्त एक आहे

मार्गाला चार प्रश्न माना आणि क्रमाने त्यांची उत्तरे द्या। पहिले अयशस्वी उत्तर म्हणजे काम कुठे आहे आणि बाकीच्यांपैकी कोणीही त्याची भरपाई करणार नाही।

क्रम महत्त्वाचा आहे कारण तपासणे स्वस्त आहे: मार्ग एका पानावर दिसतात, तपासणी एकच गुणविशेष आहे आणि गंतव्याचे मत सहसा सर्वात शेवटी विचारले जाणारे असते।

अनुवाद गंतव्य कोणता स्रोत पाहते ते बदलतो

मार्गित रचना क्लायंटचा स्रोत पत्ता टिकवते, म्हणून गंतव्याला क्लायंट प्रीफिक्सपर्यंत परतीचा मार्ग लागतो। अनुवादित रचना त्याऐवजी गेटवेचा पत्ता सादर करते, ज्यामुळे ती अट काढून टाकली जाते आणि गेटवेवरच्या स्थिती तक्त्याने बदलली जाते। असंबंधित उदाहरणाने ते वापरले आणि काम करताना दिसले म्हणून अनुवाद जोडण्याऐवजी तुमच्या इच्छित स्थापत्यानुसार निर्णय घ्या।

जर तुम्ही अनुवाद करत असाल, तर नियम क्लायंट प्रीफिक्स आणि इच्छित गंतव्यापर्यंत मर्यादित करा। जर टिकवत असाल, तर पलीकडच्या बाजूला मार्ग खरोखर माहीत आहे याची खात्री करा, तो शिकेल असे गृहीत धरू नका।

मूळ क्लायंटवरून चाचणी करा, नंतर बदल ठेवा

गेटवेवर तयार केलेली विनंती यशस्वी होऊ शकते पण फॉरवर्ड केलेली विनंती अयशस्वी होते, कारण तो वेगळा स्रोत आणि वेगळा फॉरवर्डिंग प्रसंग आहे। लक्ष्यित दुरुस्तीनंतर जी क्लायंट-ते-संसाधन चाचणी अयशस्वी झाली तीच त्याच क्लायंटवरून पुन्हा करा आणि विनंती पोहोचली एवढेच नाही तर उत्तर परत येते याची खात्री करा।

शेवटी, सेटिंग गेटवेच्या व्यवस्थापित संरचनेत ठेवा जेणेकरून बदली इन्स्टन्सला ती मिळेल। हाताने केलेल्या अपवादावर अवलंबून असलेली यशस्वी चाचणी ही पुढील पुनर्बांधणीत संपणारी चाचणी आहे आणि ज्याने ती शोधली तो का ते आठवण्यासाठी तिथे नसेल।