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 राउटर के पास वापसी रूट है। अगली बार जब कोई क्लाइंट अपग्रेड पुश किया गया रूट मिटा दे, तो वह नोट आग बुझाने के सत्र को एक पंक्ति की मरम्मत में बदल देता है।