OpenVPN क्लायंट सर्व्हरपर्यंत पोहोचतो पण LAN होस्टपर्यंत नाही: तपासणी सूची

क्लायंट सांगतो की जोडलेला आहे, टनेलचा पत्ता ping ला प्रतिसाद देतो, आणि ऑफिसच्या LAN वर काहीही प्रतिसाद देत नाही। जवळपास प्रत्येक क्लायंट अपग्रेडनंतर मला हे दिसते, आणि पहिली वृत्ती फायरवॉल उघडण्याची असते, जी सहसा चुकीचे पाऊल आहे: टनेल ठीक आहे, आणि तुटणे पॅकेटला ओलांडाव्या लागणाऱ्या तीन हॉप्सपैकी एकावर आहे। पॅकेट ज्या क्रमाने जाते त्याच क्रमाने मार्ग चाला, आधी क्लायंट मार्ग, नंतर सर्व्हरचे फॉरवर्डिंग, नंतर परतीचा प्रवास, आणि काही मिनिटांत तुम्हाला दोषाचा मालक सापडेल।

पहिली पायरी: क्लायंटचा राउटिंग निर्णय पहा

सर्व्हरला हात लावण्यापूर्वी, क्लायंट पॅकेट टनेलमध्ये पाठवतो हे सिद्ध करा। संपूर्ण टेबल वाचण्याऐवजी कर्नेलला एका विशिष्ट LAN होस्टसाठी कोणते इंटरफेस वापरेल असे विचारा:

ip route get 192.168.50.10

जर उत्तरात तुमचा भौतिक अॅडॉप्टर आणि ऑफिस गेटवेचा उल्लेख असेल, तर सर्व्हरच्या बाजूचा कोणताही बदल मदत करू शकत नाही। OpenVPN मार्ग फक्त सर्व्हरने ढकलले की वाटतो, म्हणून सर्व्हर कॉन्फिगरेशनमध्ये push "route 192.168.50.0 255.255.255.0" शोधा, आणि नंतर क्लायंट पुन्हा जोडा। बहुतेक क्लायंट ढकललेले मार्ग जोडणीच्या वेळी लागू करतात, प्रोफाइल पुन्हा लोड करताना नाही।

Windows वर त्याच प्रश्नाची वेगळी कमांड आहे। Find-NetRoute -RemoteIPAddress 192.168.50.10 स्टॅक निवडेल ते इंटरफेस आणि पुढील हॉप छापते, आणि route print -4 ढकललेला प्रीफिक्स अजिबात अस्तित्वात आहे का ते दाखवते।

दुसरी पायरी: सर्व्हर पॅकेट फॉरवर्ड करेल याची खात्री करा

जर क्लायंट मार्ग बरोबर असेल, तर पॅकेट सर्व्हरपर्यंत पोहोचते आणि सर्व्हरने ते फॉरवर्ड करण्यास संमती द्यावी लागते। कर्नेल स्विच हा पहिला दरवाजा आहे, आणि sysctl net.ipv4.ip_forward ने 1 परत द्यावे। echo 1 > /proc/sys/net/ipv4/ip_forward ने ते सेट करणे पुढील रीबूटपर्यंत चालते, आणि म्हणूनच तीच तक्रार आठवड्यांनंतर परत येते।

ते रीस्टार्टनंतर टिकणाऱ्या ठिकाणी लिहा:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

दुसरा दरवाजा फिल्टर टेबल आहे। Docker स्थापित असलेल्या होस्टवर बऱ्याचदा FORWARD धोरण DROP असते, आणि टनेल तो निर्णय वारसा घेते। iptables -L FORWARD -v -n धोरण आणि पॅकेट काउंटर दोन्ही दाखवते; धोरण DROP असल्यास, फॉरवर्डिंगला टनेलपासून LAN दिशेसाठी एक स्पष्ट परवानगी आणि प्रतिसादासाठी अजून एक आवश्यक आहे।

तिसरी पायरी: पॅकेट LAN पर्यंत पाठवा आणि प्रतिसाद शोधा

सर्व्हरच्या दोन्ही बाजू एकाच वेळी पहा। टनेलवर आणि LAN इंटरफेसवर कॅप्चर करा, एका क्लायंट आणि एका होस्टवर फिल्टर करून जेणेकरून आउटपुट वाचनीय राहील:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 वर आणि नंतर पुन्हा eth0 वर 10.8.0.x स्रोतासह दिसणाऱ्या विनंत्या, आणि त्यानंतर शांतता, याचा अर्थ पॅकेट पोहोचले आणि प्रतिसाद दुसरीकडे गेला। LAN होस्ट त्याच्या डीफॉल्ट गेटवेला प्रतिसाद देतो, त्या गेटवेकडे VPN पूलसाठी मार्ग नाही, आणि प्रतिसाद LAN राउटरवर मरतो। सर्व्हरवरून LAN होस्टला ping करणे या मार्गाबद्दल काहीही सिद्ध करत नाही, कारण तो रहदारी कधीही टनेल ओलांडत नाही।

चौथी पायरी: भाषांतर आणि परतीचा मार्ग यातून निवडा

दोन दुरुस्त्या भोक बंद करतात, आणि ping चालतो की नाही यापलीकडेही या निवडीचे परिणाम आहेत। स्रोत भाषांतर सर्व्हरला दिसणारा प्रेषक बनवते:

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

नियम पूल आणि LAN इंटरफेसपुरता मर्यादित करा, नंतर तो कायमस्वरूपी करा, नाहीतर पुढील फायरवॉल रीलोड तुमची दुरुस्ती शांतपणे काढून टाकेल। किंमत ओळख आहे: LAN लॉग आणि प्रवेश नियमांमध्ये प्रत्येक क्लायंट VPN सर्व्हरसारखा दिसतो, आणि per-client policy becomes guesswork।

LAN राउटरवर VPN सर्व्हरकडे निर्देश करणारा 10.8.0.0/24 साठी स्थिर मार्ग क्लायंट पत्ते दृश्यमान ठेवतो आणि तो राउटर तुमचा असल्यास हे दीर्घकालीन चांगले उत्तर आहे। अनेक साइट्स काही काळ दोन्ही चालवतात, तात्काळ दुरुस्तीसाठी NAT आणि फायरवॉल धोरण लिहिल्यानंतर मार्ग। जर सर्व्हर पूल नसून साइट-टू-साइट पीअर असेल, तर सर्व्हर बाजूलाही दूरच्या सबनेटसाठी iroute लागतो, नाहीतर पीअर मार्ग असतो पण क्लायंट रहदारी त्याच्याशी कधीही जोडली जात नाही।

पाचवी पायरी: क्लायंटवरून पडताळा आणि काय बदलले ते नोंदवा

लूप सर्व्हरवरून नाही, क्लायंटवरून बंद करा। LAN होस्टवरील खऱ्या सेवेशी जोडा, नंतर iptables -t nat -L POSTROUTING -v -n ने भाषांतर काउंटर हलले याची खात्री करा, कारण शून्य पॅकेटचा नियम हा कधीही जुळला नसलेला नियम आहे। परतीची दिशा ट्रॅक होत असल्याचा पुरावा हवा असल्यास conntrack -L -s 10.8.0.5 प्रवाह आणि त्याची स्थिती दाखवते।

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