OpenVPN मार्फत सार्वजनिक प्रिफिक्स: फर्कने बाटो सुधार्नुहोस्

टनेल माथि आउँदै र क्लाइन्ट अर्को छेउमा पिङ गर्दै गरेको हेर्नुहोस्, र त्यसपछि VPN पछाडि रहेको सार्वजनिक ठेगानाले अन्यत्रबाट जवाफ दिन्छ, वा बिल्कुलै दिँदैन। यो लक्षणको सामान्यतया साइफर वा प्रमाणपत्रसँग कुनै सम्बन्ध हुँदैन। प्रदायकले राउट गरेको प्रिफिक्स IP मार्गको रूपमा पुर्याइन्छ, र त्यसलाई OpenVPN मार्फत बोक्नु भन्नाले त्यो मार्ग दुई तहमा पुनः उत्पादन गर्नु र फर्कने बाटोमा स्रोत ठेगाना जोगाउनु हो। WAN ब्रिज गर्न आवश्यक छैन, र ठेगाना इन्टरफेसमा थप्दा माथिल्लो मार्ग बन्दैन।

प्रिफिक्स पहिले तपाईंतर्फ राउट हुनुपर्छ

ब्लक कसरी पुर्याइन्छ भनेर प्रदायकलाई सोध्नुहोस्। तपाईंको सर्भरको मुख्य ठेगानामा राउट गरिएको प्रिफिक्स प्रदायकले WAN खण्डमा सिधै पुग्न अपेक्षा गर्ने ठेगानाहरूभन्दा फरक कुरा हो। यहाँको डिजाइनसँग पहिलो मोडेल मात्र काम गर्छ।

यदि प्रदायकले 198.51.100.64/28 तपाईंको प्रवेश सर्भरमा राउट गर्छ भने, त्यो दायराका प्याकेट सर्भरमा आउँछन् र तपाईंले तिनलाई फर्वार्ड नगरेसम्म त्यहीँ रोकिन्छन्। यदि प्रदायकले त्यसको सट्टा दायरा तपाईंको अपलिङ्कमा ब्रिज गर्छ भने, सर्भरले त्यसका लागि ARP को जवाफ दिनुपर्छ, जुन अर्को समस्या हो।

OpenVPN छुनुअघि डेलिभरी मोडेल परीक्षण गर्नुहोस्: बाहिरबाट ब्लकको कुनै ठेगानामा पिङ गर्नुहोस् र कुन इन्टरफेसले त्यो स्वीकार्छ हेर्नुहोस्। केही पनि आएन भने कुनै पनि टनेल कन्फिगरेसनले मद्दत गर्दैन। यदि ठेगानाले WAN मा सिधै जवाफ दिन्छ भने, प्रदायक राउट गर्नुको सट्टा ब्रिज गर्दैछ, र तलको डिजाइन लागू हुँदैन।

दुई राउटिङ तह: कर्नेल मार्ग र iroute

OpenVPN लाई प्रिफिक्स दुई ठाउँमा चाहिन्छ। कर्नेललाई थाहा हुनुपर्छ कि प्रिफिक्स टनेल उपकरणको हो, ताकि फर्वार्ड गरिएका प्याकेट डिफल्ट मार्गको सट्टा OpenVPN मा प्रवेश गर्नेछन्। OpenVPN लाई पनि थाहा हुनुपर्छ कुन प्रमाणित क्लाइन्ट प्रिफिक्सको मालिक हो, र त्यो क्लाइन्ट-विशेष डाइरेक्टरीमा iroute प्रविष्टि हो।

सर्भर-पक्षको मार्ग यस्तो देखिन्छ, जसमा प्रिफिक्स र मास्क बाँडफाँटसँग मिल्नुपर्छ:

ip route add 198.51.100.64/28 dev tun0

क्लाइन्ट-विशेष कन्फिगरेसनले स्वामित्व तोक्छ। यसलाई क्लाइन्ट प्रमाणपत्रको सामान्य नाममा नामाकरण गरिएको CCD फाइलमा राख्नुहोस्, र सर्भरले वास्तवमै त्यही डाइरेक्टरी पढ्छ भन्ने सुनिश्चित गर्नुहोस्:

iroute 198.51.100.64 255.255.255.240

OpenVPN को राउट गरिएका नेटवर्कसम्बन्धी कागजात ले दुवै तह र ती किन अलग छन् वर्णन गर्छ। iroute बिनाको कर्नेल मार्गले प्याकेटहरू मालिक बिनै टनेलमा पठाउँछ, र OpenVPN ले तिनलाई फाल्छ। कर्नेल मार्ग बिनाको iroute ले प्याकेटहरू सर्भरको डिफल्ट मार्गमा छोड्छ। दुवै गल्ती क्लाइन्टको तर्फबाट टुटेको टनेलजस्तो देखिन्छ।

