एक LAN सबनेट OpenVPN मधून राउट करा आणि डीफॉल्ट ठेवा
एक सबनेट बोगद्यातून जात असताना LAN डीफॉल्ट ठेवा। पॉलिसी तक्त्याची मुख्य तक्त्यातील बदलांशी तुलना करा, नंतर NAT किंवा सर्व्हर-साइड मार्ग निवडा।
जे बॉक्स LAN साठी राउट करतात आणि त्याच वेळी VPN डायल करतात, ते स्वतःशी त्याच वादात अडकतात: बोगदा डीफॉल्ट मार्गाचा मालक व्हायचा आहे, आणि LAN ला तो परत हवा आहे। OpenVPN जोडल्यावर तो बोगद्यातून डीफॉल्ट किंवा दोन अर्धे-डीफॉल्ट बसवू शकतो, जे लॅपटॉपसाठी बरोबर आणि ज्याचे शेजारी त्याच्या LAN पत्त्यावरून उत्तरांची अपेक्षा करतात अशा गेटवेसाठी चूक आहे। उत्तर VPN वगळण्यात नाही। उत्तर दोन्ही निर्णयांना वेगवेगळे तक्ते देण्यात आहे।
एक डीफॉल्ट मार्ग, दोन मालक
फॉरवर्ड होणारा ट्रॅफिक आणि स्थानिक पातळीवर तयार होणारा ट्रॅफिक एकाच मार्गाने जायची गरज नाही। LAN क्लायंटना बोगदा फक्त तुम्ही निवडलेल्या गंतव्यांसाठी लागतो, तर होस्टच्या स्वतःच्या व्यवस्थापन सत्रांना आणि त्या क्लायंटना दिल्या जाणाऱ्या उत्तरांना LAN डीफॉल्ट लागतो। दोन्ही मुख्य तक्त्यात मिसळल्यास दोन वेगळ्या प्रश्नांवर एकच उत्तर लादले जाते।
OpenVPN मध्ये नेमका यासाठी एक स्विच आहे। route-noexec क्लायंटला मुख्य तक्त्याला अजिबात स्पर्श करू देत नाही, आणि तो वापरलेली असतील ती मूल्ये route-up स्क्रिप्टमध्ये route_vpn_gateway, dev आणि इंटरफेसचे पत्ते म्हणून निर्यात होतात। नंतर कोणते तक्ते कोणता मार्ग घेईल हे तुम्ही ठरवता, नंतर वाचता येणाऱ्या कोडमध्ये।
पॉलिसी तक्ता विरुद्ध मुख्य तक्ता पुनर्लेखन
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
वेगळा तक्ता हाच एकमेव पर्याय आहे जो एका सबनेटपुढे स्केल होतो। त्याला एकदा नाव द्या, नंतर नावानेच त्याचा उल्लेख करा जेणेकरून कोणालाही संख्या लक्षात ठेवावी लागणार नाही:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnयेथील पत्ते प्लेसहोल्डर आहेत। काहीही चालवण्यापूर्वी तुमच्या स्वतःच्या उपयोजनातून LAN प्रीफिक्स, बोगदा गेटवे आणि उपकरणाचे नाव बदला।
नियमाला होस्टशीही जुळणे आवश्यक आहे
फक्त LAN प्रीफिक्सशी जुळणारा नियम फॉरवर्ड झालेल्या पॅकेटना कव्हर करतो। तो गेटवे स्वतः तयार करणारा ट्रॅफिक कव्हर करत नाही, आणि LAN क्लायंटना परत पाठवल्या जाणाऱ्या उत्तराही कव्हर करत नाही, जी स्रोत म्हणून गेटवेचा LAN पत्ता वाहतात। त्या शोधण्या main मध्ये पडतात आणि तरीही बोगद्यातून बाहेर जाऊ शकतात।
गेटवेच्या स्वतःच्या LAN पत्त्यासाठी दुसरा नियम जोडा, किंवा पहिल्या नियमाला दोन्ही समाविष्ट करणाऱ्या संचापर्यंत रुंदावा। क्रम महत्त्वाचा आहे: अधिक विशिष्ट नियम आधी ठेवा, आणि स्रोत स्पष्टपणे नमूद करणाऱ्या शोधाने निकाल तपासा।
ip route get 203.0.113.9 from 192.168.50.1जर ते स्थानिक राहिले पाहिजे अशा गंतव्यासाठी बोगदा उपकरण दाखवते, तर तक्त्यात काय आहे याची पर्वा न करता नियमांचा संच चुकीचा आहे।
NAT किंवा पलिकडच्या बाजूला मार्ग
VPN सर्व्हरला बोगद्याचे सबनेट माहीत आहे आणि इतर काहीही नाही। LAN स्रोत पत्त्यासह येणाऱ्या पॅकेटना परतीचा मार्ग नसतो, जोपर्यंत कोणी तो पुरवत नाही, आणि तो पुरवण्याचे नेमके दोन मार्ग आहेत। सर्व्हरवर LAN प्रीफिक्ससाठी मार्ग जोडल्यास मूळ स्रोत टोकापासून टोकापर्यंत दिसत राहतो, जे ऑडिट केलेल्या रचनेला सहसा हवा असतो। गेटवेवर मास्करेड केल्यास स्रोत बोगद्याच्या पत्त्यावर पुन्हा लिहिला जातो आणि सर्व्हरच्या सहकार्याची गरज नसते।
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEसर्व्हर नियंत्रित नसल्यास आणि तेथे मार्ग जोडता येत नसल्यास NAT निवडा। लॉग, प्रवेश नियंत्रण किंवा परतीच्या मार्गाची सममिती महत्त्वाची असल्यास सर्व्हर-साइड मार्ग निवडा, कारण मास्करेड मूळ पत्ता पलिकडची बाजू नोंदवते त्या सर्वातून पुसून टाकतो।
दोन्ही बाबतीत फॉरवर्डिंग सक्षम असणे आवश्यक आहे, आणि कठोर रिव्हर्स-पाथ फिल्टरिंग उत्तर टाकू शकते जेव्हा main त्या स्रोतासाठी बोगदा निवडला नसता। बोगद्याला दोष देण्यापूर्वी प्रभावी मूल्य तपासा।
पुन्हा कनेक्ट झाल्यावरही विभाजन टिकून राहू द्या
हाताने जोडलेले नियम आणि मार्ग इंटरफेस पुन्हा तयार झाल्यावर नाहीसे होतात, आणि जुनी तक्ता नोंद तिला न्याय देणाऱ्या सत्रापेक्षा जास्त काळ टिकू शकते। तक्त्याचा नियम, बोगद्याचा मार्ग आणि मास्करेड नोंद क्लायंटच्या route-up स्क्रिप्टमध्ये ठेवा, आणि स्क्रिप्टच्या सुरुवातीला तक्ता रिकामा करा जेणेकरून जुना गेटवे नव्या सत्रात टिकू शकणार नाही।
दोन्ही टोकांकडून तपासा: गेटवेवर LAN स्रोतासह शोध, आणि LAN क्लायंटकडून बोगद्यातून जायला हव्या अशा गंतव्याकडे खरी विनंती। अस्तित्वात असूनही कधीही न निवडला जाणारा मार्ग, काउंटर वाचेपर्यंत मार्ग अजिबात नसल्यासारखाच वागतो।