राउटरवरील VPN काम करते, पण LAN क्लायंटना इंटरनेट नाही

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

LAN होस्टवरून बिघाड वाचा

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

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

स्थानिक आणि फॉरवर्ड होणारी रहदारी वेगळी आहे

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

परतीचा मार्गही असला पाहिजे

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

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

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

एक परवानगी असलेला आणि एक नाकारलेला प्रवाह तपासा

दुरुस्तीनंतर राउटरच्या विद्यमान सत्राऐवजी क्लायंटवरून नवीन कनेक्शनची चाचणी करा. नंतर ज्या विभागाने टनेल वापरू नये तो अजूनही वापरत नाही याची पुष्टी करा.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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