एक और 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 के ज़्यादा सुरक्षित होने की आदत से नहीं। पहले से निजी खंड पर टनल बिना किसी लाभ के परिचालन लागत और एक और विफलता विधि जोड़ती है, जबकि अविश्वसनीय खंड पर रूटिंग गोपनीयता को ऐसी सादगी से बदल देती है जो आप वहन नहीं कर सकते। लिख लें कि तीनों में से किस शर्त ने चुनाव को प्रेरित किया, और अगले इंजीनियर को इसे फिर से बहस नहीं करनी पड़ेगी।