पोर्ट फॉरवर्ड वि VPN प्रवेश: पॅकेट प्रत्यक्षात कुठे जाते

दोन रचना, एक HTTPS अनुप्रयोग, आणि पॅकेट प्रत्येकात वेगळा मार्ग घेतो। पोर्ट फॉरवर्ड पॅकेट कुठे पोहोचवायचे ते बदलतो आणि बाकी अशीच ठेवतो। VPN आधी ते पॅकेट दुसऱ्या पॅकेटमध्ये घेऊन जातो, त्यामुळे अनुप्रयोगाचा श्रोता वेगळा स्रोत आणि लहान कमाल पेलोड पाहतो। लोक ज्याबद्दल वाद घालतात ते एन्क्रिप्शन दोन्ही बाबतीत असते, कारण अनुप्रयोग अजूनही HTTPS आहे; फरक एवढाच की कोण कनेक्शन उघडू शकतो आणि मधले नेटवर्क काय निरीक्षण करू शकते। हा फरक बहुतेक व्यावहारिक प्रश्न सोडवतो।

DNAT नियम गंतव्य पुन्हा लिहितो आणि तिथेच थांबतो

Linux गेटवेवर सेवा प्रकाशित करणे म्हणजे nat तक्त्याच्या PREROUTING शृंखलेत नियम, किंवा nftables मध्ये त्याचे समतुल्य। नियम सार्वजनिक पत्ता आणि पोर्टशी जुळतो, नंतर गंतव्य अनुप्रयोगाच्या खाजगी पत्त्यावर पुन्हा लिहितो। स्रोत पत्ता, स्रोत पोर्ट आणि पेलोड असेच राहतात, आणि conntrack नकाशा नोंदवतो जेणेकरून उत्तरे बाहेर जाताना पुन्हा लिहिली जातात। हे वर्तन RFC 3022 मध्ये वर्णन केलेले पारंपरिक पत्ता भाषांतर मॉडेल आहे।

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

अनुप्रयोगाचा श्रोता कनेक्शन भाषांतरातून आले हे कधीच जाणत नाही। तो क्लायंटचा खरा स्रोत पत्ता पाहतो, जो प्रवेश नोंदी आणि दर मर्यादांसाठी उपयुक्त आहे, आणि खाजगी पत्त्यावर उत्तर देतो कारण conntrack नकाशा उलटतो। त्या मार्गावर काहीही डिक्रिप्ट किंवा पुन्हा एन्क्रिप्ट होत नाही: TLS अजूनही क्लायंट आणि अनुप्रयोगाच्या स्वतःच्या प्रमाणपत्रामध्ये चालते।

नियम नंतर भेटणाऱ्या अयशस्वी मोड्स देखील ठरवतो। गेटवे फॉरवर्ड करतो पण अनुप्रयोगाच्या होस्टला क्लायंटकडे परतीचा मार्ग नाही तर उत्तरे चुकीच्या स्रोतासह बाहेर पडतात आणि हातमिळवणी थांबते। दुसरा नियम आधी जुळल्यास क्रम निकाल ठरवतो, आणि iptables -t nat -L -n -v कोणत्या नियमाने पॅकेट घेतले हे सिद्ध करणारे काउंटर दाखवतो।

बोगदा श्रोत्यापूर्वी पॅकेट गुंडाळतो

VPN अनुप्रयोग प्रकाशित करत नाहीच। क्लायंट गेटवेच्या सार्वजनिक पत्त्याकडे लक्ष्य केलेले बाह्य पॅकेट तयार करतो, आतील पॅकेट त्यात एन्क्रिप्ट करतो, आणि गेटवे डिक्रिप्ट करून आतील पॅकेट खाजगी गंतव्याकडे रूट करतो। WireGuard मध्ये बाह्य वाहतूक UDP असते, सामान्यतः उंच पोर्टवर; OpenVPN TCP 443 वर असल्यास मार्ग पाहणाऱ्या कशालाही बाह्य पॅकेट TLS सारखे दिसते।

बोगद्यात आतील पॅकेट खाजगी पत्ते ठेवते: क्लायंटचा बोगदा पत्ता, समजा 10.8.0.6, आणि अनुप्रयोग 10.20.30.40 वर। त्यामुळे श्रोता बोगदा तळातून स्रोत पाहतो, आणि प्रत्येक क्लायंट तो गेटवे पुढील उडी म्हणून वाटून घेतो। VPN मागील प्रवेश नोंदी वापरकर्त्याऐवजी गेटवे दाखवतात याचे कारण नेमके हेच आहे, गेटवे मूळ स्रोत जतन करत नसेल तर।

गुंडाळणे शीर्षलेख जागा खर्च करते, आणि हाच मोजता येणारा परिणाम असलेला एकमेव यंत्रणा-स्तरीय फरक। बाह्य IP शीर्षलेख आणि UDP आणि WireGuard चा स्वतःचा शीर्षलेख मार्गाच्या MTU मधून खातात, त्यामुळे मोठे पॅकेट विभागावे लागतात किंवा आतील TCP स्टॅकने आपला MSS मर्यादित करावा। फॉरवर्ड केलेल्या मार्गावर चालणारे हस्तांतरण बोगद्यावर अडकू शकते जेव्हा मधले उपकरण लहान MTU सूचवणारे ICMP टाकून देते।

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

