SNAT, DNAT और Masquerade: VPN का हर NAT नियम क्या करता है

VPN गेटवे के दोनों ओर कैप्चर रखिए और एक प्रवाह चार अलग पते दिखा सकता है। स्रोत NAT फिर से लिखता है कि पैकेट कहाँ से आने का दावा करता है; गंतव्य NAT फिर से लिखता है कि वह कहाँ जा रहा है। Masquerade तीसरी दिशा नहीं है, यह स्रोत-NAT नियम है जो निश्चित मान के बजाय बाहर जाने वाले इंटरफ़ेस का पता लेता है। नाम दीजिए कि तीनों में से आपको वास्तव में कौन-सा चाहिए और ज़्यादातर «VPN टूटा है» टिकट वापसी मार्ग के सवाल में बदल जाएँगे।

हर नियम क्या फिर से लिखता है

स्रोत NAT, जिसे आम तौर पर SNAT लिखा जाता है, राउटर या गेटवे छोड़ते समय प्रवाह का स्रोत पता बदलता है। प्राप्त करने वाली सेवा अनूदित पते पर उत्तर देती है, और अनुवाद करने वाला बॉक्स उस कनेक्शन के लिए रखी गई स्थिति से बदलाव उलट देता है। Linux में वह स्थिति conntrack में रहती है, इसलिए conntrack -L मूल और उत्तर टपल साथ-साथ छापता है।

गंतव्य NAT, DNAT, इसके बजाय गंतव्य बदलता है। UDP 51820 पर सार्वजनिक पते को भेजा गया पैकेट 10.8.0.2:51820 पर आंतरिक WireGuard सर्वर में फिर से लिखा जा सकता है। घरेलू राउटर या क्लाउड लोड बैलेंसर इसी तरह VPN श्रोता प्रकाशित करता है, और यह नहीं बताता कि सुरंग इसके बाद क्या ढो सकती है।

Masquerade SNAT परिवार का है। नियम कोई पता नहीं देता; यह वही पता लेता है जो पैकेट निकलते समय बाहर जाने वाले इंटरफ़ेस के पास हो। Linux इसे अपना लक्ष्य देता है, और DHCP या PPPoE से पता पाने वाले WAN इंटरफ़ेस पर यह सामान्य पसंद है।

मैपिंग कहाँ रहती है, यही विफलता तय करती है

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

वापसी ट्रैफ़िक को उस डिवाइस से गुज़रना ही होगा जो मैपिंग रखता है। अगर उत्तर कोई और मार्ग लेता है, दूसरा अपलिंक, नीति-मार्ग या ऐसा प्रदाता जिसने आपकी निजी श्रेणी कभी नहीं सुनी, तो स्थिति वाला उलटा अनुवाद कभी नहीं होता और क्लाइंट एकतरफ़ा ट्रैफ़िक देखता है। और स्रोत NAT जोड़ना गायब वापसी मार्ग की मरम्मत शायद ही करता है; यह एक प्रवाह पर लक्षण छिपा सकता है और बाकी हर जगह पते-आधारित नीति तोड़ सकता है।

दूसरी आम गलती यह अपेक्षा है कि सुरंग राउटिंग-योग्यता बनाएगी। जिस निजी क्लाइंट के पैकेट इंटरनेट पर जाते हैं उसे मान्य निकास व्यवस्था चाहिए: डिफ़ॉल्ट मार्ग, फ़ॉरवर्ड करने वाला गेटवे और आम तौर पर सार्वजनिक पते पर स्रोत अनुवाद। सिर्फ़ एन्क्रिप्शन निजी पते को पहुँचने योग्य नहीं बनाता।

Masquerade या स्पष्ट SNAT

दोनों की तुलना उनके वादों से कीजिए। Masquerade निकास पता चुनता है, स्पष्ट SNAT उसे पिन करता है। स्थिर सार्वजनिक पते वाले गेटवे पर पिनिंग लॉग और भागीदार अनुमति-सूची को एक पूर्वानुमेय मान देती है। गतिशील WAN लिंक पर पिन किया गया SNAT पता लीज़ बदलते ही गलत हो जाता है, और Masquerade ठीक इसी स्थिति के लिए बनाया गया था।

दायरा चुनाव जितना ही मायने रखता है। गेटवे छोड़ने वाले हर पैकेट से मेल खाने वाला Masquerade नियम, स्रोत या गंतव्य की सीमा के बिना, उस ट्रैफ़िक का भी अनुवाद करता है जिसे आप अक्षुण्ण रखना चाहते थे, अन्य निजी नेटवर्क के ट्रैफ़िक सहित। नियम को क्लाइंट श्रेणी, इच्छित गंतव्य और इंटरफ़ेस तक सीमित कीजिए।

नीति-आधारित IPsec में यह सबसे ज़्यादा काटता है। strongSwan की फ़ॉरवर्डिंग मार्गदर्शिका IP फ़ॉरवर्डिंग चालू करने और क्लाइंट के लिए स्रोत-NAT नियम जोड़ने की प्रक्रिया बताती है, और वही दस्तावेज़ उस ट्रैफ़िक को बाहर रखने को भी शामिल करता है जिसे अपना मूल पता रखना है। सुरक्षा नीति के मेल खाने से पहले स्रोत का अनुवाद कीजिए और सुरंग ऊपर आ सकती है जबकि ट्रैफ़िक अब भी गिरता रहे, क्योंकि पैकेट अब बातचीत किए गए सेलेक्टर जैसा नहीं दिखता।

