OpenBSD VPN गेटवेमा tun0 मार्फत LAN को NAT

एउटै OpenBSD गेटवे भएका दुई इन्जिनियरले टाढाको सञ्जालमा पुग्न तपाईंलाई प्रायः दुई फरक नियमसङ्ग्रह दिन्छन्, र दुवैको बचाउ गर्न सकिन्छ। स्रोत अनुवाद र फिर्ता मार्गबीचको छनोट वाक्यरचनाको प्रश्न नै होइन। यो अर्को पक्षले 192.168.88.0/24 बारे पहिले नै के जान्दछ र तपाईंले लगमा के राख्नुपर्छ भन्नेमा निर्भर गर्दछ। यहाँ गल्ती गरे nat-to लाइन पूर्ण रूपमा सही देखिनेछ तर जवाफहरू टाढाको पूर्वनिर्धारित गेटवेमा हराउनेछन्।

रुटिङ र पुनर्लेखन फरक प्रश्नको जवाफ दिन्छन्

रुटिङ तालिकाले 172.20.0.0/16 tun0 मार्फत पुग्न सकिने निर्णय गर्छ, र त्यो निर्णय कुनै पनि pf अनुवादसँग परामर्श गर्नुअघि हुन्छ। त्यसपछि स्रोत अनुवादले प्याकेट हेडर बदल्छ, जसले गर्दा टाढाको छेउले LAN होस्टको सट्टा गेटवेको टनेल ठेगाना देख्छ। कुनै पनि संयन्त्रले अर्कोको ठाउँ लिँदैन: nat नियमले मार्ग सिर्जना गर्न सक्दैन, र मार्गले तपाईंको निजी सबनेटबारे कहिल्यै नसुनेको टाढाको राउटरलाई मनाउन सक्दैन। अर्को पक्षसँग फिर्ता बाटो नभए जवाफहरू त्यागिन्छन् वा उसको पूर्वनिर्धारित गेटवेतर्फ पठाइन्छन्, र नियम जतिसुकै मिलाए पनि त्यो सुध्रिँदैन।

सरल भाषामा, फर्वार्डिङले ट्राफिक कहाँ जान्छ भन्ने जवाफ दिन्छ र अनुवादले त्यो कहाँबाट आएजस्तो देखिन्छ भन्ने जवाफ दिन्छ। नियमसङ्ग्रह डिजाइन गर्दा दुवैलाई छुट्टाछुट्टै मानसिक बाकसमा राख्नुहोस्।

निर्णय गर्ने तीन सर्त

तीन प्रश्न क्रमैसँग सोध्नुहोस् र डिजाइन प्रायः आफै छानिन्छ। टाढाको सञ्जालसँग 192.168.88.0/24 का लागि टनेल ठेगानातर्फ सङ्केत गर्ने स्थिर मार्ग छ कि त्यसको प्रशासकले त्यो बाटोका राउटरहरू नियन्त्रण गर्छ? यदि हो भने LAN ठेगानाहरूलाई नबदली जान दिनुहोस् र अनुवाद पूर्ण रूपमा छोड्नुहोस्। अर्को पक्षमा प्रत्येक क्लाइन्टको दृश्यता चाहिन्छ कि, पहुँच नीतिका लागि वा लेखापरीक्षणको लागि? यदि चाहिन्छ भने स्रोत जोगाउनु रुटिङको कामको लायक छ। टनेल ठेगाना टाढाको मार्गमा लेख्न पुग्ने स्थिर छ कि पुनः जडानहरूबीच बदलिन्छ?

कुनै पनि जवाफ होइन वा अज्ञात भए nat-to व्यावहारिक विकल्प हो, र त्यो फर्काउन पनि सकिन्छ। अर्को पक्षले उपयुक्त मार्ग थप्ने बित्तिकै अनुवाद नियम एकै लाइनमा हट्छ। कहिल्यै स्थापना नगरिएको फिर्ता मार्गले टनेल किन एउटै दिशामा मात्र चल्छ भनी कसैले सोध्ने हरेक पटक एउटा समर्थन धागो खान्छ।

pf ले साँच्चै मूल्याङ्कन गर्ने ठाउँमा टुक्रा राख्नुहोस्

तलको टुक्राले LAN 192.168.88.0/24, टाढाको सञ्जाल 172.20.0.0/16 र टनेल इन्टरफेस tun0 मान्दछ। यसमा अर्को हप छान्ने केही छैन। यसले पहिले नै टनेलबाट बाहिर जाँदै गरेका प्याकेटमा स्रोत मात्र पुनः लेख्छ।

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

त्यो पहिलो लाइनका दुई विवरणले सबैभन्दा बढी भार बोक्छन्। tun0 वरिपरिका कोष्ठकहरूले pf लाई स्थिति प्रविष्टि बनाउने हरेक पटक इन्टरफेस ठेगाना पढ्न भन्छन्, जुन पुनः जडानपछि टनेल पुनः नम्बरिङ हुँदा महत्त्वपूर्ण हुन्छ। match शब्दको अर्थ नियमले पुनः लेख्छ र त्यसपछि तल खस्छ भन्ने हो, त्यसैले छुट्टै pass नियमले अझै प्रवाहलाई अनुमति दिनुपर्छ। match लाइनमा नाम दिइएको इन्टरफेस पनि रुटिङ तालिकाले छान्ने इन्टरफेस नै हुनुपर्छ, नत्र pf ले नियमलाई प्याकेट साँच्चै जाने बाटोभन्दा फरक निकास मार्गमा मूल्याङ्कन गर्छ।

