एउटा OpenVPN पोर्ट, तीन सेवा: भित्री पोर्ट किन महत्त्वपूर्ण छन्

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

बाह्य प्रवाहले के बोक्छ, र के लुकाउँछ

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

त्यसैले WAN इन्टरफेसमा गरिएको क्याप्चरले तीन होइन, एउटा संवाद देखाउँछ। भित्री पोर्ट डिक्याप्सुलेसनपछि मात्र देखिन्छन्। त्यसैले एउटा फायरवाल प्वालले SSH, HTTPS र DNS एकै समयमा बोक्न सक्छ।

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP कागजात ले मार्गनिर्देशित TUN यन्त्रले कर्नेल र प्रयोगकर्ता स्पेस प्रक्रियाबीच IP प्याकेट हस्तान्तरण गर्ने हस्तान्तरणको वर्णन गर्छ। त्यही हस्तान्तरणले भित्री हेडर गेटवेको मार्गनिर्देशन र फायरवाल कोडलाई देखिने बनाउँछ। साथै बाह्य पोर्टले कुन सेवा अनुमति छन् भन्नेबारे केही नभन्नुको कारण पनि व्याख्या गर्छ।

NAT फर्वार्ड सुन्नेको हो, अनुप्रयोगको होइन

IPv4 NAT पछाडिको स्व-होस्ट गरिएको गेटवेलाई एउटा आगमन अनुवाद चाहिन्छ: सार्वजनिक ठेगाना र पोर्ट VPN सुन्नेमा म्याप गरिन्छ। सुरुङ प्रयोगकर्ताले पुग्छन् भनेर SSH, HTTPS वा DNS का लागि कुनै नियम आवश्यक हुँदैन। ती पोर्ट प्रकाशित गर्दा सुरुङले पहिले नै सुरक्षित गरेका सेवा खुला हुन्छन्। फर्वार्डिङ नियमले सुन्नेको पहुँचयोग्यता वर्णन गर्छ, भित्रको कुनै कुराको अनुमति होइन।

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

पहुँच वास्तवमा भित्री नीतिमा निर्णय हुन्छ

इन्क्रिप्सनले बाटो सुरक्षित गर्छ; यसले गन्तव्यलाई अधिकार दिँदैन। कुन प्रिफिक्स सुरुङभित्र पस्छन् क्लाइन्ट मार्गले छान्छ, प्याकेट त्यसबाट बाहिर जान सक्छन् कि भनेर गेटवे फर्वार्डिङ नीतिले निर्णय गर्छ, र सेवाले जवाफ दिन्छ कि भनेर गन्तव्यको फायरवाल र लगइनले निर्णय गर्छ। DNS सबैभन्दा स्पष्ट उदाहरण हो: प्रश्न बोक्दैमा रिजोल्भरले तिनीहरूलाई तपाईंको क्लाइन्ट पूलबाट स्वीकार गर्दैन। प्रत्येक तहले स्वतन्त्र रूपमा नाइँ भन्न सक्छ।

सुरुङमार्फत प्रत्येक सेवा छुट्टै परीक्षण गर्नुहोस्। सफल खोजीले वेब पोर्टबारे केही भन्दैन, र सफल वेब अनुरोधले SSH बारे केही भन्दैन।

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

सुरुङ चालु छ र सबै असफल हुन्छ भने पहिले क्लाइन्टको मार्ग तालिका पढ्नुहोस्। एउटा सेवा असफल हुँदा अरू चलिरहेका छन् भने त्रुटि त्यही गन्तव्यमा छ। यी दुई अवलोकनले फरक जिम्मेवारतर्फ संकेत गर्छन्, र तिनलाई मिसाउँदा समय बर्बाद हुन्छ।

WireGuard ले पनि त्यही रेखा तान्छ

WireGuard ले आफ्नो बाह्य सुन्नेलाई ListenPort भनेर नाम दिन्छ, र भित्री अनुप्रयोगले अझै आफूलाई चाहिने सेवा पोर्ट प्रयोग गर्छ। AllowedIPs मार्गनिर्देशित प्रिफिक्सहरूको समूह हो, अनुमति दिइएका सेवा पोर्टहरूको सूची होइन। यसलाई पोर्ट अनुमति सूचीका रूपमा पढ्दा सुरुङले गर्ने कुरासँग नमिल्ने नियम बन्छन्। नामकरण फरक छ; तहगत बनावट फरक छैन।

सेवा होस्टमै चल्छ भने स्थानीय इनपुट नीतिमा, वा त्यो होस्टको पछाडि छ भने फर्वार्डिङ नीतिमा अनुमति दिनुहोस्। यही भिन्नताले कुन नियम समूहले प्याकेट देख्छ भन्ने निर्णय गर्छ।

सामान्य आकार धेरै भित्री संवादसहित एउटा बाह्य यातायात हो। धेरै बाह्य आदानप्रदान वा फरक IP प्रोटोकल चाहिने उत्पादनहरूले एक-सार्वजनिक-पोर्ट ढाँचाले यो डिजाइन वर्णन गर्छ, हरेक VPN होइन भन्ने सम्झाउँछन्।