दोन OpenVPN सर्व्हरवरील क्लायंट एकमेकांपर्यंत पोहोचू शकतात का?

दुसरा OpenVPN सर्व्हर उभा करणे म्हणजे क्लायंटना जोडण्यासाठी दुसरे ठिकाण मिळणे, इतकेच. ते त्या क्लायंटना पहिल्या सर्व्हरच्या नेटवर्कवर आणत नाही, आणि client-to-client नावाचा पर्याय फक्त एका सर्व्हर प्रक्रियेतील फॉरवर्डिंग बदलतो. दोन्ही पूल एक नेटवर्क तेव्हाच बनतात जेव्हा तुम्ही जाणीवपूर्वक त्यांच्यामध्ये राउटिंग करता, प्रत्येक दिशेसाठी एक मालक निश्चित करून. खालील सर्व गोष्टी वापरकर्ता-स्पेस TUN मोड गृहीत धरतात, ज्यात ते अंतर्गत फॉरवर्डिंग बंद असते, त्यामुळे निर्णय कर्नेल घेते.

गैरसमज: एक खाते यादी, एक नेटवर्क

प्रमाणीकरण आणि पोहोचक्षमता यांना एकत्र मिसळले जाते कारण दोन्ही सर्व्हर कॉन्फिगरेशनमध्ये असतात. दोनपैकी कोणत्याही गेटवेवर लॉग इन करू शकणारा वापरकर्ता बाहेरून दोन दरवाजे असलेल्या एका सिस्टमवरील वापरकर्ता वाटतो. आत मात्र प्रत्येक सर्व्हर स्वतःच्या पूलमधून पत्ते देतो आणि फक्त आपण संपवलेल्या क्लायंटसाठी मार्ग बसवतो. त्यामुळे गेटवे A वरचा क्लायंट गेटवे B वरच्या क्लायंटला पॅकेट पाठवतो तेव्हा तो अशा गंतव्याची मागणी करत असतो ज्याचे स्वतःच्या सर्व्हरने कधीच ऐकले नाही. ते पॅकेट A च्या डीफॉल्ट मार्गावर जाते, बोगद्याबाहेर पडते आणि अशा फायरवॉलकडे पोहोचते ज्याला ते परवानगी देण्यास कधीच सांगितले नव्हते.

म्हणून दुसरा सर्व्हर जोडल्याने रिडंडंसी, डिस्कव्हरी किंवा सामायिक ब्रॉडकास्ट डोमेन जोडला जात नाही. त्याऐवजी नियोजन आवश्यक असलेले राउटेड नेटवर्क जोडले जाते, आणि ते नियोजन पत्ता-नियोजनापासून सुरू होते.

प्रत्येक गेटवेला स्वतःचा पूल आणि ट्रान्झिट पत्ता द्या

इतर कोणत्याही गोष्टीशी ओव्हरलॅप होऊ न शकणार्या दोन श्रेणी, आणि होस्ट्समधील एक छोटा ट्रान्झिट लिंक, हाच संपूर्ण पत्ता आराखडा. ट्रान्झिट तुमच्या नियंत्रणातील खाजगी विभागावर ठेवा, आणि कोणताही सर्व्हर लीज देण्यापूर्वी ते आकडे लिहून ठेवा.

दोन्ही सर्व्हरना एकच पूल देऊन प्रोफाइल्स सारखीच राहतील अशा मोहाला बळी पडू नका. सामायिक श्रेणीतील अनियंत्रित पत्ता सध्या दोनपैकी कोणत्या होस्टकडे आहे हे कर्नेल मार्ग सांगू शकत नाही, त्यामुळे राउटिंग टेबल एका गेटवेकडे दाखवेल आणि क्लायंट दुसर्याशी जोडलेला असू शकतो. इंटरफेस नावे स्थानिक परंपरा आहेत, सामायिक स्थिती नाही. येथे दोन्ही होस्ट बोगदा उपकरणाला tun0 आणि ट्रान्झिट लिंकला transit0 म्हणतात, जे ठीक आहे कारण कोणतेही पॅकेट ती नावे वाहत नाही.

दोन्ही बाजूंना मार्ग बसवा

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

