SNAT, DNAT र Masquerade: प्रत्येक VPN NAT नियम के गर्छ

स्रोत NAT फेरि लेख्छ कि प्रवाह कहाँबाट आएको देखिन्छ; गन्तव्य NAT फेरि लेख्छ कि त्यो कहाँ जान्छ। Masquerade भनेको उधारो ठेगानासहितको स्रोत 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 ठेगाना बदलिएपछि दोहोर्याउनुहोस्।

सम्बन्धित लेखहरू