VPN क्लायंट सर्व्हरपर्यंत पोहोचतात, LAN पर्यंत नाही: कोणता उपाय?

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

प्रथम कोणती दिशा तुटली आहे ते ठरवा

विनंती VPN पूलमधून आलेल्या स्रोत पत्त्यासह टनेल इंटरफेसवर येते। सर्व्हर ती LAN मधील होस्टकडे पाठवतो, आणि तो होस्ट आपल्या तक्त्याने नमूद केलेल्या गेटवेला उत्तर देतो, सहसा LAN च्या राउटरला। राउटरकडे पूलसाठी रूट नसल्यास उत्तर तिथेच मरते किंवा इंटरनेटच्या दिशेने भटकते।

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

पहिला प्रश्न: तुम्ही दूरच्या LAN चा राउटर संपादित करू शकता का?

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

कोणी पूल बदललेल्या दिवशी ते शांतपणे अपयशी होते। मूल्य एकदा लिहून ठेवा आणि तीनपैकी कोणत्याही ठिकाणचा बदल तिन्हींचा बदल माना।

सेवा होस्ट करणाऱ्या NAS किंवा Layer 3 स्विचला तोच रूट लागतो, जोपर्यंत ते सर्व काही तो रूट असलेल्या राउटरमार्फत पाठवत नाही। उपनेट संपवणारे उपकरण तपासा, फक्त इंटरनेटकडे पाहणारे नाही। लहान नेटवर्कमध्ये अनेकदा राउटिंगबद्दल मत असलेली तीन उपकरणे असतात।

दुसरा प्रश्न: LAN क्लायंट पत्ते पाहणे थांबवू शकते का?

राउटर दुसऱ्याचा असेल, तर VPN सर्व्हरवरील भाषांतराला सहकार्याची गरज नसते। LAN मधील होस्ट सर्व्हरचा LAN पत्ता पाहतो, त्याला उत्तर देतो, आणि सर्व्हर परत भाषांतर करतो। म्हणूनच उपकरणे आणि NAT आधारित दूरस्थ प्रवेश भूमिका असे वागतात।

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

किंमत श्रेय आहे: प्रत्येक क्लायंटचे पत्ते LAN च्या लॉगमधून गायब होतात। LAN मधील होस्टवरील कोणतीही परवानगी यादी मग पूलऐवजी सर्व्हरचे नाव घेते।

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

तिसरा प्रश्न: सर्व्हर स्वतः दुसऱ्या टनेलचा क्लायंट आहे का?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

नंतर दोन्ही दिशा आणि दोन्ही आकार तपासा

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

नंतर खरा डेटा हलवा, कारण छोटा ping यशस्वी होत असताना मोठे हस्तांतरण अडकणे हे MTU चे लक्षण आहे। ती खराबी रूट दुरुस्त केल्याबद्दल स्वतःचे अभिनंदन केल्यानंतर लगेच दिसते।

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