एकाच Linux होस्टवर दोन OpenVPN बोगदे: मार्ग कोणाचा?

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

दुसऱ्या लिंकने करायच्या कामापासून सुरुवात करा

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

आच्छादणारे पूल राउटिंगपूर्वीच तुटतात

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

स्थानिक LAN देखील पहा। एक बोगदा उघड करणारे 192.168.1.0/24 क्रमांकाचे घरगुती LAN तीच अस्पष्टता निर्माण करते, आणि लक्षण म्हणजे जोडणी कधीही पूर्ण न होता सुटणारे होस्टनाव। मार्ग छापेपर्यंत ते नाव-निराकरण बिघाडासारखे दिसते।

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

क्लायंटला स्पर्श करण्यापूर्वी दोन्ही आउटपुट दोन सर्व्हर संरचनांशी तुलना करा। प्रीफिक्स एकमेकांवर आच्छादत असतील, तर थांबा आणि पुन्हा क्रमांकित करा, कारण कितीही रीस्टार्ट केले तरी ते विभक्त होणार नाहीत।

प्रत्येक प्रोफाइलला त्याचे युनिट आणि प्रत्येक प्रीफिक्सला मालक द्या

प्रत्येक प्रोफाइलला स्वतःचे इन्स्टन्स नाव आणि स्वतःची संरचना फाइल मिळते, त्यामुळे office नावाचे इन्स्टन्स office.conf लोड करते, तर lab नावाचे lab.conf लोड करते। डिरेक्टरी यादीवर विश्वास ठेवण्याऐवजी सेवा मॅनेजरमार्फत ते मॅपिंग पुष्टी करा, कारण drop-in कोणती फाइल लोड होते ते बदलू शकते। मॅपिंग चुकल्यास तुम्ही न चालणारे प्रोफाइल ट्यून करत आहात।

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

मार्क उत्तरे ज्या इंटरफेसवरून आली तिथेच ठेवतात

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

दुसरा जोडण्यापूर्वी विद्यमान नियम वाचा। दुहेरी प्राधान्ये आणि विसरलेले तक्ते हे मार्क धोरणाला अजिबात परिणाम होत नसल्यासारखे वाटण्याचे नेहमीचे कारण आहे।

एक लिंक थांबवून अलगीकरण सिद्ध करा

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

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

थांबवलेले प्रोफाइल परत आणा आणि तीच तपासणी पुन्हा करा। रीबूटनंतर फक्त पहिल्या सुरुवातीला बोगदा टिकत असेल, तर तुम्ही राउटिंग रचना नाही तर जीवनचक्र दोष पाहत आहात।