कर्नेल पक्ष नबिर्सनुहोस्। IPv4 फर्वार्डिङ सक्षम हुनुपर्छ, र टनेल तथा LAN का लागि स्थितियुक्त pass नियमहरू यी सबैको अर्थ हुनुअघि हुनुपर्छ। यहाँ किवर्डको क्रमका लागि OpenBSD FAQ को PF NAT खण्ड उपयुक्त सन्दर्भ हो।

ट्राफिकमा भरोसा गर्नुअघि नियमसङ्ग्रह प्रमाणित गर्नुहोस्

पहिले pfctl -nf /etc/pf.conf ले वाक्यरचना जाँच्नुहोस्, जसले फाइल नलोड गरी विश्लेषण गर्छ। त्यसपछि नीति लोड गर्नुहोस् र कर्नेलले साँच्चै के राख्छ पढ्नुहोस्, किनकि सफा रूपमा विश्लेषण भएको नियम पनि छायामा पर्न वा गलत इन्टरफेसमा जोडिन सक्छ। pfctl -sn ले अनुवाद नियमहरू लोड भएको रूपमा छाप्छ, र pfctl -sr ले फिल्टर नियमहरू मूल्याङ्कन क्रममा छाप्छ।

अनि तारमा नजर राख्नुहोस्। गेटवेमा tcpdump -ni tun0 'host 172.20.0.10' ले टनेलबाट बाहिर निस्कने स्रोत ठेगाना टनेल ठेगाना हो कि LAN होस्ट भनेर देखाउँछ। छिटो netstat -rn -f inet ले गन्तव्य कुन इन्टरफेसमा समाधान हुन्छ पुष्टि गर्छ। ट्राफिक बहन थालेपछि pfctl -ss ले स्थिति प्रविष्टिहरू सूचीबद्ध गर्छ; कुनै प्रवाहले स्थिति बनाएन भने प्याकेट कहिल्यै स्थिति बनाउने नियममा परेन।

टनेल पक्ष सही देखिन्छ तर जवाफ आउँदैन भने pf सम्पादन गर्न छोड्नुहोस्। बाँकी खराबी टाढाको राउटरमा छ, जहाँ जवाफ त्यो पक्षले पुग्न नसक्ने निजी ठेगानातर्फ पठाइँदै छ।

जब अनुवादले बचतभन्दा बढी खर्च गर्छ

अनुवादले क्लाइन्टहरू लुकाउँछ, र कहिलेकाहीँ त्यो ठ्याक्कै गलत सम्झौता हुन्छ। एकअर्कामा पर्ने सबनेटहरू एउटा अवस्था हो: यदि अर्को पक्षले आन्तरिक रूपमा 192.168.88.0/24 पनि प्रयोग गर्छ भने LAN होस्टहरूलाई गेटवेका रूपमा प्रस्तुत गर्नाले ठक्कर सुधार्नुको सट्टा बिगार्छ। ठेगाना जोडीका आधारमा ट्राफिक छान्ने IPsec नीतिहरू अर्को अवस्था हुन्, किनकि सुरक्षा नीति डेटाबेस अनुवादअघि मिलाइन्छ र तपाईंको पुनर्लेखित प्याकेट कहिल्यै देख्दैन। प्रत्येक प्रयोगकर्ताका लागि बिल गर्ने, सीमित गर्ने वा लेखापरीक्षण गर्ने कुनै पनि तैनाथीले पनि स्रोत एउटै ठेगानामा खुम्चिने क्षणमा आवश्यक पहिचान गुमाउँछ।

पोर्टेबल pf व्युत्पन्नहरू छुट्टै जाल हुन्। आफ्नै नियम फाइल बनाउने उत्पादनहरूले NAT आफ्नो इन्टरफेसबाट कन्फिगर हुने अपेक्षा गर्छन्, र हातले सम्पादन गरिएका टुक्राहरू अर्को रिलोडमा अधिलेखन हुन्छन्। match किवर्ड अस्तित्वमा आउनुअघि लेखिएका मार्गदर्शनबाट प्रतिलिपि गरिएका नियमसङ्ग्रहहरू वर्तमान कर्नेलमा लोड हुँदैनन्, त्यसैले वाक्यरचना पोर्ट गर्नुहोस् र अनुमान गर्नुको सट्टा त्रुटि पढ्नुहोस्।

वास्तविक सञ्जालसँगको सम्पर्कमा टिक्ने निर्णय नियम छोटो छ: सक्नुहुँदा फिर्ता मार्ग स्थापना गर्नुहोस्, नसक्दा अनुवाद गर्नुहोस्, र तीन सर्तमध्ये कुनले तपाईंलाई त्यो छनोट गरायो लेख्नुहोस्। त्यो टिप्पणीले अर्को व्यक्तिको आधा दिन बचाउँछ।