स्रोत NAT ग्राहक पते को बाद के फ़ायरवॉल से छिपाता है

स्टाफ़ और लैब ग्राहकों के लिए लिखा गया नियम नए एज फ़ायरवॉल पर जाता है, और वह चुपचाप सब कुछ या कुछ भी मैच नहीं करता। कारण ऊपर है: एक गेटवे पहले ही ग्राहक पतों को फिर से लिख चुका है, इसलिए नियम दो समूहों के बजाय एक ट्रांज़िट पता देखता है। उपकरण जोड़ने से वह जानकारी वापस नहीं आती जो पथ ने हटा दी थी। नीति लिखने से पहले वह अंतिम बिंदु खोजें जहाँ अंतर अभी भी मौजूद है।

एज नियम एक ही पता क्यों देखता है

कई-से-एक अनुवाद हर आंतरिक पता और पोर्ट जोड़ी को एक निर्धारित पोर्ट वाले साझा बाहरी पते पर मैप करता है। उन पोर्ट बंधनों के कारण अनुवादक के लिए बातचीत अलग रहती है, लेकिन सरल स्रोत-उपसर्ग मिलान करने वाला नीचे का उपकरण केवल साझा पता देखता है। नियम पर दो समूहों को एक जैसा बनाने के लिए यह पर्याप्त है। पैकेट अब भी आते हैं; समूहीकरण नहीं।

जाँचें कि फ़ायरवॉल का इंटरफ़ेस वास्तव में क्या देखता है, न कि आरेख क्या वादा करता है। दोनों अक्सर लोगों की अपेक्षा से अधिक भिन्न होते हैं।

अंतिम लागू करने योग्य पहचान खोजें

प्रवर्तन बिंदु से शुरू करें और तब तक पीछे चलें जब तक मूल उपसर्ग दिखाई न दे। आमतौर पर दो कमांड सीमा का पता लगाते हैं।

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

NAT तालिका दिखाती है कि कौन-सा ट्रैफ़िक और किस नियम से अनूदित होता है, जबकि conntrack सूची सक्रिय प्रवाहों के मूल और अनूदित जोड़े दिखाती है। जहाँ ऊपर का फ़ायरवॉल हमेशा केवल अनूदित पता देखता है, वहाँ समूह के अनुसार स्रोत नियम चाहे जैसे लिखे गए हों काम नहीं कर सकते। पथ पर आगे या पीछे चलें जब तक ऐसे उपकरण तक न पहुँचें जहाँ दोनों ग्राहक उपसर्ग अलग रहते हैं। अंदर या बाहर के लेबल पर भरोसा करने के बजाय हर हॉप पर स्रोत दर्ज करें।

तीन स्थान और हर एक की कीमत

नीति अनुवाद करने वाले गेटवे पर रह सकती है, जहाँ मूल स्रोत अभी भी दिखाई देते हैं। यह ऊपर के फ़ायरवॉल पर रह सकती है यदि ट्रांज़िट अनूदित होने के बजाय रूट हो जाए, जिसका अर्थ है वापसी मार्ग जोड़ना और स्रोत पुनर्लेखन हटाना। या इसे पतों के बजाय पहचान पर लागू किया जा सकता है, ऐसे प्रमाणित नियंत्रण के माध्यम से जो उपयोगकर्ता या उपकरण को जानता है। हर विकल्प का एक स्वामी और एक विफलता-विधि है, और केवल पहले दो नियम को पूरी तरह स्रोत पतों तक सीमित रखते हैं।

आप जो भी चुनें, नियम को उस पते के साथ प्रलेखित करें जिससे वह मेल खाता है। जिस नियम की पता-धारणा चुपचाप बदल गई हो, वह नियम न होने से भी बुरा है, क्योंकि वह ट्रैफ़िक से मेल खाता रहता है जबकि कुछ और ही सुरक्षित कर रहा होता है।

स्वीकृति: एक अनुमत और एक अस्वीकृत ग्राहक

हर समूह से एक-एक, दो ग्राहकों के साथ परीक्षण करें और दर्ज करें कि हर एक प्रवर्तन बिंदु पर कैसे पहुँचता है। दोनों जोड़े नियम परिणाम के पास रखें, ताकि साक्ष्य दिखाए कि अंतर बचा रहा, न कि यह कि कोई दूसरा फ़ायरवॉल मौजूद है। NAT या रूटिंग परिवर्तन के बाद परीक्षण दोहराएँ, क्योंकि प्रस्तुत पता ही वह हिस्सा है जो चुपचाप टूटता है। जहाँ लोगों को अलग करना ज़रूरी हो वहाँ प्रमाणीकरण बनाए रखें, क्योंकि स्रोत पता नीति का इनपुट है, पहचान का प्रमाण नहीं।

प्रवर्तन बिंदु, देखा गया स्रोत और नियम टिकट में लिखें। वरना अगला इंजीनियर दूसरा फ़ायरवॉल और वही नियम जोड़ देगा।