स्रोत/गंतव्य जाँच एक द्वार है, पूरा VPN मार्ग नहीं

VPN एक EC2 इंस्टेंस पर समाप्त होता है, आप उस इंस्टेंस के टनल पते तक पहुँच सकते हैं, और वह ट्रैफ़िक गायब हो जाता है जिसे उसके ज़रिए किसी दूसरे निजी होस्ट की ओर जाना था। ये दो अलग परीक्षण हैं, और इन्हें मिलाने से घंटे बर्बाद होते हैं। पहला पूछता है कि क्या आप इंस्टेंस तक पहुँच सकते हैं; दूसरा चाहता है कि वह ऐसे गंतव्य के लिए ट्रैफ़िक फ़ॉरवर्ड करे जो उसका अपना नहीं है, जिसके लिए Linux फ़ॉरवर्डिंग, फ़ायरवॉल नीति, दूसरी ओर एक रूट और AWS स्तर की अनुमति चाहिए, जिसका अतिथि ऑपरेटिंग सिस्टम से कोई संबंध नहीं है। कंसोल में कुछ भी उस अंतर की ओर ध्यान नहीं खींचता। लक्षण रूटिंग खराबी जैसा दिखता है, और आमतौर पर वह होता नहीं।

कुछ भी बदलने से पहले दोनों परीक्षण अलग करें

गेटवे तक पहुँचना टनल, उसके पते तक का रूट और वह सुरक्षा समूह सिद्ध करता है जो आदान-प्रदान की अनुमति देता है। किसी दूसरे होस्ट के लिए फ़ॉरवर्डिंग इनमें से कुछ भी सिद्ध नहीं करती: यह अलग स्रोत पता, अलग गंतव्य और ऐसी भूमिका में इंस्टेंस इस्तेमाल करती है जिसके लिए वह ज़रूरी तौर पर बना नहीं था। दोनों परीक्षण अलग-अलग लिखें और नोट करें कि कौन विफल होता है, क्योंकि हर एक का सुधार अलग कंसोल में है। केवल टनल समाप्त करने के लिए बना गेटवे इंस्टेंस किसी और चीज़ के लिए फ़ॉरवर्ड करने का कोई कारण नहीं रखता, और उसकी डिफ़ॉल्ट सेटिंग्स यही दिखाती हैं। इसलिए दूसरे परीक्षण को अपना सेटअप चाहिए, पहले में छोटा बदलाव नहीं।

गेटवे की ओर काम करने वाला ping और उसके पार के होस्ट की ओर विफल होने वाला ping कोई रुक-रुककर आने वाली समस्या नहीं है। यह ऐसे इंस्टेंस का अपेक्षित व्यवहार है जिसे बताया नहीं गया है कि वह फ़ॉरवर्ड कर सकता है।

किसी सेटिंग को छूने से पहले मार्ग लिख लें

क्लाइंट प्रीफ़िक्स, फ़ॉरवर्डिंग इंस्टेंस या नेटवर्क इंटरफ़ेस, लक्ष्य सबनेट और उत्तर का रूट दर्ज करें। किसी इंस्टेंस की ओर इशारा करने वाली VPC रूट तालिका की प्रविष्टि इंस्टेंस के ऑपरेटिंग सिस्टम को फ़ॉरवर्ड करने के लिए कॉन्फ़िगर नहीं करती, और फ़ॉरवर्डिंग चालू वाला अतिथि कर्नेल VPC रूट नहीं बनाता। उस संबंध के दोनों सिरे मौजूद होने चाहिए, और उन्हें अलग जगहों पर अलग पहुँच वाले लोग संपादित करते हैं।

फिर स्रोत/गंतव्य जाँच की सेटिंग वास्तविक फ़ॉरवर्डिंग घटक पर देखें, VPC के हर इंस्टेंस पर नहीं। AWS दस्तावेज़ करता है कि दूसरों के लिए ट्रैफ़िक फ़ॉरवर्ड करने वाले इंस्टेंस को वह जाँच बंद रखनी क्यों चाहिए, और यह भी कि सेटिंग पूरे VPC का डिफ़ॉल्ट नहीं बल्कि प्रति-इंस्टेंस निर्णय क्यों है।

चार सीमाएँ, और जाँच उनमें से केवल एक है

मार्ग को चार प्रश्न मानें और क्रम से उनके उत्तर दें। पहला विफल उत्तर वह जगह है जहाँ काम है, और बाकियों में से कोई भी उसकी भरपाई नहीं करेगा।

क्रम मायने रखता है क्योंकि जाँच सस्ती है: रूट एक पृष्ठ पर दिखते हैं, जाँच एक ही विशेषता है, और गंतव्य की राय आमतौर पर वह आख़िरी चीज़ होती है जो कोई पूछता है।

अनुवाद बदलता है कि गंतव्य कौन-सा स्रोत देखता है

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

अगर आप अनुवाद करते हैं, तो नियम को क्लाइंट प्रीफ़िक्स और इरादे वाले गंतव्य तक सीमित रखें। अगर सुरक्षित रखते हैं, तो पुष्टि करें कि दूसरी ओर मार्ग वास्तव में जानती है, यह मानने के बजाय कि वह एक सीख लेगी।

मूल क्लाइंट से परीक्षण करें, फिर बदलाव रखें

गेटवे पर बना अनुरोध सफल हो सकता है जबकि फ़ॉरवर्ड किया गया अनुरोध विफल होता है, क्योंकि यह अलग स्रोत और अलग फ़ॉरवर्डिंग स्थिति है। लक्षित सुधार के बाद वही क्लाइंट-से-संसाधन परीक्षण दोहराएँ जो विफल हुआ था, उसी क्लाइंट से, और पुष्टि करें कि उत्तर वापस आता है, केवल यह नहीं कि अनुरोध पहुँच गया।

अंत में, सेटिंग को गेटवे के प्रबंधित कॉन्फ़िगरेशन में रखें ताकि प्रतिस्थापन इंस्टेंस को वह मिले। मैन्युअल अपवाद पर निर्भर सफल परीक्षण ऐसा परीक्षण है जो अगले पुनर्निर्माण में समाप्त हो जाता है, और जिसने उसे खोजा वह यह याद रखने के लिए वहाँ नहीं होगा कि क्यों।