टनेल सुरू आहे, इंटरनेट नाही: फॉरवर्डिंग कुठे थांबते

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

इंटरनेट निर्गम कधी डिझाइन होते का ते तपासा

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

क्लायंट जे स्थापित करतो ते नेहमी प्रोफाइलचा हेतू नसते। ढकललेला मार्ग कमी मेट्रिकच्या स्थानिक मार्गाने मागे टाकला जाऊ शकतो, आणि जो क्लायंट आपला LAN मार्ग ठेवून डीफॉल्ट मार्ग जोडतो तो त्या सबनेटसाठी स्प्लिट-टनेलसारखा वागतो।

एका सार्वजनिक विनंतीचा मागोवा घ्या

एक गंतव्य निवडा आणि ते क्लायंटपासून बाहेरच्या दिशेने ट्रेस करा। क्लायंटवर तपासा की पॅकेट खरोखर टनेल निवडते आणि कोणता स्थानिक पत्ता स्रोत म्हणून वापरते। मग गेटवे तपासा: पॅकेट येते का, आणि सार्वजनिक इंटरफेसातून बाहेर पडते का। यांपैकी प्रत्येक उत्तर कारणाचा संपूर्ण वर्ग काढून टाकते।

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

गेटवे पॅकेट कधीही पाहत नसेल, तर क्लायंट मार्ग किंवा टनेल निवड चुकीची आहे। पॅकेट येऊन बाहेर पडत नसेल, तर समस्या गेटवेवर आहे, आणि उर्वरित तीन तपासण्या लागू होतात।

फॉरवर्डिंग, मार्ग आणि भाषांतर तपासा

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

असममित रचनेत उलट-मार्ग गाळणीही वैध पॅकेट टाकू शकते। त्या नियमाचा काउंटर वाचा, सर्व ठीक आहे असे गृहीत धरण्याऐवजी, कारण सार्वजनिक इंटरफेसवरील कडक सेटिंग मार्ग सारणीच्या अंदाजापेक्षा वेगळ्या मार्गाने येणारी रहदारी नाकारते।

उत्तर मार्ग आणि रिझॉल्व्हर दोन वेगळी उत्तरे आहेत

फक्त विनंती नाही, उत्तराकडेही लक्ष ठेवा। विनंती भाषांतरित होऊन बाहेर पडत असेल आणि उत्तर भाषांतरित प्रवाहात परत येत असेल, तर फॉरवर्डिंग काम करते जरी अ‍ॅप अजूनही अयशस्वी होत असले, तरी पुढील तपासणी अ‍ॅप किंवा DNSची आहे।

जी साइट HTTP त्रुटी परत करते ते पुरावा आहे की इंटरनेटवर फॉरवर्डिंग कार्यरत आहे। जे नाव सुटत नाही जेव्हा पत्त्याद्वारे प्रवेश कार्यरत असतो, ती रिझॉल्व्हरची समस्या आहे, NATची नाही।

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