OpenWrt पर पूरे LAN के लिए OpenVPN क्लाइंट: काम करने वाला क्रम

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

तय करें कि टनल क्या साझा करेगी

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

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

किसी भी तरह, LAN सबनेट अलग-अलग रखें। एक जैसी रेंज एक ओर को सीधे जुड़ा दिखाती है, और इससे बना ब्लैक होल VPN की ख़राबी जैसा लगता है घंटों तक।

टनल को मालिक दें

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

एक ही डिवाइस को दो जगह न बनाएँ। घोषित इंटरफ़ेस के बगल में हाथ से बनी टनल ऐसा डिवाइस बनाती है जो मौजूद है पर ज़ोन में नहीं है, या जो रीलोड पर ग़ायब हो जाता है। दोनों क्लाइंट की विफलता जैसे दिखते हैं, और कोई भी ऐसी ग़लती नहीं देता जो असली कारण बताए। घोषणात्मक रास्ता चुनें और हाथ वाला मिटा दें।

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

ज़ोन बनाएँ, फिर उसमें फ़ॉरवर्ड करें

फ़ायरवॉल ज़ोन वह जगह है जहाँ नीति रहती है: इनपुट, आउटपुट, फ़ॉरवर्ड और मास्करेड। किसी ज़ोन में न होने वाली टनल उन डिफ़ॉल्ट से चलती है जो आपने नहीं चुने, और राउटर क्लाइंट को यह शायद ही कभी चाहिए होता है। नीचे के स्टैंज़ा इंटरफ़ेस घोषित करते हैं, उसे ज़ोन में रखते हैं और LAN ट्रैफ़िक को उस ज़ोन में जाने देते हैं।

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

21.02 से पुरानी रिलीज़ों में वही इंटरफ़ेस पंक्ति इस रूप में लिखी जाती है option ifname, इसलिए चिपकाने से पहले जाँचें कि इंस्टॉल किया गया फ़र्मवेयर कौन-सा रूप पढ़ता है। फ़ॉरवर्डिंग स्टैंज़ा वह अनुमति है जिससे LAN ट्रैफ़िक टनल का उपयोग कर पाता है। इसके बिना डिवाइस चालू है, क्लाइंट जुड़ा है, और कोई LAN होस्ट टनल तक नहीं पहुँचता। राउटर क्लाइंट पर जुड़ा है पर इंटरनेट नहीं सबसे आम रिपोर्ट यही है।

VPN ज़ोन पर मास्करेड पैकेट निकलने से पहले हर LAN पते को राउटर के टनल पते में समेट देता है। इससे दूसरी ओर आपके सबनेट तक वापसी रूट की ज़रूरत नहीं रहती।

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

NAT में असली अपलिंक का नाम लें

जहाँ अनुवाद नियम हाथ से लिखा जाता है वहाँ आउटगोइंग इंटरफ़ेस वही फ़ील्ड है जो गड़बड़ाता है। जो नियम vlan2 कहता है वह कुछ नहीं करता जब सेशन ppp0 पर ख़त्म होता है। बिना किसी इंटरफ़ेस वाला नियम ऐसे ट्रैफ़िक का भी अनुवाद कर सकता है जो निजी ही रहना चाहिए था। दोनों में से कोई ग़लती ख़ुद की घोषणा नहीं करती, क्योंकि टनल चलती रहती है।

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

उस नियम में ppp0 को ip route या चालू इंटरफ़ेस सूची से मिलने वाले इंटरफ़ेस से बदलें, फिर LAN होस्ट पेज खोलते समय काउंटर देखें। एक ही प्रदाता वाले राउटर पर अपलिंक के लिए एक मास्करेड नियम आम तौर पर काफ़ी है। टनल इंटरफ़ेस के लिए दूसरा नियम पहले का विकल्प नहीं है।

फिर क्लाइंट विकल्प जोड़ें जो तय करते हैं टनल में क्या जाता है। redirect-gateway निर्देश क्लाइंट का इंटरनेट ट्रैफ़िक VPN से भेजता है, और इसके बिना टनल सिर्फ़ वे रूट ले जाती है जो सर्वर भेजता है। DNS को छूने से पहले बनी रूट तालिका जाँचें।

दूसरी तालिका से Wi-Fi बाँटें

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

OpenWrt पर पॉलिसी-रूटिंग पैकेज ठीक यही संयोजन व्यक्त करते हैं। हाथ से करना भी चलता है, स्रोत नियम और ऐसी तालिका के साथ जिसका डिफ़ॉल्ट टनल डिवाइस की ओर इशारा करता हो।

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

घड़ी और डिवाइस फ़्लैग पर शक करें

यह persist-tun फ़्लैग रीस्टार्ट के दौरान टनल डिवाइस को जगह पर छोड़ता है। यह सर्वर को सूट करता है और ऐसे क्लाइंट को उलझाता है जिसकी स्थिति शुरू से फिर बननी चाहिए। राउटर क्लाइंट की समस्या ढूँढ़ते समय इसे हटाएँ, क्योंकि विफल वार्ता के बाद बचा रहने वाला डिवाइस छिपा देता है कि वास्तव में कौन-सा चरण टूटा। क्लाइंट के भरोसेमंद तरीके से जुड़ने के बाद ही इसे वापस रखें, उससे पहले नहीं।

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