पूलांची अदलाबदल करून दुसर्या होस्टवर तेच मिरर करा. असंबंधित स्क्रिप्टमधून तोच मार्ग वारंवार जोडणे म्हणजे होस्टकडे अनेक प्रती आणि पुढच्या वेळी कोणी टेबल वाचले की रहस्यमय बदल असणे. ट्रान्झिट लिंक स्वतः बोगदा असेल, तर मार्ग त्या बोगद्याच्या टोपोलॉजीकडे दाखवतो आणि तो हॉप त्याच्या पुन्हा-कनेक्शननंतर टिकला पाहिजे. तीस सेकंदांसाठी गायब होणारा ट्रान्झिट पत्ता पूलांतर मार्ग आपल्यासोबत घेऊन जातो, हा शोधण्याऐवजी सांगण्यासारखा डिझाइन गुणधर्म आहे.

मालकीचे नाटक न करता क्लायंट मार्ग ढकला

क्लायंटना दूरच्या पूलसाठी मार्ग आवश्यक आहे, नाहीतर त्यांची स्वतःची ऑपरेटिंग सिस्टम पॅकेट त्यांच्या डीफॉल्ट गेटवेकडे पाठवते आणि बोगद्याला ते कधीच दिसत नाही. ते पोहोचवण्यासाठी सर्व्हर कॉन्फिगरेशन ही नैसर्गिक जागा आहे.

push "route 10.64.20.0 255.255.255.0"

दुसर्या सर्व्हरच्या कॉन्फिगरेशनमध्ये मिरर ओळ ठेवा, नंतर चाचणी क्लायंट पुन्हा जोडा आणि त्याचे टेबल वाचा. ढकललेल्या मार्गांकडे दुर्लक्ष करणार्या क्लायंटला स्वतःचे मंजूर कॉन्फिगरेशन लागते, आणि कधीही न येणारा मार्ग हा प्रवेश नियंत्रण नाही. दुसर्या गेटवेच्या संपूर्ण पूलसाठी क्लायंटला iroute देऊ नका. ती सूचना एका जोडलेल्या क्लायंटमागील सबनेटसाठी आहे, आणि गेटवे-दरम्यानचा गहाळ मार्ग झाकण्यासाठी तिचा वापर केल्यास आपण पोहोचू शकत नाही अशा पत्त्यांची मालकी असल्याचे मानणारा सर्व्हर तयार होतो.

एक विनंती सिद्ध करा आणि दुसरी नाकारा

एक खरे ऑपरेशन निवडा, उदाहरणार्थ 10.64.10.21 वरच्या क्लायंटकडून 10.64.20.37 वरच्या सेवेकडे HTTPS, आणि दोन्ही होस्टवर नेमके तेच परवानगी द्या. प्रत्येक फायरवॉल आपल्या इनबाउंड बाजूला विनंती आणि परतीच्या बाजूला ट्रॅक केलेले उत्तर स्वीकारतो; गंतव्याचे स्वतःचे सेवा धोरण ते अजूनही स्वीकारले पाहिजे.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

परस्पर मार्ग असताना स्रोत NAT अनावश्यक आणि येथे सक्रियपणे हानिकारक आहे: स्रोताचे भाषांतर केल्याने विनंती कोणत्या क्लायंटने केली हे लपते आणि गंतव्य बाजूचे स्रोत-आधारित धोरण विफल होते. इंटरनेट इग्रेससाठीचा विद्यमान मास्करेद नियम हा मार्गही पकडत नाही याची खात्री करा. नंतर नकाराची चाचणी करा. पूल B मध्ये स्थानिक राहिली पाहिजे अशी सेवा पूल A मधून पोहोचण्यायोग्य राहू नये, आणि एकाच गेटवेवरील क्लायंट जोड्यांचीही चाचणी करा, कारण तुम्ही आत्ता बदललेले फॉरवर्डिंग धोरण त्यांनाही लागू होते.

मानसिक मॉडेलमध्ये आणखी एक दुरुस्ती: ट्रान्झिट लिंक डिक्रिप्ट केलेले आंतरिक पॅकेट वाहते, म्हणून ती खाजगी हमी नसून विश्वास सीमा आहे. ती तुमच्या नियंत्रणाबाहेरील नेटवर्क ओलांडत असेल, तर त्या हॉपला मंजूर एन्क्रिप्टेड बोगद्याने संरक्षित करा आणि त्याच्या खर्या टोपोलॉजीमधून राउट करा. एंड-टू-एंड TLS अजूनही ॲप्लिकेशनचे स्वतःचे प्रमाणीकरण करते, म्हणूनच आंतरिक सेवेने ते वापरत राहावे.