VPN क्लाइंट जुड़ते हैं पर इंटरनेट नहीं: तीन गायब हिस्से

क्लाइंट को एक पता मिलता है, सर्वर ping का जवाब देता है, और फिर भी हर पृष्ठ समय-सीमा पार कर जाता है। ज़्यादातर लोग इसी मोड़ पर क्लाइंट प्रोफ़ाइल संपादित करना शुरू करते हैं, जो आम तौर पर व्यर्थ मेहनत है: टनल ऊपर आने के बाद सर्वर को राउटर की तरह व्यवहार करना पड़ता है। पैकेट बाहर जाए और जवाब लौटे, इससे पहले तीन शर्तें एक साथ पूरी होनी चाहिए, और कौन-सी गायब हो, लक्षण एक जैसा ही रहता है।

काम करता टनल भी बाहर जाने का रास्ता क्यों नहीं रखता

कर्नेल को इंटरफ़ेस के बीच पैकेट फ़ॉरवर्ड करने पड़ते हैं, जो ज़्यादातर Linux वितरणों में डिफ़ॉल्ट रूप से बंद रहता है। ट्रैफ़िक का अनुवाद ऐसे पते पर होना चाहिए जिसका जवाब बाहरी दुनिया दे सके, जब तक कि हर अपस्ट्रीम राउटर को टनल सबनेट तक का वापसी रास्ता पहले से पता न हो। फ़ायरवॉल के फ़ॉरवर्ड मार्ग को ट्रैफ़िक दोनों दिशाओं में अनुमति देनी चाहिए, जवाबों सहित।

इनमें से हर एक को अलग-अलग ठीक किया जा सकता है, और यही जाल है। अनुवाद नियम के बिना फ़ॉरवर्डिंग चालू करने से पैकेट निजी स्रोत के साथ और वापसी रास्ते के बिना निकलते हैं। फ़ॉरवर्ड नियम के बिना अनुवाद जोड़ने से कर्नेल एक कदम बाद पैकेट गिरा देता है।

इसलिए क्लाइंट नहीं, तीनों परतों की जाँच करें, और एक बार में एक बदलें ताकि नतीजे का कोई अर्थ हो।

फ़ॉरवर्डिंग कर्नेल का स्विच है जिसे स्थायी बनाना पड़ता है

बदलने से पहले मौजूदा मान जाँचें, फिर उसे सेट करें और पुष्टि करें कि बदलाव लागू हुआ।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

पहला आदेश मौजूदा मान बताता है, दूसरा उसे रनटाइम में सेट करता है, और तीसरा साबित करता है कि लिखाई काम कर गई। रनटाइम मान अगले रीबूट में गायब हो जाता है, इसलिए काम करता सत्र रखरखाव के बाद बिना किसी कॉन्फ़िगरेशन बदलाव के टूट सकता है।

इसे /etc/sysctl.d/ के अंतर्गत एक फ़ाइल में स्थायी करें, फिर पता लगाने के लिए रीबूट करने के बजाय वही फ़ाइल लागू करें। FreeBSD में समकक्ष net.inet.ip.forwarding है, और स्थायित्व के लिए rc.conf में gateway_enable=YES। जो उपकरण फ़ॉरवर्डिंग बंद बताता है, वह «पैकेट आते हैं और कुछ वापस नहीं आता» जैसी पूरी श्रेणी की रिपोर्टें समझा देता है। हर अपग्रेड के बाद भी सेटिंग जाँचें, क्योंकि फिर से बना कर्नेल या बदली गई उपकरण छवि किसी को बताए बिना इसे रीसेट कर सकती है।

masquerade या एक निश्चित अनुवाद पता चुनें

गतिशील बाहरी पते के साथ masquerading सबसे सरल सही रूप है। टनल सबनेट को स्रोत और बाहरी इंटरफ़ेस को निकास नाम दें।

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

स्थिर सार्वजनिक पते के साथ स्रोत का अनुवाद ठीक उसी पते पर अधिक अनुमानित और जाँचना आसान है।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

