VPN गेटवेला IP फॉरवर्डिंग आवश्यक आहे: काय तपासावे

तुमचा क्लायंट गेटवेच्या पत्त्यावर पिंग करू शकतो, पण त्यामागील प्रत्येक संसाधन अगम्य राहते। ही दोन निरीक्षणे तुमच्याशी बोलणारे होस्ट आणि राउटिंग न करणारे राउटर यांचे वर्णन करतात, जी एकाच मशीनवरील वेगवेगळी भूमिका आहेत। फॉरवर्डिंग हा त्यांच्यातील स्विच आहे।

दोन्ही भूमिका स्वतंत्र आहेत, आणि दोन्ही पत्ता कुटुंबेही।

स्वतःच्या पत्त्यावर उत्तर देणे काहीही सिद्ध करत नाही

जेव्हा पॅकेट गेटवेलाच संबोधले जाते, तेव्हा स्थानिक स्टॅक ते वापरतो आणि कोणताही फॉरवर्डिंग निर्णय होत नाही। म्हणूनच टनेलच्या पत्त्यावर किंवा व्यवस्थापन इंटरफेसवर यशस्वी पिंग तुम्हाला सांगते की डेमॉन जिवंत आहे आणि टनेल वर आहे, पण बॉक्सच्या मागील नेटवर्कसाठीच्या रहदारीबद्दल काहीही सांगत नाही। कर्नल केवळ त्याला संबोधले न गेलेल्या पॅकेटसाठी आपला फॉरवर्डिंग मार्ग पाहतो।

आवश्यकता सेटिंग नव्हे तर भूमिका म्हणून वाचा: या होस्टने दोन इंटरफेसदरम्यान पॅकेट हलवायचे आहेत। फक्त दूरच्या नेटवर्कपर्यंत पोहोचायचे असलेला लॅपटॉप ही भूमिका कधीच घेत नाही, आणि साइट-टू-साइट एंडपॉइंट ती नेहमी घेतो। आवश्यकता अशा प्रकारे वाचल्यास कार्यरत क्लायंट कॉन्फिगरेशन गेटवेवर हलवल्यावर का अयशस्वी होते हे स्पष्ट होते।

तेच वाक्य फॉरवर्डिंग निर्णयासमोरील फायरवॉललाही लागू होते, ज्याचे काय फॉरवर्ड करता येईल याबद्दल स्वतःचे धोरण आहे।

प्रत्येक पत्ता कुटुंब स्वतंत्रपणे तपासा

IPv4 फॉरवर्डिंग एक स्विच आहे, आणि IPv6 फॉरवर्डिंग प्रत्येक इंटरफेससाठी स्वतःचे वर्तन असलेला दुसरा आहे। पहिला सुरू केल्याने दुसऱ्याबद्दल काहीही कळत नाही, आणि दुहेरी स्टॅक क्लायंट अर्ध्या नेटवर्कपर्यंत पोहोचू शकतो तर उर्वरित अंधारात राहते। म्हणून वेगवेगळ्या कुटुंबांतील दोन क्लायंट एकाच गेटवेबद्दल असहमत असू शकतात। कोणतीही सेटिंग संपादित करण्यापूर्वी अयशस्वी क्लायंटने कोणते कुटुंब वापरले ते विचारा। राउटिंग रचना चुकीची आहे असा निष्कर्ष काढण्यापूर्वी दोन्हीची पुष्टी करा।

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

अनेक वितरणांमध्ये रनटाइममध्ये तुम्ही वाचता ते मूल्य तिथे सेवा किंवा कॉन्फिगरेशन फाइलने ठेवलेले असते, म्हणून एकवेळच्या कमांडने केलेला बदल रीबूटवर नाहीसा होऊ शकतो। रनटाइम मूल्य संपादित करण्यापूर्वी ही सेटिंग ज्या फाइलची मालकीची आहे ती शोधा।

फॉरवर्डिंग चार आवश्यकतांपैकी एक आहे

कार्यरत फॉरवर्ड केलेल्या प्रवाहाला एकाच वेळी चार गोष्टी लागतात: क्लायंटला माहीत असले पाहिजे की गंतव्य टनेलच्या मागे आहे, गेटवेकडे पुढे जाणारा मार्ग असला पाहिजे, उत्तरांना परतीचा मार्ग असला पाहिजे, आणि फायरवॉलने रहदारीला परवानगी दिली पाहिजे। स्रोत भाषांतर त्या रचनेत नियम नव्हे तर पर्याय म्हणून येते, कारण सममित मार्ग असलेल्या खाजगी राउटेड नेटवर्कला त्याची गरज नसते आणि असममित नेटवर्कला सहसा असते। चारपैकी प्रत्येक स्वतंत्रपणे अयशस्वी होतो, म्हणून एक दुरुस्त केल्याने लक्षण क्वचितच हलते। कोणतेही बदलण्यापूर्वी चारही लिहून ठेवा।

क्लाउड प्लॅटफॉर्म पाचवा विचार जोडतात। काही इन्स्टन्सवर स्रोत आणि गंतव्य तपासण्या लागू करतात, ज्यामुळे गेस्ट कर्नल कसा कॉन्फिगर केलेला असला तरी फॉरवर्ड केलेले पॅकेट टाकून दिले जातात। तिथे अधिकार प्लॅटफॉर्मच्या स्वतःच्या नेटवर्किंग दस्तऐवजांना आहे, VM मधील sysctl आउटपुटला नाही।

गेटवेवरून नव्हे, क्लायंटवरून चाचणी करा

गेटवेच्या स्वतःच्या शेलमध्ये चालवलेली चाचणी तुम्ही नुकतेच सक्षम केलेल्या फॉरवर्डिंग मार्गाच्या कोणत्याही भागातून जात नाही। समस्या असलेल्या क्लायंटकडून रहदारी निर्माण करा, आणि ती गेटवेकडे नव्हे तर गेटवेच्या मागील कशाकडेतरी पोहोचते याची पुष्टी करा। तुम्ही बदललेल्या भूमिकेचा सराव करणारी ही एकमेव चाचणी आहे।

श्रोता नियम आणि फॉरवर्डिंग नियम तुमच्या मनात आणि बदल नोंदीत वेगळे ठेवा। VPN पोर्ट उघडल्याने क्लायंट सेवेत येतात; त्यामुळे त्यांना मागील नेटवर्कवर काहीही मिळत नाही, आणि वर्षानुवर्षे वाढलेल्या फायरवॉल यादीत दोन्ही सारखेच दिसतात।

पॅकेट आले आणि सेवेने वापरकर्त्याला नाकारले, तर तुम्ही नेटवर्किंगच्या पलीकडे गेला आहात। फॉरवर्डिंग धोरण पुन्हा रुंदावण्याऐवजी अनुप्रयोग अधिकृततेसह पुढे जा।