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 प्रत्येकाला निर्णय हवा, अनुमान नाही।