दुई 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 ले अझै आफैं एप्लिकेसन प्रमाणित गर्छ, त्यसैले आन्तरिक सेवाले त्यो प्रयोग गरिरहनुपर्छ।