अपने LAN के हर डिवाइस के साथ एक VPN कनेक्शन साझा करें

एक लैपटॉप टनल रखता है, घर के बाकी लोगों को वही पहुँच चाहिए, और पहली कोशिश सब कुछ जुड़े हुए मशीन की ओर इंगित करना है। यह उन कारणों से विफल होता है जिनका VPN से कोई लेना-देना नहीं: प्राप्त करने वाले होस्ट को पैकेट फ़ॉरवर्ड करना होगा, उसका स्रोत फिर से लिखना होगा और सुनिश्चित करना होगा कि जवाब वापसी का रास्ता पा लें। तीनों में से कोई एक छूटे तो जुड़ा हुआ लैपटॉप काम करता रहता है जबकि हर दूसरा डिवाइस टाइमआउट हो जाता है। समाधान क्लाइंट सेटिंग नहीं, रूटिंग डिज़ाइन है।

डिवाइस को होस्ट की ओर इंगित करना क्यों विफल होता है

दूरस्थ नेटवर्क के लिए पता किया गया पैकेट पाने वाला होस्ट उस पल के लिए राउटर बन जाता है, चाहे किसी ने उसे वैसे कॉन्फ़िगर किया हो या नहीं। फ़ॉरवर्डिंग Linux और Windows पर डिफ़ॉल्ट रूप से बंद रहती है, जब तक कोई सुविधा उसे चालू न करे। अनुवाद महत्वपूर्ण है क्योंकि दूरस्थ पक्ष को जानना होता है कि जवाब कहाँ भेजे जाएँ, और निजी LAN पता उसके लिए कुछ नहीं मायने रखता। वापसी रूट तीसरा हिस्सा है, और पहला ping सफल लगने पर लोग यही भूल जाते हैं।

सेटिंग्स को बेतरतीब बदलने के बजाय उसी क्रम में निदान करें। हर छूटा हिस्सा थोड़ा अलग लक्षण पैदा करता है।

होस्ट पर फ़ॉरवर्डिंग और अनुवाद चालू करें

जुड़े हुए होस्ट पर दो बदलाव पहले दो हिस्सों को कवर करते हैं: IPv4 फ़ॉरवर्डिंग चालू करें और LAN ट्रैफ़िक का अनुवाद टनल इंटरफ़ेस पर करें।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sysctl मान को /etc/sysctl.d के अंतर्गत एक फ़ाइल में सहेजें, और रीबूट के बाद MASQUERADE नियम फिर से जाँचें, क्योंकि फ़ायरवॉल फ़्रंटएंड कस्टम चेन साफ़ कर सकते हैं। Windows पर साझेदारी सुविधा दोनों चरण करती है, लेकिन यह LAN अडैप्टर को निश्चित सबनेट पर फिर से पता देती है और उसका गेटवे साफ़ कर देती है, जिससे स्थिर एड्रेसिंग और पोर्ट फ़ॉरवर्डिंग टूट जाती है। साझेदारी विफल हुई ऐसा निष्कर्ष निकालने से पहले नए पते पर राउटर का होस्ट तक का रास्ता बहाल करें। फिर देखें कि दूसरा डिवाइस ट्रैफ़िक भेजते समय नियम काउंटर बढ़ते हैं।

LAN को रीबूट के बाद भी टिकने वाला रास्ता दें

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

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

क्लाइंट के डिफ़ॉल्ट गेटवे को होस्ट की ओर इंगित करने से उसका सारा ट्रैफ़िक होस्ट से होकर जाता है, स्थानीय प्रिंटिंग और फ़ाइल साझेदारी सहित, इसलिए होस्ट के सोने पर असंबंधित चीज़ें रुक जाती हैं। दूरस्थ प्रीफ़िक्स के लिए राउटर पर विशिष्ट रूट जोड़ना संकीर्ण है: केवल टनल के पीछे के गंतव्य जुड़े हुए मशीन पर जाते हैं, और बाकी LAN काम करता रहता है। ऊपर के सबनेट उदाहरण हैं, इसलिए उन्हें अपनी LAN और टनल श्रेणियों से बदलें। किसी भी तरह, टनल चालू और फिर बंद अवस्था में दूसरे डिवाइस से परीक्षण करें।

टनल को दोष देने से पहले MTU देखें

टनल उपयोगी पैकेट आकार घटाते हैं, और दूसरे डिवाइस को इसकी भनक नहीं। बड़े ट्रांसफ़र और TLS हैंडशेक अटक जाते हैं जबकि छोटे अनुरोध सफल होते हैं।

ping -M do -s 1400 10.8.0.5

जवाब साबित करता है कि वह आकार बिना विखंडन के रास्ता पार करता है; टाइमआउट का अर्थ है कि एनकैप्सुलेशन ओवरहेड ने पैकेट को टनल के MTU से आगे धकेल दिया। साझेदारी इंटरफ़ेस पर MTU घटाएँ या फ़ॉरवर्डर पर अधिकतम सेगमेंट आकार सीमित करें, फिर वही जाँच दोहराएँ। पहले LAN पक्ष पर वही आकार जाँचें, क्योंकि स्थानीय विफलता टनल नहीं, LAN की ओर इशारा करती है। काम करने वाला आकार दर्ज करें, क्योंकि बाद में प्रदाता या टनल बदलने से वह खिसक सकता है।

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