स्रोत/गन्तव्य जाँच एउटा ढोका हो, सम्पूर्ण VPN मार्ग होइन

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

केही परिवर्तन गर्नुअघि दुई परीक्षण छुट्याउनुहोस्

गेटवेसम्म पुग्नुले टनेल, त्यसको ठेगानासम्मको रुट र आदानप्रदान अनुमति दिने सुरक्षा समूह प्रमाणित गर्छ। अर्को होस्टका लागि फर्वार्डिङले यीमध्ये केही पनि प्रमाणित गर्दैन: यसले फरक स्रोत ठेगाना, फरक गन्तव्य र त्यसका लागि अनिवार्य रूपमा नबनाइएको भूमिकामा रहेको इन्स्ट्यान्स प्रयोग गर्छ। दुई परीक्षण छुट्टै लेख्नुहोस् र कुन असफल हुन्छ टिप्नुहोस्, किनकि प्रत्येकको सुधार फरक कन्सोलमा हुन्छ। केवल टनेल अन्त्य गर्न बनाइएको गेटवे इन्स्ट्यान्सलाई अरू केहीका लागि फर्वार्ड गर्ने कारण हुँदैन, र यसको पूर्वनिर्धारित मानहरूले त्यही देखाउँछन्। त्यसैले दोस्रो परीक्षणलाई आफ्नै सेटअप चाहिन्छ, पहिलोमा सानो परिवर्तन होइन।

गेटवेतर्फ काम गर्ने ping र त्यसपछाडिको होस्टतर्फ असफल हुने ping कुनै बेलाबेलामा आउने समस्या होइन। फर्वार्ड गर्न सक्ने भनी नभनिएको इन्स्ट्यान्सको अपेक्षित व्यवहार हो यो।

कुनै सेटिङ छुनुअघि मार्ग लेख्नुहोस्

ग्राहक प्रिफिक्स, फर्वार्डिङ इन्स्ट्यान्स वा नेटवर्क इन्टरफेस, लक्ष्य सबनेट र जवाफको रुट टिप्नुहोस्। इन्स्ट्यान्सतर्फ देखाउने VPC रुट तालिकाको प्रविष्टिले इन्स्ट्यान्सको अपरेटिङ सिस्टमलाई फर्वार्ड गर्न कन्फिगर गर्दैन, र फर्वार्डिङ खुला रहेको अतिथि कर्नेलले VPC रुट बनाउँदैन। त्यो सम्बन्धका दुवै छेउ हुनुपर्छ, र ती फरक ठाउँमा फरक पहुँच भएका मानिसहरूद्वारा सम्पादन गरिन्छन्।

त्यसपछि स्रोत/गन्तव्य जाँचको सेटिङ वास्तविक फर्वार्डिङ घटकमा हेर्नुहोस्, VPC का हरेक इन्स्ट्यान्समा होइन। अरूका लागि ट्राफिक फर्वार्ड गर्ने इन्स्ट्यान्सले त्यो जाँच बन्द राख्नुपर्ने किन हो, र सेटिङ सम्पूर्ण VPC को पूर्वनिर्धारित नभई प्रत्येक इन्स्ट्यान्सको निर्णय किन हो, AWS ले कागजात गर्छ।

चार सीमा, र जाँच तीमध्ये एउटा मात्र

मार्गलाई चार प्रश्न मान्नुहोस् र क्रममा उत्तर दिनुहोस्। पहिलो असफल उत्तर काम रहेको ठाउँ हो, र अरू कुनैले त्यसको क्षतिपूर्ति गर्दैन।

क्रम महत्त्वपूर्ण छ किनकि जाँच सस्तो छ: रुटहरू एउटै पृष्ठमा देखिन्छन्, जाँच एउटै विशेषता हो, र गन्तव्यको राय सामान्यतया कसैले सबैभन्दा पछि सोध्ने कुरा हो।

अनुवादले गन्तव्यले कुन स्रोत देख्छ भन्ने बदल्छ

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

यदि तपाईं अनुवाद गर्नुहुन्छ भने नियम ग्राहक प्रिफिक्स र अभीष्ट गन्तव्यमा सीमित गर्नुहोस्। यदि जोगाउनुहुन्छ भने परपारको छेउले रुट साँच्चै जान्छ भनी पुष्टि गर्नुहोस्, सिक्छ भनी मान्नुको सट्टा।

मूल ग्राहकबाट परीक्षण गर्नुहोस्, त्यसपछि परिवर्तन राख्नुहोस्

गेटवेमा बनाइएको अनुरोध सफल हुन सक्छ जबकि फर्वार्ड गरिएको अनुरोध असफल हुन्छ, किनकि यो फरक स्रोत र फरक फर्वार्डिङ अवस्था हो। लक्षित सुधारपछि असफल भएको ठ्याक्कै त्यही ग्राहक-देखि-स्रोत परीक्षण उही ग्राहकबाट दोहोर्याउनुहोस्, र अनुरोध पुगेको मात्र नभई जवाफ फर्केको पुष्टि गर्नुहोस्।

अन्तमा, सेटिङ गेटवेको व्यवस्थापित कन्फिगरेसनमा राख्नुहोस् ताकि प्रतिस्थापन इन्स्ट्यान्सले त्यो पाओस्। म्यानुअल अपवादमा निर्भर सफल परीक्षण अर्को पुनर्निर्माणमा सकिने परीक्षण हो, र जसले यो फेला पार्यो उसले किन भनेर सम्झन त्यहाँ हुनेछैन।