pfSense आउटबाउंड NAT: पहले जनरेट किए गए नियम पढ़ें

Firewall खोलें, फिर NAT, फिर Outbound, और कुछ भी जोड़ने से पहले मोड पढ़ें। Automatic मोड में pfSense WAN इंटरफ़ेस के लिए और उनमें से रिमोट-एक्सेस VPN नेटवर्क के लिए नियम जनरेट करता है, इसलिए जो पूल आप जोड़ने वाले हैं वह अक्सर पहले ही कवर होता है। हाथ से लिखी पंक्ति का न होना अनुवाद के न होने का प्रमाण नहीं है। नीचे का क्रम आपको एक पूल के लिए पूरे फ़ायरवॉल को Manual पर बदलने से रोकता है।

मोड तय करता है कि बॉक्स के हर दूसरे नेटवर्क के लिए अनुवाद कौन बनाए रखता है, और यह एक VPN अपवाद से बड़ा निर्णय है।

Automatic मोड पहले से ही VPN पूल को कवर करता है

हर मोड का अलग स्वामी होता है। Automatic WAN इंटरफ़ेस के लिए नियम जनरेट करता है और रिमोट-एक्सेस VPN नेटवर्क को अपने स्रोतों में शामिल करता है। Hybrid उन जनरेट किए गए नियमों को रखता है और आपको उनके बगल में मैनुअल नियम जोड़ने देता है। Manual कुछ भी जनरेट करना बंद कर देता है, इसलिए फ़ायरवॉल पर हर अनुवाद आपकी ज़िम्मेदारी बन जाता है, जिन्हें आपने नहीं लिखा उन सहित। चौथी सेटिंग आउटबाउंड NAT को पूरी तरह बंद कर देती है। हाथ से लिखी दिखने वाली पंक्ति तब तक कुछ सिद्ध नहीं करती जब तक आपको पता न हो कि कौन सा मोड सक्रिय है।

Automatic और Hybrid में पेज जनरेट किए गए नियम भी दिखाता है। यह निष्कर्ष निकालने से पहले कि VPN पूल का कोई अनुवाद नहीं है, उन्हें पढ़ें: स्रोत कॉलम में पूल का नेटवर्क और इंटरफ़ेस कॉलम में WAN इंटरफ़ेस खोजें।

Hybrid केवल समीक्षा किए गए अपवाद के लिए चुनें

जब एग्रेस नीति वास्तव में अलग हो तब भी प्रलेखित अपवाद संभव है। एक सर्वर की कल्पना करें जो 10.90.0.0/24 बाँटता है, जहाँ फ़ायरवॉल को IPv4 इंटरनेट एग्रेस देना चाहिए और राउटिंग पहले से WAN चुनती है। अपेक्षित रूपांतरण यह है कि स्रोत 10.90.0.23 को WAN पते पर फिर से लिखा जाए। जाँचें कि कोई जनरेट किया गया नियम उस एग्रेस पर पहले से ऐसा करता है या नहीं; यदि नहीं, तो Hybrid स्वचालित कवरेज बनाए रखते हुए आपका समीक्षा किया गया नियम जोड़ता है।

स्रोत के रूप में वास्तविक VPN पूल, या उसके लिए समर्थित उपनाम इस्तेमाल करें, और केवल इसलिए कभी असंबंधित पता न चुनें कि OpenVPN इंस्टेंस का नाम पिकर में नहीं है। any स्रोत से बचें, जो फ़ायरवॉल द्वारा स्वयं उत्पन्न ट्रैफ़िक का भी अनुवाद करता है।

एक पूल के लिए पूरे फ़ायरवॉल को Manual पर न ले जाएँ। वह निर्णय हर आंतरिक नेटवर्क और हर भविष्य के WAN परिवर्तन के लिए रखरखाव फिर से सौंपता है।

NAT एग्रेस नहीं चुनता

राउटिंग एग्रेस इंटरफ़ेस चुनती है; आउटबाउंड NAT नियम केवल बताता है कि पैकेट निकलने के बाद स्रोत कैसे फिर से लिखा जाता है। WAN के लिए मैपिंग राउटिंग द्वारा कहीं और भेजे गए पैकेट को WAN पर जाने के लिए बाध्य नहीं करती, इसलिए NAT जोड़ना गलत रूट को ठीक नहीं कर सकता। लागू 1:1 NAT प्रविष्टियाँ और अपवाद भी जाँचें, क्योंकि क्रम मायने रखता है और नई पंक्ति ज़रूरी नहीं कि जीते। और आउटबाउंड पेज फ़िल्टर पेज नहीं है।

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

नए कनेक्शन पर रूपांतरण सिद्ध करें

स्वीकृत परिवर्तन के बाद, मौजूदा कनेक्शन का पुन: उपयोग करने के बजाय नए अधिकृत कनेक्शन से परीक्षण करें, क्योंकि स्थापित स्थितियाँ अपना पिछला रूपांतरण बनाए रखती हैं। पुष्टि करें कि कौन सा स्रोत पता वास्तव में WAN छोड़ता है और उत्तर उसी स्थिति से लौटता है। पहले कदम के रूप में पूरी स्थिति तालिका फ्लश न करें; यह छिपा देता है कि किस नियम ने परिणाम बदला। परिवर्तन टिकट में मोड, नियम, पूल और एग्रेस दर्ज करें।

यह उदाहरण केवल IPv4 एग्रेस को कवर करता है। यह IPv6 अनुवाद या फ़िल्टरिंग नीति के बारे में कुछ नहीं कहता, और जिस डिज़ाइन को इसकी आवश्यकता हो उसे यह अलग से बताना होगा। अंतिम रिकॉर्ड अनुमत क्लाइंट ट्रैफ़िक, उसे ले जाने वाला इंटरफ़ेस और स्रोत को आख़िर क्यों फिर से लिखना है, इसका कारण सूचीबद्ध करता है।