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