Linux VPN ची उत्तरे गायब होत आहेत? rp_filter आणि मार्ग तपासा

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

स्रोत पडताळणी काय ठरवते

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

महत्त्वाचा शब्द विश्वासार्ह आहे। पॅकेट पूर्णपणे वैध असूनही तपासणीत नापास होऊ शकते, कारण वैधता तपासली जात नाही।

प्रत्यक्ष मोड वाचा, एक फील्ड नाही

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

तिसऱ्या ओळीतील मार्ग शोध हा लोक वगळत असलेला भाग आहे। तो कर्नेल स्रोताबद्दल काय विचार करते ते सांगतो, आणि तेच तपासणीचे इनपुट आहे।

तपासणी बदलण्यापूर्वी विसंगती शोधा

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

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

पहिल्या प्रतिक्रियेस म्हणून स्रोत तपासण्या जागतिक पातळीवर बंद करू नका। ते ठोस निदानाच्या बदल्यात व्यापक वर्तन बदल देते जो आपल्याला नंतर लक्षात ठेवावा लागेल।

आपण समर्थन देऊ शकता असे निवडक समायोजन

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

अजूनही नाकारला पाहिजे अशी परिस्थिती समाविष्ट करा। जर ती परिस्थिती आता यशस्वी होत असेल, तर समायोजनाने आपण दुरुस्त करू इच्छित असलेल्या एका मार्गापेक्षा जास्त कमकुवत केले आहे।

IPv4 आणि IPv6 वेगळे ठेवा

ओळखीचे वाटणारे sysctl प्रत्येक पत्ता-कुटुंबासाठी धोरण नाही। IPv6 चे स्वतःचे वर्तन आणि स्वतःच्या सेटिंग्ज आहेत, आणि मशीन एका कुटुंबात कठोर व दुसऱ्यात सौम्य असू शकते, विशिष्ट गंतव्य अयशस्वी होईपर्यंत कोणाच्याही लक्षात न येता। कामाचा भार दोन्ही वापरत असेल तर दोन्ही तपासा।

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