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