मास्करेड या नीति-आधारित रूटिंग: VPN गेटवे से LAN ट्रैफ़िक

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

दोनों डिज़ाइन अलग-अलग चीज़ों का वादा करते हैं

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

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

विफलता के तरीके वादों जितने ही अलग हैं। अनुपस्थित मास्करेड नियम ऐसे पैकेट बनाता है जो निजी स्रोतों के साथ निकलते हैं और कभी लौटते नहीं। अनुपस्थित वापसी रूट नीति-आधारित रूटिंग में वही लक्षण देता है, पर सुधार गेटवे पर नहीं, दूर के राउटर पर होता है।

मास्करेड: दूर के सिरे पर एक ही पीयर

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

DNS एक अलग निर्णय है। दूर के सिरे का रिज़ॉल्वर तभी जवाब देता है जब उसका जवाब क्लाइंट तक वापस जा सके। मास्करेड के तहत क्वेरी गेटवे से आती दिखती है, इसलिए रिज़ॉल्वर का वापसी मार्ग पहले से पूरा है; नीति-आधारित रूटिंग के तहत रिज़ॉल्वर को वही वापसी रूट चाहिए जो किसी भी अन्य दूर की सेवा को।

नीति-आधारित रूटिंग: स्रोत रखें, वापसी मार्ग जोड़ें

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

फिर दूर के सिरे को LAN प्रीफ़िक्स को टनल से होकर वापस रूट करना होता है। यह दूर के राउटर पर सेटिंग है, इस गेटवे पर नहीं। गेटवे को ऐसे जवाब भी स्वीकार करने होते हैं जो मुख्य तालिका के अनुमान से अलग इंटरफ़ेस पर आते हैं; सख़्त मोड के उन पैकेटों को गिरा देने पर ढीली रिवर्स-पाथ फ़िल्टरिंग (rp_filter को 2 पर सेट) सामान्य समायोजन है।

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

स्वामित्व और दूर का सिरा क्या लॉग करता है, इसके आधार पर तय करें

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

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

हाइब्रिड डिज़ाइन सामान्य हैं: अपने नेटवर्क के भीतर नीति-आधारित रूटिंग, प्रदाता के किनारे मास्करेड। मायने यह रखता है कि लिखकर रखें कौन-सा हॉप अनुवाद करता है और कौन-सा हॉप रूट करता है, क्योंकि एक क्लाइंट के लिए ग़लती से जोड़ा गया NAT नियम उसी श्रृंखला के हर क्लाइंट का स्रोत छिपा देता है।

एक क्लाइंट से जाँचें, फिर दूसरे क्लाइंट से

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

पुनः कनेक्ट के बाद परीक्षण दोहराएँ। इंटरफ़ेस का नाम लेने वाला मास्करेड नियम नए टनल पते पर टिकता है; पुराने पते का नाम लेने वाला नियम नहीं टिकता। फिर दूसरे LAN होस्ट को परखें, क्योंकि एक मशीन पर चलने वाला डिज़ाइन अक्सर उसी मशीन के अपने रूट पर निर्भर होता है, गेटवे की नीति पर नहीं।

चुना गया मॉडल, अनुवादित या सुरक्षित स्रोत और वापसी रूट का स्वामी गेटवे के नोट्स में लिखें। वरना अगला व्यक्ति जो क्लाइंट या टनल जोड़ेगा वह अनुमान लगाएगा, और अनुमान ही वह तरीका है जिससे चलती हुई LAN-से-VPN व्यवस्था आधी-अधूरी हो जाती है।