OpenWrt वर संपूर्ण LAN साठी OpenVPN क्लायंट: काम करणारा क्रम

राउटरचे संपूर्ण LAN एका बोगद्यामागे आणण्यासाठी चार स्वतंत्र कामे लागतात। बोगदा उपकरणाला एक मालक, एक फायरवॉल झोन, अपलिंककडे जाणारे भाषांतर लक्ष्य आणि काही क्लायंट VPN बाहेर ठेवायचे असतील तर स्रोत पत्त्यानुसार राउटिंग लागते। जोडला जातो पण काहीही जात नाही असा बोगदा सहसा या चारपैकी एक गहाळ असल्याचे दर्शवतो। अवलंबित्वाच्या क्रमाने काम केल्याचा अर्थ शेवटी येणारे अपयश नुकत्याच बदललेल्या टप्प्याचे असते। खालील प्रत्येक टप्पा दिसू शकणाऱ्या गोष्टीने संपतो, त्यामुळे पुढचा टप्पा अंदाज बनत नाही।

बोगदा काय वाटून घेईल ते ठरवा

Wi-Fi आणि DHCP देणारा राउटर स्वतः क्लायंट चालवू शकतो। त्यामुळे प्रत्येक उपकरणासाठी वेगळी सेटिंग न करता सर्व जोडलेली उपकरणे बोगद्यामागे येतात, आणि लहान ठिकाणांना हीच रचना हवी असते। बोगदा कोसळल्यास सर्वात मोठा परिणामही याच रचनेत होतो, कारण सर्व उपकरणे एकाच वेळी त्यांचा मार्ग गमावतात। LAN वर बाहेर जाणारा कार्यरत मार्ग काहीच राहत नाही।

पहिल्यामागे दुसरा राउटर, स्वतःच्या सबनेटसह क्लायंट चालवतो, बोगदा फक्त त्याच्या उपकरणांपुरता मर्यादित ठेवतो। तो काढणे आणि ज्याला तो वारसा मिळेल त्याला समजावणे सोपे असते। किंमत म्हणजे मार्ग किंवा पोर्ट फॉरवर्डशिवाय दोन्ही बाजूंमध्ये पोहोच नसते।

कोणत्याही प्रकारे, LAN सबनेट वेगवेगळे ठेवा। सारख्याच श्रेणी एक बाजू थेट जोडलेली दिसते, आणि त्यातून तयार होणारा काळा छिद्र VPN च्या बिघाडासारखा वाटतो तासन्तास।

बोगद्याला मालक द्या

बोगदा नाव, उपकरण आणि स्वतःचा प्रोटोकॉल नसलेला नेटवर्क इंटरफ़ेस म्हणून जाहीर करा। त्यानंतर नेटवर्क प्रणाली उपकरण तयार करते व सांभाळते, आणि पुढील सर्व इंटरफ़ेसला उपकरणाने नव्हे तर नावाने संदर्भित करते। त्यामुळेच झोनला तो सापडतो।

एकच उपकरण दोन ठिकाणी तयार करू नका। जाहीर केलेल्या इंटरफ़ेसच्या शेजारी हाताने बनवलेला बोगदा असल्यास अस्तित्वात असलेले पण झोनमध्ये नसलेले उपकरण तयार होते, किंवा रीलोडवर नाहीसे होणारे उपकरण। दोन्ही क्लायंट अपयशी झाल्यासारखे दिसतात, आणि दोन्ही खरे कारण सांगणारी त्रुटी देत नाहीत। घोषणात्मक मार्ग निवडा आणि हाताने केलेला काढून टाका।

नेटवर्क, फायरवॉल आणि VPN संरचनेत नाव एकसारखे ठेवा। झोन नेटवर्क नावाने सूचीबद्ध करतो, त्यामुळे एक टायपिंग चूक बोगद्याला प्रत्येक झोनबाहेर ठेवते आणि इंटरफ़ेस स्वतः निरोगी दिसतो। धोरण नसलेला निरोगी इंटरफ़ेस शोधणे सर्वात कठीण असते।

झोन करा, मग त्यात फॉरवर्ड करा

फायरवॉल झोन म्हणजे धोरण राहते ते ठिकाण: इनपुट, आउटपुट, फॉरवर्ड आणि मास्करेड। कोणत्याही झोनमध्ये नसलेला बोगदा तुम्ही न निवडलेल्या डीफॉल्टद्वारे चालतो, आणि राउटर क्लायंटला ते क्वचितच लागते। खालील स्टॅन्झा इंटरफ़ेस जाहीर करतात, तो झोनमध्ये ठेवतात आणि LAN रहदारीला त्या झोनमध्ये जाऊ देतात।

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

21.02 पेक्षा जुन्या प्रकाशनांमध्ये तीच इंटरफ़ेस ओळ option ifname अशी लिहिली जाते, म्हणून पेस्ट करण्यापूर्वी बसवलेले फर्मवेअर कोणता आकार वाचते ते तपासा। फॉरवर्डिंग स्टॅन्झा म्हणजे LAN रहदारीला बोगदा वापरण्याची परवानगी। त्याशिवाय उपकरण सुरू आहे, क्लायंट जोडलेला आहे, आणि कोणतेही LAN होस्ट बोगद्यापर्यंत पोहोचत नाही। राउटर क्लायंटवरील सर्वात सामान्य तक्रार जोडलेले पण इंटरनेट नाही हीच आहे।

