Raspberry Pi पर VPN गेटवे: एक नेटवर्क पोर्ट या अलग क्लाइंट पोर्ट
एक Pi पोर्ट चुने हुए क्लाइंट की सेवा कर सकता है, या दूसरा पोर्ट डिवाइसों को भीतर बंद कर सकता है। अलगाव, फ़ॉलबैक नीति और DNS किसका है, इनके आधार पर लेआउट चुनें।
आपके पास एक Pi, एक काम करता बाहर जाने वाला VPN प्रोफ़ाइल और दो डिवाइस हैं जिन्हें उसके ज़रिए इंटरनेट तक पहुँचना चाहिए। पूरे निर्माण का फ़ैसला करने वाला सवाल यह नहीं है कि कौन-सी गाइड का पालन करें, बल्कि यह है कि आपको कितना अलगाव चाहिए। एक पोर्ट Pi को उन डिवाइसों के बगल में राउटर के LAN पर बैठने और अतिरिक्त गेटवे की तरह काम करने देता है; दूसरा पोर्ट आपको उन्हें ऐसे सेगमेंट में रखने देता है जहाँ Pi ही बाहर निकलने का एकमात्र रास्ता है। उस चुनाव के बाद का सब कुछ — DHCP, फ़ायरवॉल का दायरा, DNS, विफलता का मामला — उसी से निकलता है।
दोनों लेआउट असल में किसमें अलग हैं
दोनों डिज़ाइन रूटिंग करते हैं। फ़र्क यह है कि तार पर और कौन खड़ा है और जब आपकी नीति गलत हो तो क्या होता है।
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
अलगाव ही असली धुरी है। लेआउट A सलाहकारी है: जो डिवाइस DHCP से मिले गेटवे को नज़रअंदाज़ करके राउटर चुनता है, वह बिना एन्क्रिप्शन के भी चलता रहता है। लेआउट B टोपोलॉजी से लागू होता है, क्योंकि चुनने के लिए कोई दूसरा अगला हॉप नहीं है।
लेआउट A: मौजूदा LAN पर Pi अतिरिक्त गेटवे की तरह
मान लें कि ISP का राउटर 192.168.50.1 है, Pi 192.168.50.2 है, और चुने गए क्लाइंट Pi की ओर इशारा करते हैं। अहम बात यह है कि दो अलग पैकेट प्रवाह एक ही केबल साझा करते हैं। क्लाइंट का भीतरी पैकेट Pi तक पहुँचता है और टनल से बाहर जाना चाहिए; Pi का अपना एन्क्रिप्टेड पैकेट VPN साथी की ओर उसी केबल से राउटर की तरफ़ बाहर जाना चाहिए। वे एक ही इंटरफ़ेस पर उलटी दिशाओं में चलते हैं और अलग व्यवहार चाहते हैं।
Pi को उसका पता इंस्टॉल किए गए नेटवर्क मैनेजर से दें, किसी पुरानी इंटरफ़ेस-फ़ाइल रेसिपी से नहीं जो डिवाइस के लिए उससे लड़ती है। फिर क्लाइंट सेट करें: एक डिवाइस पर स्थिर गेटवे, या एक DHCP आरक्षण जो 192.168.50.2 को राउटर के रूप में देता है। दो डिवाइसों के लिए राउटर का पूरा DHCP दायरा न बदलें, और यह न मानें कि क्लाइंट इस विकल्प का सम्मान करता है — इसे सत्यापित करें।
कमज़ोरी ढाँचागत है, सुधारने योग्य नहीं। उस सेगमेंट का कोई भी क्लाइंट 192.168.50.1 की ओर इशारा करके साफ़ रूप में बाहर जा सकता है, और दूसरे इंटरफ़ेस या सेलुलर रेडियो वाला डिवाइस आपका प्रवर्तन मार्ग पूरी तरह छोड़ देता है। अगर वह वाक्य संबंधित डिवाइस के लिए अस्वीकार्य है, तो आपका जवाब पहले से है: लेआउट B इस्तेमाल करें।
लेआउट B: अलग पोर्ट डिवाइसों को भीतर बंद कर देता है
यहाँ Pi अपलिंक पर गेटवे 192.168.50.1 के साथ 192.168.50.2 रखता है, और जुड़े डिवाइसों के लिए दूसरे इंटरफ़ेस पर 10.20.0.1/24 लेता है। अब Pi दो नेटवर्क वाला राउटर है, और जुड़े सेगमेंट के पास ठीक एक ही निकास है।
प्रतिबद्ध होने से पहले रेंज को बाकी सबके सामने जाँचें: टनल का अपना सबनेट, दूसरे साइट-टू-साइट प्रीफ़िक्स, और VPN से पहुँचने योग्य हर चीज़। दूर के LAN से टकराता 10.20.0.0/24 वही आधा-चलता परिणाम देता है जिसका निदान एक शाम लेता है। अगर दूसरा पोर्ट USB अडैप्टर है, तो पुष्टि करें कि वह समर्थित है और नेटवर्क मैनेजर में उसका नाम पिन करें ताकि रीबूट के बाद की पुनर्व्यवस्था आपका LAN पता न हिलाए।
DHCP श्रोता को सिर्फ़ उसी इंटरफ़ेस पर चलाएँ। अपलिंक पर जवाब देने वाला सर्वर ISP राउटर से मुकाबला करता है और आपके सेगमेंट के पते बाकी घर को दे देता है। इसे LAN इंटरफ़ेस से बाँधें, घोषित रेंज तक सीमित रखें, और Pi का अपना पता पूल से बाहर रखें।
फ़ॉरवर्डिंग, अनुवाद और विफलता पर बंद होने का नियम
चार चीज़ें अक्सर एक बताई जाती हैं और एक नहीं हैं। फ़ॉरवर्डिंग चालू करना (net.ipv4.ip_forward=1) कर्नेल को सिर्फ़ यह बताता है कि वह इंटरफ़ेसों के बीच पैकेट खिसका सकता है; यह अपने आप कुछ भी अनुमति नहीं देता और किसी मार्ग की गारंटी नहीं देता। इग्रेस चुनना रूटिंग का फ़ैसला है। पैकेट की अनुमति देना forward श्रृंखला में नीति का फ़ैसला है। उसके स्रोत को फिर से लिखना postrouting का फ़ैसला है। सिर्फ़ पहला करने वाला निर्माण ऐसा Pi बनाता है जो क्लाइंट ट्रैफ़िक को ख़ुशी से अपलिंक से बाहर फ़ॉरवर्ड करता है।
अनुमति को उन स्रोतों तक सीमित करें जिनका आपने इरादा किया और उस इंटरफ़ेस तक जिसका ट्रैफ़िक को उपयोग करना चाहिए, और वापसी मार्ग तथा Pi के अपने ज़रूरी गंतव्यों को शामिल करें। फिर अगर प्रदाता आपके LAN प्रीफ़िक्स को आपकी ओर वापस रूट नहीं करता तो टनल इग्रेस पर अनुवाद करें। nftables मैनुअल फ़ॉरवर्डिंग, स्थानीय आउटपुट और स्रोत-अनुवाद को अलग क्रियाओं के रूप में देखता है, जो यहाँ सही मानसिक मॉडल है।
आम विफलता भौतिक इंटरफ़ेस पर चौड़ा masquerade नियम है। तब ट्रैफ़िक ISP मार्ग से इंटरनेट तक पहुँचता है, जबकि क्लाइंट की तरफ़ से वह ठीक काम करते VPN जैसा दिखता है। यह कुछ साबित नहीं करता। अनुवाद को घोषित इग्रेस से बँधा रखें, और अपने नियम उसी फ़ायरवॉल में रखें जो होस्ट पहले से इस्तेमाल करता है, ऐसा प्रतिस्पर्धी नियम-समूह जोड़ने के बजाय जो साझा postrouting श्रृंखला खाली कर देता है।
फिर टनल की अनुपस्थिति सँभालें। चौड़ा डिफ़ॉल्ट रूट इंस्टॉल करने वाली क्लाइंट प्रोफ़ाइल का यह भी मतलब है कि जब टनल गिरता है, सामान्य डिफ़ॉल्ट लौट सकता है और क्लाइंट ट्रैफ़िक चुपचाप अपलिंक पर लौट जाता है। जहाँ साफ़ टेक्स्ट पर वापस जाना स्वीकार्य नहीं है, वहाँ forward नीति को क्लाइंट-से-अपलिंक ट्रैफ़िक को स्पष्ट रूप से अस्वीकार करना होगा, उस स्थिति में जब VPN मार्ग जा चुका हो। इसे अस्वीकृति नियम के रूप में लिखें, धारणा के रूप में नहीं। Pi का अपना एन्क्रिप्टेड परिवहन VPN साथी की ओर अलग local-output प्रवाह है और उसे अनुमत रहना चाहिए, वरना टनल कभी वापस नहीं आ सकता।
DNS और IPv6 को अपना जवाब चाहिए
अगर क्लाइंट Pi को रिज़ॉल्वर के रूप में इस्तेमाल करते हैं, तो वे स्थानीय श्रोता तक पहुँचते हैं और Pi नई क्वेरी शुरू करता है। वह ऊपरी क्वेरी Pi के अपने मार्ग का पालन करती है, उस forward नियम का नहीं जो आपने क्लाइंट के लिए लिखा, इसलिए सिर्फ़ टनल से जाने वाला क्लाइंट मार्ग और सीधे बाहर जाने वाला रिज़ॉल्वर — यह बिना किसी त्रुटि संदेश के लीक है। जानबूझकर तय करें: टनल से पहुँचने वाला रिज़ॉल्वर, या स्थानीय जिसे आप सीधा स्वीकारते हैं, और Pi की अपनी आउटपुट नीति को उस फ़ैसले से मिलाएँ।
IPv6 फिर से अलग मामला है। IPv4 के लिए forward नियम IPv6 के बारे में कुछ भी सीमित नहीं करता, और अपलिंक पर राउटर की घोषणाएँ Pi को, और उसके ज़रिए जुड़े सेगमेंट को, आपकी नीति से बचने वाला दूसरा डिफ़ॉल्ट दे सकती हैं। या तो उसी सिद्धांत पर IPv6 को अपना सुरक्षित मार्ग दें, या क्लाइंट सेगमेंट पर उसे स्पष्ट रूप से सीमित करें और यह कहें।
भरोसा करने से पहले सीमा जाँचें
डिज़ाइन को सिर्फ़ चार अलग जाँचों के बाद स्वीकार करें, क्योंकि लुभाने वाला अकेला परीक्षण — एक क्लाइंट पर ब्राउज़र खोलना — कई टूटी स्थितियों में पास हो जाता है।
पुष्टि करें कि एक वास्तविक क्लाइंट टनल से इंटरनेट तक पहुँचता है, फिर पुष्टि करें कि वही क्लाइंट टनल बंद होने पर इंटरनेट तक नहीं पहुँच सकता। पुष्टि करें कि DNS रिज़ॉल्यूशन काम करता है और क्वेरी वहीं से बाहर जाती है जहाँ आप चाहते थे। पुष्टि करें कि टनल रीस्टार्ट के बाद Pi का अपना परिवहन अब भी काम करता है, और रिकवरी के लिए मशीन रीबूट की ज़रूरत नहीं होती। अंत में, वह डिवाइस जाँचें जो आपने नहीं चुना: लेआउट A में उसे सामान्य रूप से काम करते रहना चाहिए, और लेआउट B में उसे उस सेगमेंट में बिल्कुल नहीं होना चाहिए।
- दो पोर्ट और अस्वीकृति नियम प्रवर्तन देते हैं; एक पोर्ट और DHCP विकल्प सलाह देते हैं।
- गलत इंटरफ़ेस पर अनुवाद सफलता जैसा दिखता है और नहीं है।
- Pi का अपना ट्रैफ़िक, DNS और IPv6, हर एक को फ़ैसला चाहिए, अनुमान नहीं।