सेवा ठेगाना कहाँ बस्छ

डेलिगेट गरिएको प्रिफिक्स टनेलका आफ्नै ठेगानाहरू जस्तो होइन। चाहनुहुन्छ भने लिङ्कलाई निजी ठाउँबाट नम्बर गर्नुहोस्, र सार्वजनिक सेवा ठेगाना सेवा वास्तवमै चल्ने ठाउँमा राख्नुहोस्।

सेवा स्थानीय रूपमा अन्त्य गर्ने Linux क्लाइन्टमा एउटा होस्ट ठेगाना पर्याप्त छ:

ip address add 198.51.100.70/32 dev lo

यदि प्रिफिक्स अगाडि VM होस्ट वा अर्को LAN मा राउट हुन्छ भने, त्यसको सट्टा त्यो डाउनस्ट्रिम मार्ग र त्यसको फर्कने मार्ग कन्फिगर गर्नुहोस्। ब्लकको हरेक ठेगाना VPN क्लाइन्टलाई दिनु आवश्यक छैन र पछि द्वन्द्व सिर्जना गर्छ।

फर्कने बाटोमा सार्वजनिक स्रोत राख्नुहोस्

डेलिगेट गरिएको प्रिफिक्सबाट जवाफ टनेलबाट बाहिर निस्केर प्रदायकको मार्गसम्म पुग्नुपर्छ। यदि टाढाको होस्टले यसलाई आफ्नै ISP मार्फत पठाउँछ भने, स्रोत ठेगाना नक्कली देखिन्छ, र प्रदायक वा गन्तव्यले त्यसलाई फाल्छ। समाधान हो स्रोत-आधारित नियम वा समर्पित राउटिङ तालिका, अझ फराकिलो NAT होइन। त्यो बिना सेवा टनेल साथीबाट काम गर्छ र बाँकी सबै ठाउँबाट असफल हुन्छ।

प्रवेश सर्भरमा फराकिलो masquerade नियम सामान्य दोषी हो। यसले सार्वजनिक स्रोतलाई सर्भरको मुख्य ठेगानामा पुनः लेख्छ, र क्लाइन्टले वास्तविक कहिल्यै देख्दैन:

iptables -t nat -S POSTROUTING

NAT लाई आवश्यक पर्ने निजी VPN क्लाइन्टहरूमा मात्र सीमित गर्नुहोस् र डेलिगेट गरिएको प्रिफिक्स अनुवाद नगरी छोड्नुहोस्। त्यसपछि सर्भरले प्रिफिक्स कतै फर्वार्ड गर्छ कि भनेर सुनिश्चित गर्नुहोस्, किनकि डिफल्ट-अस्वीकृति फर्वार्ड चेनले त्यसलाई चुपचाप फाल्छ।

विश्वास गर्नुअघि दुवै दिशा जाँच्नुहोस्

प्रमाणीकरण एक होइन, चार अवलोकन हुन्। प्रदायकको मार्ग आउँछ, कर्नेलले प्रिफिक्स टनेलमा पठाउँछ, OpenVPN ले त्यसलाई सही क्लाइन्टमा तोक्छ, र जवाफ सार्वजनिक स्रोतसहित सुरक्षित फर्कन्छ भन्ने सुनिश्चित गर्नुहोस्। हरेक अवलोकनको आफ्नै आदेश हुन्छ, त्यसैले असफलताले पूरै डिजाइनको सट्टा एउटा तहतर्फ संकेत गर्छ। हरेक कन्फिगरेसन परिवर्तनपछि ती त्यही क्रममा चलाउनुहोस्।

कर्नेललाई सोध्नुहोस् कि डेलिगेट गरिएको ठेगानाले कुन मार्ग लिन्छ, र अनुरोध चलिरहेको बेला टनेल हेर्नुहोस्:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

रिभर्स-पाथ फिल्टरिङले सही मार्ग रद्द गर्न सक्छ। टनेलमा र अपलिङ्कमा प्रभावकारी सेटिङ जाँच्नुहोस्, र सम्झनुहोस् कि कडा मोडले त्यो ट्राफिक अस्वीकार गर्छ जसको स्रोत आएको इन्टरफेससँग मिल्दैन:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

अन्तमा, असफलताको अवस्था परीक्षण गर्नुहोस्। टनेल रोक्नुहोस् र सार्वजनिक प्रिफिक्स सामान्य अपलिङ्कबाट चुहावट नभएको सुनिश्चित गर्नुहोस्। VPN पुनर्स्थापना गर्दा होस्टले खोल्ने पोर्टहरू नबढाई सेवा फर्कनुपर्छ।