दूसरे रूप में रखरखाव का जाल है: हार्डकोड किया गया पता जो बाद में बदल जाता है, टनल चलाता रहता है जबकि इंटरनेट पहुँच चुपचाप रुक जाती है। या तो masquerade इस्तेमाल करें या जब भी प्रदाता आपको हटाए नियम अपडेट करें। इंटरफ़ेस भी मायने रखता है, क्योंकि अपना ही अपस्ट्रीम टनल साझा करने वाले राउटर को भौतिक WAN के बजाय उसी टनल से अनुवाद करना पड़ता है।

फ़िल्टर तालिका तीसरा द्वार है

फ़ॉरवर्डिंग और अनुवाद दोनों सही हो सकते हैं जबकि पैकेट फिर भी फ़िल्टर तालिका में मरता है। ufw बार-बार दोषी होता है: उसकी फ़ॉरवर्ड नीति DROP के रूप में आती है, और बाकी सेटअप पूरी तरह सही दिख सकता है जबकि वही एक सेटिंग ट्रैफ़िक को मार देती है। उसे ऊपर उठाना चेकबॉक्स नहीं, सोचा-समझा सुरक्षा निर्णय है।

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

पहला नियम टनल से बाहर की ओर नए ट्रैफ़िक को अनुमति देता है, और दूसरा केवल जवाबों को लौटने देता है। दोनों को टनल सबनेट और इच्छित गंतव्य तक सीमित करें, क्योंकि टनल इंटरफ़ेस पर व्यापक अनुमति VPN को हर उस व्यक्ति के लिए खुला निकास बिंदु बना देती है जो प्रमाणित हो सकता है।

ब्रिज किए गए टनल को अलग जवाब चाहिए। पता भौतिक पोर्ट का नहीं, ब्रिज का है, इसलिए इंटरफ़ेस को गुलाम बनाने से उसका पहले वाला पता हट जाता है और मेज़बान तब तक अगम्य दिखता है जब तक ब्रिज खुद एक पता न पा ले, जो dhclient br0 दे सकता है। वह विफलता VPN समस्या जैसी दिखती है और दूसरी परत की समस्या है। फ़ायरवॉल छूने से पहले ब्रिज का अपना पता जाँचें, क्योंकि फ़िल्टर बदलाव उस मेज़बान को ठीक नहीं कर सकता जिसके पास भेजने का पता ही नहीं है।

पृष्ठ कभी लोड न हो तो कहाँ देखें

टनल मौजूद है यह साबित करने के लिए सर्वर के टनल पते पर ping करें। फिर क्लाइंट से किसी सार्वजनिक पते तक traceroute चलाएँ और पढ़ें कि वह कहाँ रुकता है: सर्वर पर पैकेट पहुँचता है पर फ़ॉरवर्ड या अनुवाद नहीं होता; सर्वर से आगे समस्या अपस्ट्रीम है और आपके हाथ में नहीं।

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

पहला आदेश साबित करता है कि टनल ट्रैफ़िक को सर्वर तक ले जाता है, और दूसरा दिखाता है कि पैकेट बाहर कितनी दूर जाता है। टनल पते पर खत्म होता निशान सर्वर पर फ़ॉरवर्डिंग या अनुवाद की ओर इशारा करता है, जबकि एक हॉप बाद रुकता निशान प्रदाता या अपस्ट्रीम राउटर के वापसी मार्ग की ओर।

सर्वर पर, जब क्लाइंट कोई पृष्ठ लोड करे तब बाहरी इंटरफ़ेस देखें। निजी स्रोत पते के साथ निकलता ट्रैफ़िक मतलब अनुवाद गायब है, और जवाब बिल्कुल न आना मतलब फ़ॉरवर्ड मार्ग या अपस्ट्रीम वापसी मार्ग उसे गिरा रहा है।

अगर दूरस्थ क्लाइंट को सर्वर के LAN के मेज़बानों तक भी पहुँचना है, तो याद रखें कि LAN को टनल सबनेट तक वापसी मार्ग चाहिए। यह अनुवाद नहीं, रूटिंग है, और इंटरनेट मार्ग के आखिरकार काम करने के बाद सबसे ज़्यादा भूलाया जाने वाला कदम यही है।