एक 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 का नहीं।