एका Linux गेटवेवर दोन OpenVPN क्लायंट: धोरण विभागा

दोन OpenVPN डीमन दोन्ही यशस्वी टनेलची नोंद देऊ शकतात, पण गेटवे प्रत्येक क्लायंटला त्याच एकातून पाठवतो। क्लायंट कोणते टनेल वापरतो हे हातमिळवणीत काहीही ठरवत नाही; ते कर्नल ठरवते, पॅकेटमागे पॅकेट, धोरणाच्या नियमांतून आणि नंतर प्रत्येक नियम ज्या तक्त्याचे नाव देतो त्यातून जात। असे पाहिल्यावर संरचना OpenVPN पर्यायांबद्दल राहत नाही आणि दोन मालक असलेली राउटिंग मॅट्रिक्स होते।

कर्नल ठरवते, डीमन नाही

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

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

प्रत्येक प्रतीला तिचा स्वतःचा संसाधनसंच द्या

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull सर्व्हरने ढकललेले मार्ग स्थानिक तक्त्याबाहेर ठेवतो, आणि धोरणाचे तक्ते स्पष्ट असावेत तेव्हा तुम्हाला हेच हवे असते। दिलेला सर्व्हर redirect-gateway पर्यायही ढकलतो का आणि तुमची क्लायंट आवृत्ती गाळणीचा आकार स्वीकारते का, हे गृहीत धरण्याऐवजी हस्तपुस्तिकेत तपासण्यासारखे आहे।

मॅट्रिक्स लिहा: स्रोत, तक्ता, उपकरण

प्रत्येक क्लायंट गटासाठी, स्रोत पत्त्याने तक्ता निवडणारा नियम जोडा, मग इच्छित मार्ग त्या तक्त्यात ठेवा:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

टनेलची स्वतःची वाहतूक क्लायंट गटात नाही

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

स्थानिक व्यवस्थापन सत्र आणि अधःस्तराचा मार्ग धोरणाच्या तक्त्यांबाहेर स्पष्ट ठेवा। ते अपवाद मॅट्रिक्सच्या शेजारी लिहा; ते रचनेचा भाग आहेत, घटनेच्या वेळी पुन्हा शोधायचा उपाय नाही।

मार्ग निवडणे त्याला परवानगी देत नाही

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

स्रोत भाषांतर हा तिसरा निर्णय आहे, आणि तो स्रोत गटापर्यंत आणि ती खरोखर वाहणाऱ्या टनेल उपकरणापर्यंत मर्यादित असावा। दोन प्रतींसाठी समर्पित शृंखला जोडा, postrouting शृंखला रिकामी करण्याऐवजी, कारण असंबंधित सेवांच्या तिथे नोंदी असू शकतात आणि रिकामे करणे त्या शांतपणे काढून टाकते।

एक टनेल पडल्यावर काय होते

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

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