मल्टी-राउटर 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 ला एक नाही तर दोन नोंदी लागतात, आणि परत जाण्याचा मार्ग हाच लोक विसरतात। पुढे पाठवलेला ट्राफिक खाजगी नेटवर्कपर्यंत बरोबर पोहोचतो आणि नंतर परतीच्या मार्गावर मरतो, कारण 10.41.0.0/24 कुठे राहतो हे Pi ला माहीत नाही। ते फायरवॉलची समस्या वाटते आणि प्रत्यक्षात गहाळ रूट आहे।
दूरच्या बाजूला देखील स्वतःचा रूट लागतो। जर दूरच्या टोकावरील सेवेला माहीत नसेल की 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 वरील वायर्ड क्लायंटकडून दुसरी चाचणी जोडा जेणेकरून दोन्ही मार्गांची तुलना होईल। कोणतेही डिव्हाइस रीबूट केल्यानंतर दोन्ही पुन्हा करा।
हाताने जोडलेले रूट आणि कधीही जतन न केलेले भाषांतर एकत्र गायब होतात। मग ती जोडी अपूर्ण कामाऐवजी नवीन बिघाड वाटते।
जोडणीचे मॉडेल रूट, परवानगी असलेली खाजगी सेवा आणि कोणत्याही भाषांतरासह एका टिपेत जतन करा। तीच टीप पुढच्या व्यक्तीला वायरलेस जागा हा राउटिंग धोरणाचा प्रश्न समजण्यापासून रोखते।