pfSense OpenVPN: अर्को राउटरको पछाडिको नेटवर्कमा पुग्ने

तपाईंको ल्यापटप VPN मार्फत pfSense LAN मा पुग्छ तर अझै दुई हप भित्रको सेवामा पुग्न सक्दैन, र फरक प्रत्येक मालिकका लागि एक राउटिङ निर्णय हो। प्याकेटले आफ्नो आउ-जाउ यात्रा पूरा गर्नु अघि तीन उपकरणले सहमति जनाउनुपर्छ: क्लाइन्ट, फायरवाल र गन्तव्य नेटवर्कको वास्तविक मालिक राउटर। यीमध्ये कुनै पनि छुट्यो भने लक्षण उस्तै देखिन्छ।

नियम बदल्नु अघि एउटा प्याकेटलाई यी तीन निर्णयहरूबाट पुर्याएर हेर्नुहोस्, किनकि हरेक मालिकको नियन्त्रण र असफल हुने तरिका फरक हुन्छ।

एउटा प्याकेट, तीन राउटिङ निर्णय

गन्तव्य सुरुङमा पर्छ कि पर्दैन भनेर क्लाइन्टले निर्णय गर्छ, र उसले आफूलाई थाहा भएका कुराबाट मात्र निर्णय गर्न सक्छ: धकेलिएको मार्ग, स्थानीय मार्ग वा पहिले नै सबै ढाक्ने पूर्वनिर्धारित। pfSense ले प्याकेट अर्को कहाँ पठाउने भनेर निर्णय गर्छ, र अर्को राउटरको पछाडिको नेटवर्कका लागि यसको अर्थ सही इन्टरफेसमा पुग्न सकिने गेटवेमार्फत स्थिर मार्ग हो। तल्लो राउटरले VPN पूलमा फर्कने बाटो थाहा छ कि छैन भनी निर्णय गर्छ, र थाहा छैन भने जवाफ फालिन्छ वा निरर्थक ठाउँमा पठाइन्छ। हरेक निर्णय अरू दुईबाट स्वतन्त्र छ।

यीमध्ये कुनै एकको असफलताले उही प्रयोगकर्ता रिपोर्ट दिन्छ। त्यसैले डिबगिङको क्रम उपकरणभन्दा बढी महत्त्वपूर्ण हुन्छ।

क्लाइन्टलाई प्रिफिक्स दिनुहोस्, अनुमान होइन

IPv4 सुरुङ नेटवर्क /30 भन्दा ठूलो भएको pfSense SSL/TLS सर्भरमा, IPv4 Local network(s) फिल्डले जोड्दा क्लाइन्टहरूलाई मार्ग वितरण गर्छ। क्लाइन्टले आफैँ एक बनाउँछ भन्ने भरोसा गर्नुको सट्टा तल्लो प्रिफिक्स त्यहाँ थप्नुहोस्। त्यसपछि जोडिएपछि क्लाइन्टको वास्तविक तालिका पढ्नुहोस्, किनकि route-nopull भएको प्रोफाइल वा मार्ग फिल्टरले सर्भरले पठाएको कुरा बेवास्ता गर्न सक्छ। सर्भर पूर्ण रूपमा सही हुन सक्छ जबकि क्लाइन्टले केही पनि स्थापना गर्दैन।

अन्य सर्भर मोड र टोपोलोजीका सीमा फरक हुन्छन्, र प्रति-क्लाइन्ट वा जडान नीतिले निश्चित क्लाइन्टले पाउने कुरा बदल्न सक्छ। तपाईंले पहिले परीक्षण गरेको क्लाइन्टमा होइन, महत्त्वपूर्ण क्लाइन्टमा प्रमाणित गर्नुहोस्।

pfSense लाई आन्तरिक राउटरतिर निर्देशित गर्नुहोस्

pfSense मा स्थिर मार्गलाई परिभाषित र पुग्न सकिने गेटवे चाहिन्छ, र त्यो गेटवेका लागि छानिएको इन्टरफेस त्यही हुनुपर्छ जो वास्तवमा त्यहाँ पुग्छ, जसरी Netgate को स्थिर-मार्ग मार्गदर्शिका वर्णन गर्छ। एउटा उदाहरणीय बनोटमा ट्रान्जिट लिंक फायरवालमा 192.168.77.1 र आन्तरिक राउटरमा 192.168.77.2 हो, र सेवा नेटवर्क त्यसको पछाडि 172.16.30.0/25 मा छ। त्यसपछि मार्गले प्रिफिक्स र अर्को हपको नाम दिन्छ, सेवाको ठेगानाको होइन। टाढाको नेटवर्कको ठेगाना गेटवेका रूपमा प्रयोग गर्नु सही देखिने तर कतै फर्वार्ड नगर्ने मार्ग बनाउने सामान्य तरिका हो।

इन्टरफेसलाई नाम दिनुले त्यसको पछाडिका नेटवर्कको वर्णन गर्दैन। स्थिर मार्ग नै त्यो वर्णन हो।

टाढाको पक्षले पूल थाहा पाउनुपर्छ

तल्लो राउटरलाई पूलका लागि फर्कने मार्ग चाहिन्छ, यो उदाहरणमा 192.168.77.1 मार्फत 10.55.0.0/24, जबसम्म पूर्वनिर्धारित मार्ग वा गतिशील प्रोटोकलले पहिले नै एक दिँदैन। सेवा होस्टको आफ्नै गेटवेले त्यो राउटरतिर लैजानुपर्छ, जो सामान्यतया राउटर उसको पूर्वनिर्धारित गेटवे हुँदा सत्य हुन्छ र होस्ट हातले कन्फिगर गरिएको बेला असत्य हुन्छ। फायरवालमा नीति-आधारित राउटिङले पनि निश्चित ट्राफिकका लागि तालिका उल्लंघन गर्न सक्छ, त्यसैले मार्ग गलत छ भनेर निष्कर्ष निकाल्नु अघि कुनै नियमले अर्को गेटवे छान्छ कि छैन जाँच्नुहोस्।

यो डिजाइनका लागि कुनै अनुवाद आवश्यक छैन, र क्लाइन्टको स्रोत ठेगाना देखिने राख्दा तल्लो नेटवर्कले आफ्नै नीति लागू गर्न सक्छ।

स्वीकृतिका लागि, एउटा नयाँ अनुरोधलाई सुरुङ प्रवेश, फायरवालको आन्तरिक निर्गमन र गन्तव्यबाट आउने जवाफबाट पुर्याएर हेर्नुहोस्। यदि त्यसको सट्टा जानाजानी अनुवाद प्रयोग गरिन्छ भने, तल्लो नेटवर्कले कुन स्रोत देख्छ र जवाफ कसरी फर्कने अपेक्षा छ भनी अभिलेख गर्नुहोस्।

तीन मालिकको योजना अनुमति दिइएको अनुप्रयोगसँगै सुरक्षित राख्नुहोस्, ताकि अर्को प्रशासकले मार्ग पुनः पत्ता लगाउनुको सट्टा पुनर्निर्माण गर्न सकोस्।