पोर्ट फ़ॉरवर्ड बनाम VPN एक्सेस: पैकेट वास्तव में कहाँ जाता है

पोर्ट फ़ॉरवर्ड गंतव्य को फिर से लिखता है और वहीं रुक जाता है; VPN पहले पैकेट को लपेटता है। देखें कि कौन कौन-सी परत बदलता है और HTTPS के लिए इसका क्या अर्थ है।

दो डिज़ाइन, एक 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 सीमित करना पड़ता है। जो स्थानांतरण फ़ॉरवर्ड किए गए रास्ते पर काम करता है वह सुरंग पर अटक सकता है जब कोई मध्य उपकरण उस ICMP को गिरा देता है जो छोटे MTU का संकेत देता।

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 पार करते हैं या नहीं। इनमें से हर एक के लिए ऊपर एक कमांड है, और किसी का भी जवाब «सुरक्षित» शब्द या बैंडविड्थ चार्ट नहीं देता।

संबंधित लेख