कई 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 को दूसरी मशीनों का ट्रैफ़िक फ़ॉरवर्ड करना है, तो उस राउटर भूमिका की स्पष्ट योजना बनाएँ, जिसमें फ़ॉरवर्डिंग की अनुमति देने वाली क्लाउड सेटिंग और उसके साथ जाने वाले गेस्ट फ़िल्टर शामिल हैं।