अनेक 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 ला इतर मशीनचा रहदारी पुढे पाठवायचा असल्यास ती राउटर भूमिका स्पष्टपणे नियोजित करा, फॉरवर्डिंगला परवानगी देणारे क्लाउड सेटिंग आणि त्यासोबत जाणारे गेस्ट फिल्टर यांसह।