एक LAN सबनेट को OpenVPN से रूट करें और डिफ़ॉल्ट रखें
एक सबनेट को टनल से गुज़रने देते हुए LAN डिफ़ॉल्ट रखें। पॉलिसी तालिका की तुलना मुख्य तालिका के संपादनों से करें, फिर NAT या सर्वर-साइड रूट चुनें।
जो बॉक्स किसी LAN के लिए रूट करते हैं और साथ ही VPN डायल करते हैं, वे अपने ही साथ उसी बहस में फँस जाते हैं: टनल डिफ़ॉल्ट रूट का मालिक बनना चाहता है, और LAN को वह वापस चाहिए। जब OpenVPN जुड़ता है, तो वह टनल के रास्ते एक डिफ़ॉल्ट या दो आधे-डिफ़ॉल्ट रूट लगा सकता है, जो लैपटॉप के लिए सही है और ऐसे गेटवे के लिए ग़लत है जिसके पड़ोसी उसके LAN पते से जवाब की उम्मीद करते हैं। जवाब VPN छोड़ देने में नहीं है। जवाब यह है कि दोनों फ़ैसलों को अलग-अलग तालिकाएँ दी जाएँ।
एक डिफ़ॉल्ट रूट, दो मालिक
फ़ॉरवर्ड किया गया ट्रैफ़िक और स्थानीय रूप से बना ट्रैफ़िक एक ही रास्ता नहीं लेना पड़ता। LAN क्लाइंट्स को टनल सिर्फ़ उन गंतव्यों के लिए चाहिए जिन्हें आप चुनते हैं, जबकि होस्ट के अपने प्रबंधन सत्रों और उन क्लाइंट्स को दिए जवाबों को LAN डिफ़ॉल्ट चाहिए। दोनों को मुख्य तालिका में मिलाने से दो अलग सवालों पर एक ही जवाब थोप दिया जाता है।
OpenVPN में ठीक इसी के लिए एक स्विच है। route-noexec क्लाइंट को मुख्य तालिका छूने से ही रोक देता है, और जो मान वह इस्तेमाल करता, वे route-up स्क्रिप्ट में route_vpn_gateway, dev और इंटरफ़ेस के पते के रूप में भेज दिए जाते हैं। फिर आप तय करते हैं कि कौन-सी तालिका कौन-सा रूट पाएगी, ऐसे कोड में जिसे आप बाद में पढ़ सकें।
पॉलिसी तालिका बनाम मुख्य तालिका को फिर से लिखना
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
अलग तालिका ही एकमात्र विकल्प है जो एक सबनेट से आगे बढ़ता है। इसे एक बार नाम दें, फिर नाम से ही इसका ज़िक्र करें ताकि किसी को कोई संख्या याद न रखनी पड़े:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnयहाँ के पते प्लेसहोल्डर हैं। कुछ भी चलाने से पहले अपनी खुद की तैनाती से LAN प्रीफ़िक्स, टनल गेटवे और डिवाइस का नाम बदलें।
नियम को होस्ट से भी मेल खाना चाहिए
सिर्फ़ LAN प्रीफ़िक्स से मेल खाने वाला नियम फ़ॉरवर्ड किए गए पैकेटों को कवर करता है। यह गेटवे के खुद बनाए ट्रैफ़िक को कवर नहीं करता, और LAN क्लाइंट्स को लौटाए जाने वाले जवाबों को भी कवर नहीं करता, जो स्रोत के रूप में गेटवे का LAN पता ले जाते हैं। वे लुकअप main में गिर जाते हैं और अभी भी टनल से बाहर निकल सकते हैं।
गेटवे के अपने LAN पते के लिए दूसरा नियम जोड़ें, या पहले नियम को ऐसे समूह तक बढ़ाएँ जिसमें दोनों शामिल हों। क्रम मायने रखता है: ज़्यादा विशिष्ट नियम पहले रखें, और स्रोत को स्पष्ट रूप से बताने वाले लुकअप से नतीजा जाँचें।
ip route get 203.0.113.9 from 192.168.50.1अगर वह ऐसे गंतव्य के लिए टनल डिवाइस बताता है जो स्थानीय रहना चाहिए, तो तालिका में क्या है इसके बावजूद नियमों का समूह ग़लत है।
NAT या दूसरी तरफ़ रूट
VPN सर्वर टनल सबनेट जानता है और कुछ नहीं। LAN स्रोत पते के साथ आने वाले पैकेटों के पास वापसी का रास्ता नहीं होता जब तक कोई उसे न दे, और उसे देने के ठीक दो तरीके हैं। सर्वर पर LAN प्रीफ़िक्स के लिए रूट जोड़ने से मूल स्रोत सिरे से सिरे तक दिखता रहता है, जो ऑडिट किए गए डिज़ाइन को आमतौर पर चाहिए। गेटवे पर मास्करेड करने से स्रोत टनल पते में फिर से लिखा जाता है और सर्वर के किसी सहयोग की ज़रूरत नहीं होती।
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEजब आप सर्वर नियंत्रित नहीं करते और वहाँ रूट नहीं जोड़ सकते तो NAT चुनें। जब लॉग, एक्सेस नियंत्रण या वापसी मार्ग की समरूपता मायने रखती है तो सर्वर-साइड रूट चुनें, क्योंकि मास्करेड मूल पता उस सब से मिटा देता है जो दूसरी तरफ़ दर्ज करती है।
दोनों हालत में फ़ॉरवर्डिंग सक्षम होनी चाहिए, और सख़्त रिवर्स-पाथ फ़िल्टरिंग जवाब गिरा सकती है जब main उस स्रोत के लिए टनल न चुनता। टनल को दोष देने से पहले प्रभावी मान जाँचें।
विभाजन को पुनः कनेक्शन के बाद भी बना रहने दें
हाथ से जोड़े गए नियम और रूट इंटरफ़ेस फिर से बनने पर ग़ायब हो जाते हैं, और पुरानी तालिका प्रविष्टि उस सत्र से ज़्यादा जी सकती है जिसने उसे जायज़ ठहराया था। तालिका का नियम, टनल का रूट और मास्करेड प्रविष्टि क्लाइंट की route-up स्क्रिप्ट के अंदर रखें, और स्क्रिप्ट के शुरू में तालिका ख़ाली करें ताकि पुराना गेटवे नए सत्र में न जी पाए।
दोनों सिरों से जाँचें: गेटवे पर LAN स्रोत के साथ एक लुकअप, और LAN क्लाइंट से ऐसे गंतव्य तक असली अनुरोध जो टनल से गुज़रना चाहिए। जो रूट मौजूद है पर कभी चुना नहीं जाता, वह काउंटर पढ़ने तक बिल्कुल रूट न होने जैसा व्यवहार करता है।