धेरै NIC भएको GCP VM: जवाफहरू किन गलत इन्टरफेसबाट बाहिरिन्छन्

Compute Engine VM मा दोस्रो इन्टरफेस जोड्दा त्यसलाई अर्को नेटवर्क जडान दिन्छ, सममित फिर्ती मार्ग होइन। गेस्टले अझै पनि आफ्नै मार्ग र नियमहरूबाट इन्टरफेस र स्रोत ठेगाना छान्छ। त्यसपछि Google Cloud प्याकेट बाहिरिएको इन्टरफेसको वरिपरि VPC राउटिङ र फायरवाल नीति लागू गर्छ। जब यी दुई निर्णय मिल्दैनन्, अनुरोधहरू एउटा NIC मा आउँछन् र जवाफहरू अर्कोबाट बाहिरिन्छन्, र शाखाले आधा खुला कुराकानी देख्छ।

पाँच चरणमा मार्ग हिँड्नुहोस् र नीति नियम लेख्नु अघि नै असमझदारी देखिनेछ।

चरण 1: क्लाउड NIC हरूलाई गेस्ट यन्त्रहरूसँग जोड्नुहोस्

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

ठेगाना, यन्त्र नाम र प्रत्येक कुन VPC मा पर्छ लेख्नुहोस्। त्यो तीन-स्तम्भ नक्सा प्रत्येक अर्को चरणको इनपुट हो।

चरण 2: दुई राउटिङ निर्णयहरूलाई नाम दिनुहोस्

पहिलो निर्णय गेस्टको हो: यो प्याकेटका लागि कुन इन्टरफेस र कुन स्रोत ठेगाना। दोस्रो क्लाउडको हो: VPC का मार्गहरू र फायरवाल नीतिले त्यो इन्टरफेसको वरिपरि के अनुमति दिन्छन्।

VPN तर्फको VPC मा देखिने मार्ग त्यो NIC छान्ने गेस्ट मार्ग बन्दैन। क्लाउड मार्गले नेटवर्कले के डेलिभर गर्न सक्छ वर्णन गर्छ, जबकि गेस्ट मार्गले प्याकेट के गर्छ निर्धारण गर्छ।

चरण 3: फिर्ती मार्गको नीति छान्नुहोस्

शाखा प्रिफिक्सको सानो, स्थिर समूहका लागि गेस्टमा स्पष्ट गन्तव्य मार्गहरू सबैभन्दा सरल अभिव्यक्ति हुन्: ती प्रिफिक्सका जवाफहरू VPN तर्फको इन्टरफेसबाट बाहिरिन्छन्। जब धेरै सेवाहरूले जानाजान फरक स्थानीय स्रोत ठेगाना प्रयोग गर्छन्, प्रति इन्टरफेस तालिका छान्ने स्रोत-आधारित नियमहरूले प्रत्येक जवाफ सही सन्दर्भमा राख्छन्। धेरै इन्टरफेसको कागजात यी डिजाइनहरू अवलम्बित NIC नामकरण र पूर्वनिर्धारित-मार्ग व्यवहार वर्णन गर्छ।

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

चरण 4: गेस्टका आफ्नै फिल्टरहरू जाँच्नुहोस्

सर्भर कहाँ सुन्छ र जवाफ कुन स्थानीय स्रोत बोक्छ जाँच्नुहोस्। सबै ठेगानामा सुन्ने श्रोताले राउटिङ नीति रद्द गर्दैन, त्यसैले सबै ठेगानामा बाँध्दा जवाफ बाहिरिने इन्टरफेसबारे केही बदलिँदैन।

Linux मा, इच्छित डिजाइनको तुलनामा उल्टो-मार्ग मान्यता समीक्षा गर्नुहोस्। पहिलो कदमका रूपमा यसलाई विश्वव्यापी बन्द गर्नु राउटिङ बगलाई स्पूफिङ जोखिमसँग साट्छ, र तपाईं खोजिरहनुभएको असममिति लुकाउँछ।

चरण 5: प्रत्येक मार्गका लागि एउटा प्रवाह परीक्षण गर्नुहोस्

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

दुई परीक्षण आफ्ना टिप्पणीमा छुट्टै राख्नुहोस्, किनकि तिनीहरू फरक मार्ग र फरक फायरवाल नियम प्रयोग गर्छन्।

दोस्रो NIC ले तपाईंलाई के दिँदैन

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

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