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 कीवर्ड के अस्तित्व से पहले लिखे गए मार्गदर्शिकाओं से कॉपी किए नियम-समुच्चय वर्तमान कर्नेल पर लोड नहीं होंगे, इसलिए वाक्य-रचना पोर्ट करें और अनुमान लगाने के बजाय त्रुटि पढ़ें।

वास्तविक नेटवर्कों के संपर्क में टिकने वाला निर्णय नियम छोटा है: जब संभव हो तो रिटर्न रूट स्थापित करें, जब न कर सकें तो अनुवाद करें, और लिख लें कि तीन शर्तों में से किसने आपसे यह चुनाव करवाया। वह टिप्पणी अगले व्यक्ति का एक पूरी दोपहर बचा लेती है।