यह भी तय कीजिए कि दूर का सिरा क्या देखे। अनुवाद के बाद सेवा गेटवे देखती है, अलग-अलग क्लाइंट नहीं। इससे वापसी राउटिंग सरल होती है और साथ ही लॉग सपाट होते हैं तथा प्रति-क्लाइंट अनुमति-सूचियाँ बेअसर होती हैं। अगर क्लाइंट पते सुरक्षित रखना मायने रखता है, तो परीक्षण पास कराने के लिए उन्हें छिपाने के बजाय राउटेड वापसी मार्ग की योजना बनाइए।

Linux गेटवे पर नियम पढ़ना

10.8.0.0/24 पर क्लाइंट और eth0 नाम का WAN इंटरफ़ेस रखने वाले रिमोट-एक्सेस गेटवे को फ़ॉरवर्डिंग चालू और ऐसी फ़िल्टर नीति चाहिए जो प्रवाह की अनुमति दे, तभी कोई NAT नियम मदद कर सकता है। iptables संस्करण दोनों दिशाएँ nat तालिका में रखता है:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables रूप वही दो हुक नामित इंटरफ़ेस और स्पष्ट चेन के साथ उपयोग करता है:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

दोनों अंश मानते हैं कि फ़िल्टर चेन फ़ॉरवर्ड किए गए प्रवाह को पहले ही स्वीकार करती है। NAT अनुमति का नियम नहीं है, और सही ढंग से अनूदित पैकेट भी एक तालिका बाद गिराया जा सकता है। conntrack -L से जीवित मैपिंग की पुष्टि कीजिए, nft list ruleset या iptables-save -t nat से पुष्टि कीजिए कि क्या लोड है, फिर पता सचमुच बदलता देखने के लिए दोनों इंटरफ़ेस पर कैप्चर कीजिए।

खराब नियम जैसे दिखने वाले विफलता-प्रकार

हेयरपिन ट्रैफ़िक क्लासिक है। जो आंतरिक क्लाइंट सर्वर के सार्वजनिक पते से आंतरिक सर्वर तक पहुँचता है उसे अंदर आते मार्ग पर DNAT और लौटते मार्ग पर स्रोत अनुवाद चाहिए, वरना सर्वर सीधे क्लाइंट को उत्तर देता है और उत्तर अस्वीकार हो जाता है। समाधान उस आंतरिक-से-सार्वजनिक स्थिति के लिए दूसरा, संकरा नियम है, सब कुछ के लिए चौड़ा Masquerade नियम नहीं।

दोहरा अनुवाद ख़ामोश वाला है। जो क्लाइंट पहले से ऑपरेटर-स्तरीय NAT के पीछे है वह आपके गेटवे पर ऐसे पते के साथ आता है जिसे आप वापस राउट नहीं कर सकते, इसलिए आप फिर अनुवाद करते हैं। काम करता है, पर लॉग अब निजी पता-निर्धारण की दो छलाँगें ढोते हैं और किसी भी जाँच के लिए दोनों मैपिंग चाहिए। नीति-आधारित IPsec तीसरा मोड़ जोड़ता है: नीति के मेल खाने से पहले अनुवाद कीजिए और आपको ऐसा SA मिलता है जो ऊपर है पर कोई ट्रैफ़िक नहीं गुज़रता, जो NAT की नहीं बल्कि फ़ायरवॉल की गड़बड़ जैसा पढ़ा जाता है।

फिर वह परीक्षण है जो पास होता है और वह तैनाती जो विफल होती है। NAT कमांड हाथ से चलाना तंत्र सिद्ध करता है, कॉन्फ़िगरेशन नहीं। रनटाइम में जोड़ा गया नियम रीबूट पर या अगली इंटरफ़ेस घटना पर गायब हो जाता है, और जिस इंटरफ़ेस का नंबर बदलता है उससे बँधा Masquerade नियम दूर के सिरे को दिखने वाला पता चुपचाप बदल सकता है। नियम को उसके मालिक फ़ायरवॉल के कॉन्फ़िगरेशन में रखिए और फिर से जुड़ने के बाद दोबारा परखिए।

नियम सहेजने से पहले जाँच-सूची

पहले दिशा का नाम दीजिए: स्रोत, गंतव्य या दोनों। फिर तय कीजिए कि स्थिति किसे रखनी है — गेटवे, ऊपर का राउटर या IPsec साथी — और पुष्टि कीजिए कि वापसी मार्ग उसी से लौटता है। नियम को उसी क्लाइंट श्रेणी, गंतव्य और इंटरफ़ेस तक सीमित कीजिए जो आपका वास्तविक इरादा है, और पहले से तय कीजिए कि दूर का सिरा गेटवे देखे या मूल क्लाइंट पता।

गेटवे से नहीं, क्लाइंट से परखिए। गेटवे पर ही रखा ब्राउज़र क्लाइंट अनुवाद नियम को पूरी तरह बचा सकता है, इसलिए वहाँ चलने वाला पन्ना सुरंग के बारे में कुछ सिद्ध नहीं करता। क्लाइंट से शुरू हुआ एक अनुरोध भेजिए, काउंटर और conntrack तालिका देखिए, और अगर जहाँ आप काम करते हैं वहाँ कोई एक संभव हो तो सुरंग के दोबारा जुड़ने और WAN पता बदलने के बाद फिर दोहराइए।