मल्टी-राउटर Pi VPN: हर रूट को उस डिवाइस पर रखें जो निर्णय लेता है
एक डाउनस्ट्रीम राउटर दूसरा क्लाइंट सबनेट जोड़ता है, और चारों डिवाइसों में से हर एक के पास एक निर्णय है। रूट रखें, स्रोत जाँचें, फिर असली क्लाइंट से परखें।
Pi के पीछे Wi-Fi बॉक्स लगाने से एक राउटिंग निर्णय चार हो जाता है, और योजना तब टूटती है जब चारों एक ही डिवाइस पर लिए जाएँ। पहला सवाल यह नहीं है कि कौन-सा रूट जोड़ें। सवाल यह है कि नया बॉक्स ब्रिज करता है या राउट करता है, क्योंकि वही जवाब तय करता है कि कितने सबनेट हैं और किन डिवाइसों को उनके बारे में सीखना है। पहले जुड़ाव का मॉडल चुनें; हर रूट उसी से निकलता है।
ब्रिज या राउट: वह चुनाव जो संख्या तय करता है
ब्रिज नए क्लाइंटों को उसी सबनेट पर रखता है जिसे Pi पहले से सेवा देता है। एक सबनेट, एक DHCP अधिकारी, और राउट करने के लिए कोई हैंडऑफ़ नहीं। यह सरल व्यवस्था है और तब सही है जब अलग क्लाइंट नेटवर्क कभी ज़रूरत न रहा हो। राउटेड लिंक अलग डिज़ाइन है: बॉक्स अपना सबनेट रखता है, और वह प्रीफ़िक्स हर वहाँ ले जाना पड़ता है जहाँ ट्रैफ़िक जाता है।
इस योजना का बाकी हिस्सा डाउनस्ट्रीम राउटर रखता है और क्लाइंट स्रोत पतों को सुरक्षित रखता है। लक्ष्य एक निजी VPN नेटवर्क है, पूरा इंटरनेट एग्ज़िट नहीं। मॉडल पतों से पहले लिखें, क्योंकि नीचे की सूची केवल राउटेड जुड़ाव का उदाहरण है।
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24कौन क्या तय करता है
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
हर डिवाइस एक निर्णय लेता है, और कोई किसी दूसरे का निर्णय उसकी जगह नहीं ले सकता। Pi को एक नहीं, दो प्रविष्टियाँ चाहिए, और लौटने का रास्ता वही है जो लोग भूल जाते हैं। फ़ॉरवर्ड किया गया ट्रैफ़िक निजी नेटवर्क तक ठीक पहुँचता है और फिर लौटते रास्ते पर मर जाता है, क्योंकि Pi को पता नहीं कि 10.41.0.0/24 कहाँ रहता है। यह फ़ायरवॉल की समस्या जैसा दिखता है और असल में एक गायब रूट है।
दूर वाले पक्ष को भी अपना रूट चाहिए। अगर दूर के छोर की सेवा नहीं जानती कि 10.41.0.0/24 आपके टनल से पहुँचा जा सकता है, तो जवाब पहले उस हॉप पर रुक जाते हैं जिसके पास कोई जवाब नहीं है। पैकेट फ़िल्टर पढ़ने से पहले दोनों दिशाएँ जोड़ें।
अगली हॉप जुड़ाव से आती हैं
अगली हॉप ऐसे नेटवर्क पर एक पता होनी चाहिए जहाँ डिवाइस वास्तव में पहुँच सके। VPN पीयर का सार्वजनिक पता निजी सबनेट के लिए अगली हॉप नहीं है, और दूर का सेवा नेटवर्क किसी भी तरह अगली हॉप नहीं है। अपहुँच गेटवे तक का रूट सूची में सही दिखता है और हर पैकेट गिरा देता है। गंतव्य को दोष देने से पहले जाँचें कि गेटवे जवाब देता है।
Pi के बाहरी VPN पीयर को उसके अपने अंडरले रूट से पहुँचने योग्य रखें। वह प्रविष्टि पेलोड रूट से अलग है, और उन्हें मिलाने से ऐसा टनल मिलता है जो पथ बदलने के बाद फिर से स्थापित नहीं हो सकता।
स्टैटिक रूट का दस्तावेज़ीकरण गंतव्य और गेटवे के बीच का अंतर साफ़ करता है, हालाँकि हर प्लेटफ़ॉर्म अपने मेनू को अलग तरह से नाम देता है। दूसरे विक्रेता की स्क्रीन कॉपी करने के बजाय अपने सामने के डिवाइस का दस्तावेज़ पढ़ें। नीचे के कमांड Linux पर प्रविष्टियों का आकार दिखाते हैं।
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1अनुवाद स्रोत के साथ क्या करता है
अगर डाउनस्ट्रीम राउटर पहले से अपने क्लाइंटों का ट्रांज़िट पते में अनुवाद करता है, तो Pi हर क्लाइंट के अपने पते की जगह एक अनूदित स्रोत देखता है। यह ऊपर वाले स्रोत-संरक्षक डिज़ाइन से अलग है। यह स्रोत-आधारित नीति, लॉगिंग और यह बदलता है कि कौन-सा पक्ष कनेक्शन शुरू कर सकता है। दोनों डिज़ाइन काम करते हैं; वे अलग सवालों के जवाब देते हैं।
जब कोई अपस्ट्रीम VPN सेवा क्लाइंट प्रीफ़िक्स को वापस राउट करने से इनकार करती है, तो Pi के टनल इग्रेस पर संकरा अनुवाद एक वैध अस्थायी उपाय हो सकता है। यह सबूत नहीं है कि गायब रूट अनावश्यक था। दर्ज करें कि दूर का नेटवर्क असल में कौन-सा पता देखता है और कौन-सा वापसी पथ बनता है।
रूट चयन, फ़ॉरवर्डिंग अनुमति और स्रोत अनुवाद तीन अलग काम रहते हैं। साझा NAT चेन फ़्लश करना या हर इंटरफ़ेस को अनुमति देना इसलिए कि एक वायर्ड क्लाइंट काम करता है, यही तरीका है जिससे काम करता परीक्षण खुला फ़ॉरवर्डर बन जाता है।
इसे क्लाइंट मशीन से साबित करें
डाउनस्ट्रीम LAN की किसी मशीन से अनुरोध भेजें, फिर उसके स्रोत को बाहर और वापस ट्रैक करें। Pi द्वारा भेजा गया ping कभी डाउनस्ट्रीम वापसी रूट का उपयोग नहीं करता, इसलिए सफल ping दिखने से कम साबित करता है। Pi के अपने LAN पर एक वायर्ड क्लाइंट से दूसरा परीक्षण जोड़ें ताकि दोनों रास्तों की तुलना हो सके। किसी भी डिवाइस को रीबूट करने के बाद दोनों दोहराएँ।
हाथ से जोड़े गए रूट और कभी सहेजे न गए अनुवाद साथ-साथ गायब हो जाते हैं। तब यह जोड़ी अधूरे काम के बजाय नई खराबी जैसी दिखती है।
जुड़ाव का मॉडल रूट, अनुमत निजी सेवा और किसी भी अनुवाद के साथ एक ही नोट में सहेजें। वही नोट अगले व्यक्ति को वायरलेस जगह को राउटिंग नीति का सवाल मानने से रोकता है।