VPN झोनवरील मास्करेड पॅकेट बाहेर पडण्यापूर्वी प्रत्येक LAN पत्ता राउटरच्या बोगदा पत्त्यात आवळतो। त्यामुळे पलीकडे तुमच्या सबनेटपर्यंत परतीच्या मार्गाची गरज संपते।

पलीकडे आधीच तुमच्या LAN ला मार्ग देत असेल, तर मास्करेड बंद केल्यास स्रोत पत्ते दिसत राहतात आणि प्रत्येक क्लायंटचे लॉग अर्थपूर्ण होतात। एक निवडा आणि कोणता निवडला ते लिहून ठेवा, कारण दोन्ही पर्याय पुढे वेगळे सहाय्य प्रश्न निर्माण करतात। डीफॉल्ट LAN-ते-WAN फॉरवर्डिंग काढणे हे स्वतःच्या परिणामासह वेगळे निर्णय आहे। ते काढले तर राउटरचे स्वतःचे इंटरनेट प्रवेशही सोबत जाते।

NAT मध्ये खरा अपलिंक नावाने नमूद करा

भाषांतर नियम हाताने लिहितात त्या फर्मवेअरमध्ये बाहेर जाणारा इंटरफ़ेस हेच बिघडणारे क्षेत्र। नियम vlan2 असे नाव दिले तरी सत्र ppp0 वर संपल्यास काहीही करत नाही। इंटरफ़ेस अजिबात नसलेला नियम खाजगी राहायला हवी अशी रहदारीही भाषांतरित करू शकतो। दोन्ही चुका स्वतःची घोषणा करत नाहीत, कारण बोगदा काम करत राहतो।

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

त्या नियमातील ppp0 हा ip route किंवा चालू इंटरफ़ेस यादीतील इंटरफ़ेसने बदला, मग LAN होस्ट पान लोड करत असताना काउंटर पहा। एकाच पुरवठादाराच्या राउटरवर अपलिंकसाठी एक मास्करेड नियम सहसा पुरतो। बोगदा इंटरफ़ेससाठीचा दुसरा नियम पहिल्याचा पर्याय नाही।

मग बोगद्यात काय प्रवेश करते हे ठरवणारे क्लायंट पर्याय जोडा। redirect-gateway सूचना क्लायंटची इंटरनेट रहदारी VPN मधून पाठवते, आणि त्याशिवाय बोगदा सर्व्हर ढकलत असलेले मार्गच वाहतो। DNS ला हात लावण्यापूर्वी तयार झालेला मार्ग तक्ता तपासा।

दुसऱ्या तक्त्याने Wi-Fi विभागा

एक राउटिंग तक्ता दोन डीफॉल्ट ठेवू शकत नाही। म्हणून बोगदा टाळायचा असलेल्या दुसऱ्या SSID ला स्वतःचे सबनेट आणि स्वतःचा तक्ता लागतो। बोगद्यातील SSID ला स्वतःची श्रेणी द्या, मग तक्ता निवडणाऱ्या नियमाने फक्त ती श्रेणी बोगद्यात पाठवा।

OpenWrt वरील धोरण-राउटिंग पॅकेजेस नेमका तोच संयोग व्यक्त करतात। हातानेही करता येते — स्रोत नियम आणि डीफॉल्ट बोगदा उपकरणाकडे दाखवणारा तक्ता वापरून।

दोन्ही नेटवर्कमधून विभागणी तपासा। बोगद्यातील SSID वरील क्लायंटने VPN चा निर्गम पत्ता दाखवावा, आणि सामान्य SSID वरील क्लायंटने पुरवठादाराचा। दोन्ही सारखे दिसल्यास नियम चुकीच्या स्रोताशी जुळतो किंवा तक्ता अजिबात पाहिला जात नाही। पुन्हा जोडल्यावरही चाचणी करा, कारण इंटरफ़ेस नावावर अवलंबून असलेला नियम उपकरणाचा क्रमांक बदलल्यावर तुटतो।

घड्याळ आणि उपकरण ध्वजावर संशय घ्या

हा persist-tun ध्वज पुन्हा सुरू करण्यांमध्ये बोगदा उपकरण जागच्या जागी ठेवतो। ते सर्व्हरला अनुकूल असते आणि स्थिती सुरुवातीपासून पुन्हा बांधायची असलेल्या क्लायंटला गोंधळवते। राउटर क्लायंटची समस्या सोडवताना तो काढा, कारण अपयशी वाटाघाटीतून टिकलेले उपकरण कोणता टप्पा खरोखर तुटला हे लपवते। क्लायंट विश्वासार्हपणे जोडल्यावरच तो परत ठेवा, त्यापूर्वी नाही।

घड्याळ हे दुसरे शांत अपयश आहे। बॅटरी घड्याळ नसलेला राउटर युगाच्या सुरुवातीपासून सुरू होतो, म्हणजे NTP येईपर्यंत प्रमाणपत्र तपासण्या अपयशी होतात। प्रमाणपत्राला हात लावण्यापूर्वी लॉगमधील वेळा खऱ्या वेळाशी तुलना करा, कारण बूटनंतर एका मिनिटाने जोडणारा क्लायंट सहसा वेळ समक्रमणाची वाट पाहत असतो।