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 पत्ता बदलल्यानंतर ती पुन्हा करा।