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