उघडकी प्रवेशद्वारावर ठरते, सायफरने नाही

दोन्ही रचना एकाच TLS श्रोत्यावर संपतात, त्यामुळे दोन्हींना तेच प्रमाणपत्र, तीच प्रोटोकॉल आवृत्ती आणि तोच अनुप्रयोग लॉगिन वारसा मिळतो। बदलते ते हे की कोणाला हातमिळवणी सुरू करण्याची परवानगी आहे। सार्वजनिक फॉरवर्डमध्ये, 203.0.113.10:443 पर्यंत पोहोचणाऱ्या कोणत्याही होस्टला तुमचे अनुप्रयोग अधिकृतता तपासण्यापूर्वीच TCP हातमिळवणी आणि TLS ClientHello मिळते। फक्त बोगद्यातून प्रवेशात, श्रोत्यापर्यंत फक्त गेटवे बोगद्यात रूट करतो त्या पत्त्यांवरूनच पोहोचता येते, आणि अनोळखीचा SYN गेटवे धोरणावर मरतो।

हा फरक पोहोचक्षमतेबद्दल आहे, गोपनीयतेबद्दल नाही। फॉरवर्ड केलेली HTTPS सेवा साधा मजकूर नाही, आणि VPN अनुप्रयोग प्रमाणीकरणाची गरज काढून टाकत नाही: बोगद्यात प्रवेश उपकरण या नेटवर्कमध्ये पॅकेट पाठवू शकते का याचे उत्तर देतो, तर फाइल अनुप्रयोग वापरकर्ता दस्तऐवज वाचू शकतो का याचे। दोन्हींचा गोंधळ हाच संघ संपूर्ण LAN देणारा VPN आणि एकाच सामायिक पासवर्डचा अनुप्रयोग येथे पोहोचण्याचा मार्ग आहे।

श्रोता आणि धोरण स्वतंत्रपणे तपासा, कारण यापैकी कोणतेही तुम्ही गृहीत धरता त्यापेक्षा विस्तृत असू शकते:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss श्रोता 0.0.0.0 ला बांधलेला आहे असे दाखवत असल्यास, अनुप्रयोग राउटिंग आणि फायरवॉल धोरण परवानगी देतात तिथून पोहोचण्यायोग्य आहे, आणि फॉरवर्ड आत येण्याचा एक मार्गच आहे। खाजगी पत्त्याला बांधणे, किंवा फायरवॉलमध्ये स्रोत श्रेणी मर्यादित करणे, VPN निवडण्यापासून वेगळा निर्णय आहे, आणि उघडकी प्रत्यक्षात कमी करणारा तोच निर्णय आहे।

मार्ग मोजा, लेबल नाही

कोणी फॉरवर्ड वेगवान आहे असे म्हटल्यावर, प्रामाणिक तुलना बाकी सर्व स्थिर ठेवते: तोच क्लायंट, तेच प्रवेश नेटवर्क, तीच फाइल, तीच TLS संरचना, तोच अनुप्रयोग होस्ट। प्रत्येक मार्गावर हस्तांतरण दोन वेळा चालवा आणि एकूण वेळ, अयशस्वींची संख्या आणि प्रतिसादक्षमता नोंदवा, असंबंधित वेग चाचणीचे आउटपुट नाही।

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

ही संख्या कनेक्शन स्थापना हस्तांतरण वेळेपासून वेगळी करतात, हे महत्त्वाचे कारण दोन मार्ग सामान्यतः सायफर खर्चात नाही, तर फेरी-परती विलंब आणि MTU मध्ये वेगळे असतात। TLS काम दोन्ही रचनांमध्ये टोकांवर होते, आणि बोगदा एन्कॅप्सुलेशन, वेगळा मार्ग आणि कदाचित अधिक व्यस्त गेटवे जोडतो। बोगद्याचा मार्ग लांब असल्यास किंवा त्याचा गेटवे भारित असल्यास, फरक मार्गाचा आहे, एन्क्रिप्शन शब्दाचा नाही।

सेवेला खरोखर आवश्यक असलेले प्रवेश धोरण निवडा, नंतर मोजलेला फरक ते बदलण्यास न्याय्य आहे का ते ठरवा। सार्वजनिक फॉरवर्ड खुल्या इंटरनेटसाठी असलेल्या सेवेसाठी योग्य आहे, स्रोत निर्बंध, अद्ययावत TLS आणि समोर देखरेखीसह। फक्त बोगद्यातून प्रवेश अशा अंतर्गत साधनासाठी योग्य आहे ज्याचे वापरकर्ते आधीच नोंदणीकृत आहेत, गेटवे राउटिंग आणि अनुप्रयोग परवानग्या दोन्ही संपूर्ण LAN पेक्षा अरुंद असल्यास।

रचना पूर्ण जाहीर करण्यापूर्वी चार गोष्टी पुष्टी करा: श्रोता कोणत्या पत्त्याला बांधलेला आहे, कोणता नियम किंवा मार्ग पॅकेट आत घेतो, क्लायंटच्या खऱ्या पत्त्यावरून परतीचा मार्ग चालतो का, आणि मोठे पेलोड MTU पार करतात का। यापैकी प्रत्येकासाठी वर आदेश आहे, आणि कोणत्याही उत्तरास «सुरक्षित» शब्द किंवा बँडविड्थ चार्ट देत नाही।