अर्को NAT थप्नु अघि निजी LAN बीच रुट गर्नुहोस्
ओभरल्याप हुने ठेगाना ठाउँ, हराएको फिर्ती मार्ग वा अविश्वसनीय ट्रान्जिटले रुटिङ, NAT र सुरुङ बीचको छनोट तय गर्छ। फायरवाल सम्पादन गर्नु अघि यी तीन जाँच्नुहोस्।
दुई आन्तरिक फायरवाल, एउटा निजी ट्रान्जिट खण्ड, र प्रत्येक LAN का केही होस्टले अर्कासँग बोल्न पाउने अनुरोध। सामान्य प्रतिक्रिया VPN उभ्याउनु वा दोस्रो NAT तह थप्नु हो, र दुवै प्रतिक्रियाले समस्याको लायकभन्दा बढी खर्च गर्छन्। साधारण रुटिङ पर्याप्त हुन्छ जब तीन सर्त पूरा हुन्छन्: ठेगाना दायराहरू ओभरल्याप हुँदैनन्, दुवै पक्षले अर्को LAN मा ट्राफिक फर्काउन सक्छन्, र ट्रान्जिट खण्ड डेटाका लागि पहिले नै पर्याप्त विश्वसनीय छ। केही पनि डिजाइन गर्नु अघि यी तीन जाँच्नुहोस्, किनकि प्रत्येकले उत्तर बदल्छ।
डिजाइन तय गर्ने तीन सर्त
पहिलो सर्त ठेगाना ठाउँ हो। यदि दुवै LAN एउटै RFC 1918 ब्लक प्रयोग गर्छन्, रुटिङले तिनलाई छुट्याउन सक्दैन र अनुवाद वैकल्पिक नभई अनिवार्य हुन्छ। दोस्रो फिर्ती मार्ग हो: A बाट B सम्मको मार्ग तबसम्म निरर्थक हुन्छ जबसम्म B लाई पनि A को LAN मा कसरी पुग्ने थाहा हुँदैन, र असममित ज्ञान नै रुटेड डिजाइनले चुपचाप उत्तरहरू खसाल्ने सबैभन्दा सामान्य कारण हो।
तेस्रो विश्वास हो। रुटिङले प्याकेट सार्छ; तिनको रक्षा गर्दैन। एउटै भवनभित्रको निजी ट्रान्जिट खण्ड प्रदायकलाई हस्तान्तरण वा साझा क्याम्पस ब्याकबोन तर्ने लिङ्कभन्दा फरक कुरा हो। खण्ड विश्वसनीय छैन भने उत्तर दुई फायरवालबीचको सुरुङ हो, र तलको रुटिङ योजना यसभित्र पनि लागू हुन्छ।
तीनवटै एउटै दिशामा देखाएपछि मात्र सरल डिजाइन जित्छ। तीमध्ये एउटा असफल भएमा अनुवादले छोप्नुको सट्टा त्यो सर्त स्पष्ट रूपमा सुधार्नुहोस्, किनकि NAT असफलता लुकाउँछ, समाधान गर्दैन।
ट्रान्जिट नेटवर्कमा रुट योजना बनाउनुहोस्
प्रत्येक फायरवाललाई साझा खण्डमा ठेगाना दिनुहोस् र प्रत्येक टाढाको LAN का लागि एउटा विशिष्ट रुट थप्नुहोस्। विद्यमान कन्फिगरेसनमा अरू केही सार्नु पर्दैन, र विशेष गरी इन्टरनेट डिफल्ट रुट जहाँ छ त्यहीँ रहनुपर्छ। डिफल्ट रुटलाई पियर फायरवालले बदल्दा प्रत्येक असम्बन्धित गन्तव्य ट्रान्जिटबाट जान्छ, जुन मागिएको परिवर्तनभन्दा धेरै ठूलो हो। pfSense को स्ट्याटिक रुटिङ दस्तावेज त्यो प्लेटफर्मका लागि त्यही रुट-प्लस-गेटवे मोडेल वर्णन गर्छ, र तपाईंले वास्तवमा चलाउनुहुने कुनै पनि फायरवालमा समान नियन्त्रण हुन्छ।
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
फायरवाल A ले 10.30.0.0/24 सेवा गर्छ र फायरवाल B ले 10.40.0.0/24, दुई ट्रान्जिट ठेगाना 192.0.2.0/24 मा छन्। प्रत्येक LAN होस्टले आफ्नो स्थानीय फायरवाललाई गेटवे राख्छ, त्यसैले एकमात्र नयाँ अवस्था प्रत्येक पट्टि एउटा रुट हो। Linux आधारित फायरवालमा त्यही योजना यस्तो देखिन्छ, र फर्वार्डिङ सक्षम हुनुपर्छ, नत्र रुट समाधान हुन्छ तर प्याकेट खसालिन्छ।
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
फिल्टरिङलाई अनुवादबाट अलग राख्नुहोस्
रुटिङ र नीति फरक नियन्त्रण हुन्, र दोस्रोमै धेरै रुटेड डिजाइन वास्तवमा असफल हुन्छन्। प्याकेटले वास्तवमा तर्ने प्रवेश सीमामा विशिष्ट स्रोत, गन्तव्य र सेवाहरूलाई अनुमति दिनुहोस्, र WAN जस्तो इन्टरफेस लेबल नाम हो, विश्वासको बारेमा कथन होइन भन्ने सम्झनुहोस्। निजी ट्राफिक बोक्ने ट्रान्जिट पोर्टमा निजी ठेगाना ब्लकिङ डिफल्ट रूपमा सक्रिय हुन सक्छ।
त्यसपछि NAT हुँदैन भन्ने निष्कर्षमा पुग्नु अघि बाहिर जाने अनुवाद हेर्नुहोस्। स्वचालित बाहिर जाने नियमहरूले कहिल्यै अनुवादका लागि नभएको ट्राफिक पुनःलेखन गर्न सक्छन्, र त्यसले अर्को पक्षलाई आफ्नै नीति र लगका लागि आवश्यक स्रोत ठेगाना नष्ट गर्छ। छानिएका प्रवाहहरूले मूल ठेगाना कायम राख्छन् भनी पुष्टि गर्नुहोस्, र अझै आवश्यक ट्राफिकका लागि इन्टरनेट अनुवाद नियम अछुत राख्नुहोस्।
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
जब NAT नै इमानदार उत्तर हो
ठेगाना दायराहरू साँच्चै ओभरल्याप हुँदा र पुनःक्रमांकन उपलब्ध नहुँदा, वा नीतिले एक पक्षले सबनेटको सट्टा एउटै ठेगाना देख्नुपर्ने माग गर्दा अनुवादले आफ्नो स्थान कमाउँछ। त्यस्ता अवस्थामा जानाजान गरिएको एक-देखि-एक वा पोर्ट-सीमित म्यापिङ ज्ञात परिणामसहितको डिजाइन निर्णय हो, काम चलाउने उपाय होइन।
ठूलो स्वरमा भन्नुपर्ने परिणाम यो हो कि अर्को पक्षले अब व्यक्तिगत स्रोत देख्न वा फिल्टर गर्न सक्दैन। लगहरू अनुवाद गर्ने ठेगानामा खुम्चिन्छन्, प्रति-होस्ट नीति काम गर्न छाड्छ, र समस्या समाधान कुनै क्षणमा कुन आन्तरिक होस्टसँग प्रवाह थियो भन्ने खोजीमा परिणत हुन्छ। प्रश्नको ट्राफिकका लागि यीमध्ये केही पनि महत्त्वपूर्ण नभए, NAT ठीक छ।
जब ट्रान्जिट आफैं गलत अनुमान हो
साझा खण्ड प्रदायक, साझा स्विच फ्याब्रिक वा अर्को पक्षले ट्राफिक पढ्न सक्ने कुनै पनि बाटो हुँदै गएमा, केवल रुटिङ पूर्ण उत्तर होइन। दुई फायरवालबीचको सुरुङले तपाईंलाई गोपनीयता र पियर प्रमाणीकरण दिन्छ, र यसभित्रको रुट तालिका तपाईंले ट्रान्जिटमा लेख्ने त्यही तालिका हो।
यो पहिलो खण्डको विश्वास प्रश्नबाट तय गर्नुहोस्, VPN बढी सुरक्षित हुन्छन् भन्ने बानीबाट होइन। पहिले नै निजी रहेको खण्डमाथिको सुरुङले कुनै लाभबिना सञ्चालन लागत र अर्को असफलता विधि थप्छ, जबकि अविश्वसनीय खण्डमाथिको रुटिङले गोपनीयतालाई तपाईंले वहन गर्न नसक्ने सरलतासँग साट्छ। तीन सर्तमध्ये कुनले छनोटलाई निर्देशित गर्यो लेख्नुहोस्, अर्को इन्जिनियरले फेरि बहस गर्नु पर्दैन।