VPN क्लायंटमागील सर्व्हर टनेलमधून का उत्तर देतो

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

उत्तर राउट होते, आठवले जात नाही

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

पुढील दिशा गंतव्यानुसार राउट होते, आणि मागील दिशाही. उत्तर सार्वजनिक क्लायंटला उद्देशून असते, जे टनेल आनंदाने वाहून नेईल. दूरचे टोक आपल्याकडे नसलेल्या स्रोताचे पॅकेट घेते, ते टाकून देते, आणि मूळ क्लायंट वेळ संपेपर्यंत थांबतो.

कडक रिव्हर्स-पाथ फिल्टरिंग डेमन वाचण्यापूर्वीच येणारे पॅकेट टाकून देऊ शकते. आधी तो काउंटर पाहा, कारण फिल्टरची टाकणी आणि राउटिंगची चूक बाहेरून सारखीच दिसतात.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

परतीचा मार्ग टिकवण्याचे तीन मार्ग

सेवेचे गंतव्य टनेलमधून वगळणे हा सर्वात अरुंद पर्याय आहे. LAN गेटवेकडे निर्देशित होस्ट मार्ग, शिवाय प्रत्येक पत्त्याऐवजी भौतिक पत्त्याला बांधलेला डेमन, तो एकच प्रवाह टनेलबाहेर ठेवतो. बदल स्थानिक आहे आणि उलटणे सोपे आहे.

पॉलिसी राउटिंग हे सामान्य उत्तर आहे. स्रोत पत्ता किंवा फायरवॉल चिन्हावर की केलेला नियम अशी सारणी निवडतो जिचा डीफॉल्ट WAN गेटवेकडे दाखवतो, तर होस्टची स्वतःची कनेक्शन टनेल वापरत राहतात. प्राधान्य स्पष्ट ठेवा जेणेकरून नियम नंतर सावलीत येणार नाही.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

पहिले दोन कमांड सार्वजनिक पत्त्यावरून येणाऱ्या उत्तरांसाठी पर्यायी मार्ग बांधतात. तिसरा कर्नलला विचारतो की नेमका तो स्रोत आणि गंतव्य कोणता मार्ग घेईल, आणि अशा प्रकारे नियमाचा काही परिणाम आहे याची खात्री करता.

स्रोत भाषांतर हा तिसरा पर्याय आहे आणि सेवेच्या पुढे आधीच NAT करणाऱ्या राउटरसमोर टिकणारा एकमेव पर्याय. उत्तराला त्या राउटरकडे परत जावे लागते, आणि WAN इंटरफेसवर मास्करेडिंग ते साध्य करते आणि क्लायंट सेवा लॉगपासून लपवते. कनेक्ट झाल्यानंतर डीफॉल्ट मार्ग हाताने बदलणे हे निदान आहे, कारण पुढील पुन्हा कनेक्ट होताना क्लायंट सारणी पुन्हा लिहितो.

बॉक्स LAN साठीही राउट करतो तेव्हा

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

मग कनेक्शन ट्रॅकिंगला कधीही न नोंदवलेल्या प्रवाहाचे उत्तर दिसते आणि ती ते टाकून देते. गंतव्य भाषांतर येणारे कनेक्शन उपकरणापर्यंत पोहोचवते, आणि स्रोत भाषांतर उत्तर राउटरकडूनच आले असे दाखवते.

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

कारणे वेगळी करणाऱ्या तीन तपासण्या

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

आधी राउटिंगचा प्रश्न सोडवा, नंतर नावे पाहा. दोन्ही मिसळणे म्हणजे काम करणाऱ्या सर्व्हरला तुटलेल्या रिझॉल्व्हरसाठी दोष देणे.

अपवाद कोणत्या इंटरफेसचे नाव घेतो ते नोंदवा आणि संरचना आवृत्ती नियंत्रणात ठेवा. अपग्रेडनंतर नाव बदलणाऱ्या इंटरफेसविरुद्ध लिहिलेला नियम आज उत्तीर्ण होतो आणि पुढील रीबूटनंतर अयशस्वी होतो.