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 लाई यसको ठेगाना इन्स्टल गरिएको नेटवर्क म्यानेजरबाट दिनुहोस्, उपकरणका लागि यससँग लड्ने पुरानो इन्टरफेस-फाइल विधिबाट होइन। त्यसपछि क्लाइन्ट मिलाउनुहोस्: एउटा उपकरणमा स्थिर गेटवे, वा 192.168.50.2 लाई राउटरको रूपमा दिने DHCP आरक्षण। दुई उपकरणका लागि राउटरको सम्पूर्ण 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 नयाँ क्वेरी सुरु गर्छ। त्यो माथिल्लो क्वेरी क्लाइन्टका लागि तपाईंले लेखेको forward नियम होइन, Pi को आफ्नै मार्ग पछ्याउँछ, त्यसैले टनेलबाट मात्र जाने क्लाइन्ट बाटो र सिधै बाहिर जाने समाधानकर्ता — यो कुनै त्रुटि सन्देश बिनैको चुहावट हो। जानाजान निर्णय गर्नुहोस्: टनेलबाट पुगिने समाधानकर्ता, वा सिधा भनी स्वीकार्ने स्थानीय समाधानकर्ता, र Pi को आफ्नै आउटपुट नीति त्यो निर्णयसँग मिलाउनुहोस्।
IPv6 फेरि छुट्टै अवस्था हो। IPv4 का लागि forward नियमले IPv6 बारे केही सीमित गर्दैन, र माथिल्लो लिङ्कका राउटर घोषणाले Pi लाई, र त्यसबाट जोडिएको खण्डलाई, तपाईंको नीति छल्ने दोस्रो पूर्वनिर्धारित दिन सक्छ। या त त्यही सिद्धान्तमा IPv6 लाई आफ्नै संरक्षित बाटो दिनुहोस्, वा क्लाइन्ट खण्डमा यसलाई स्पष्ट रूपमा सीमित गरेर त्यसो भन्नुहोस्।
विश्वास गर्नुअघि सीमा जाँच्नुहोस्
डिजाइनलाई चार छुट्टाछुट्टै जाँचपछि मात्र स्वीकार गर्नुहोस्, किनकि लोभ्याउने एकल परीक्षण — एउटा क्लाइन्टमा ब्राउजर खोल्नु — धेरै भाँचिएका अवस्थामा उत्तीर्ण हुन्छ।
एउटा वास्तविक क्लाइन्ट टनेलबाट इन्टरनेटमा पुग्छ भनी पुष्टि गर्नुहोस्, त्यसपछि त्यही क्लाइन्ट टनेल तल हुँदा इन्टरनेटमा पुग्न सक्दैन भनी पुष्टि गर्नुहोस्। DNS समाधान चल्छ र क्वेरी तपाईंले मनसाय गरेको ठाउँबाट बाहिर जान्छ भनी पुष्टि गर्नुहोस्। टनेल पुनःसुरु गरेपछि पनि Pi को आफ्नै ढुवानी चल्छ, र पुनःप्राप्तिलाई मेसिन रिबुट आवश्यक पर्दैन भनी पुष्टि गर्नुहोस्। अन्तमा, तपाईंले नछान्नुभएको उपकरण जाँच्नुहोस्: लेआउट A मा त्यो सामान्य रूपमा चलिरहनुपर्छ, र लेआउट B मा त्यो त्यो खण्डमा हुँदै हुनुहुँदैन।
- दुई पोर्ट र अस्वीकार नियमले कार्यान्वयन दिन्छ; एउटा पोर्ट र DHCP विकल्पले सल्लाह दिन्छ।
- गलत इन्टरफेसमा अनुवाद सफलता जस्तो देखिन्छ र होइन।
- Pi को आफ्नै ट्राफिक, DNS र IPv6 प्रत्येकलाई निर्णय चाहिन्छ, अनुमान होइन।