AWS को NAT गेटवेले VPN तर्फ कुन स्रोत IP प्रयोग गर्छ?

तपाईं VPC कन्सोल खोल्नुहुन्छ किनकि साझेदारले साइट-देखि-साइट VPN मार्फत कुन स्रोत दायरा आउने भनी सोधे। NAT गेटवे पृष्ठले Elastic IP जोडिएको सार्वजनिक गेटवे देखाउँछ, र त्यो ठेगाना पठाएर अगाडि बढ्ने प्रलोभन हुन्छ। इन्टरनेट मार्गका लागि यो सही उत्तर हो र VPN मार्गका लागि गलत उत्तर, र भिन्नता यो हो कि रुट तालिकाले कुन गेटवेतर्फ देखाउँछ। अनुमति सूची लेख्नुअघि मार्ग हिँडेर हेर्नुहोस्।

अनुमति सूचीबाट होइन, NAT गेटवे पृष्ठबाट सुरु गर्नुहोस्

NAT गेटवे पृष्ठले तपाईंलाई सबनेट, प्रकार र Elastic IP बताउँछ, र यी तीन क्षेत्र सुरु गर्न पर्याप्त छन्। जुन बताउँदैन त्यो ट्राफिकले पछि लिने मार्ग हो। त्यो NAT गेटवेको सबनेटसँग जोडिएका रुट तालिकाबाट आउँछ।

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

दुवै रूपान्तरण पछ्याउनुहोस्

सार्वजनिक र निजी दुवै NAT गेटवेले कार्यभारको निजी IPv4 स्रोतलाई NAT गेटवेको आफ्नै निजी IPv4 ठेगानामा रूपान्तरण गर्छन्। यो पहिलो रूपान्तरण प्रकारलाई वास्ता नगरी हुन्छ। दोस्रो रूपान्तरण मानिसहरूले बिर्सने हो: सार्वजनिक NAT गेटवेले ट्राफिक इन्टरनेट गेटवेलाई सुम्पन्छ, जसले ठेगानालाई जोडिएको Elastic IP मा म्याप गर्छ।

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

निजी मार्गमा शृंखलामा कुनै इन्टरनेट गेटवे हुँदैन। ट्राफिक ट्रान्जिट गेटवे वा भर्चुअल निजी गेटवेबाट बाहिर जाँदा, NAT गेटवे मार्गदर्शिका NAT गेटवेको निजी ठेगानालाई टाढाको पक्षले प्राप्त गर्ने स्रोतका रूपमा अभिलेख गर्छ। साझेदारले अनुमति दिनुपर्ने ठेगाना त्यही हो, Elastic IP होइन।

VPN मार्गले सामान्यतया निजी ठेगाना देखाउँछ

10.20.1.0/24 मा रहेको कार्यभार साझेदारको प्रिफिक्ससम्म पुग्दा कार्यभार सबनेटको रुट तालिका NAT गेटवेतर्फ र NAT गेटवेको सबनेटको रुट तालिका निजी गेटवे मार्गतर्फ देखाउँछ। दुवै हप महत्त्वपूर्ण छन्, र साझेदारले के देख्छ भन्ने केवल दोस्रोले निर्धारण गर्छ। यदि NAT सबनेटसँग VPN मार्गतर्फ कुनै रुट छैन, प्याकेट कहिल्यै पुग्दैन, र यो गलत स्रोत ठेगानाभन्दा फरक असफलता हो।

ठेगानाबारे कुरा गर्नुअघि नै त्यो दोस्रो मार्ग प्रमाणित गर्नुहोस्। हराएको रुट र गलत रूपमा जानकारी दिइएको स्रोत ट्राफिक नदेख्ने साझेदारलाई ठ्याक्कै उस्तै देखिन्छ।

जब दोस्रो रूपान्तरणले उत्तर बदल्छ

AWS ले ट्रान्जिट गेटवे संलग्नतामा स्पष्ट, मिल्ने एक-देखि-एक NAT म्यापिङ पनि प्रदान गर्छ। त्यो म्यापिङले टाढाको सेवाले देख्नुअघि स्रोतलाई फेरि रूपान्तरण गर्न सक्छ, र यो केवल रुट गर्ने पूर्वनिर्धारित व्यवहार होइन। यसलाई जानाजानी कन्फिगर गर्नुपर्ने हुनाले, दुर्घटनावश पाइने कुराका रूपमा होइन, डिजाइन अपवादका रूपमा लिनुहोस्। यदि तपाईंको टोलीमा कसैले पनि यो खोलेको सम्झँदैन भने, संलग्नता पढेसम्म यो छैन भनी मान्नुहोस्।

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

निजी NAT गेटवेलाई इन्टरनेट गेटवेतर्फ देखाएर इन्टरनेट सेवा दिन सकिँदैन; AWS ले यस्तो ट्राफिक फालिने अभिलेख गर्छ। प्रकार पूरा मार्गबाट छान्नुहोस्, आवश्यकतामा भएको VPN शब्दबाट होइन।

तपाईंको साझेदारले काम गर्न सक्ने सम्झौता लेख्नुहोस्

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

रूपान्तरणले ठेगाना ओभरल्यापबाट राहत र अनुमान गर्न सकिने स्रोत नीति किन्छ, र साझेदारको लगमा व्यक्तिगत कार्यभार पहिचान तपाईंलाई गुमाउँछ। यदि अडिटलाई प्रत्येक कार्यभारको श्रेय चाहिन्छ भने, त्यो पहिचान रूपान्तरित स्रोत ठेगानाबाट पुनःप्राप्त गर्न खोज्नुको सट्टा अनुप्रयोग तहमा राख्नुहोस्।

त्यसपछि कुनै पनि परिवर्तनपछि दुवै रुट तालिका फेरि जाँच्नुहोस्, किनकि नयाँ संलग्नता वा पुनः जोडिएको सबनेटले उत्तर चुपचाप फेरि लेख्छ।