टनल के ज़रिए दूर के /24 तक पहुँचना: NETMAP, DNAT या रूट?
NETMAP से पूरा प्रीफ़िक्स मैप करें, हर होस्ट के लिए DNAT नियम जोड़ें या असली रेंज को रूट करें, और इस आधार पर तय करें कि दूर की तरफ़ को क्या देखना है और कौन ट्रैफ़िक शुरू कर सकता है।
टनल एंडपॉइंट के पीछे की सबनेट तक तीन तरीक़ों से पहुँचा जा सकता है, और एक मिनट तथ्य जुटाने पर आम तौर पर दो रद्द हो जाते हैं। तथ्य ये हैं: क्या वहाँ के सर्वरों को उपयोगकर्ताओं में फ़र्क़ करना है, क्या वहाँ से कोई कभी आपकी रेंज की ओर डायल करेगा, और दूर के सिरे के राउटर को कौन संपादित कर सकता है। इन तीनों का जवाब दें और डिज़ाइन खुद चुन लिया जाएगा। बाक़ी मानता है कि आप एंडपॉइंट चलाते हैं और उसका फ़ायरवॉल संपादित कर सकते हैं।
तीन विकल्प, और हर एक असल में क्या बदलता है
प्रीफ़िक्स मैपिंग, प्रति-होस्ट DNAT और रूट किया गया प्रीफ़िक्स — सभी पैकेटों को उन्हीं दो रेंजों के बीच ले जाते हैं, पर अलग-अलग चीज़ें बदलते हैं। मैपिंग एक नक़ली एलियस रेंज बनाती है और उड़ान में पतों को अंकगणितीय ढंग से फिर से लिखती है। प्रति-होस्ट नियम भी फिर से लिखते हैं, बस हर गंतव्य का नाम हाथ से रखा जाता है। रूट किया गया प्रीफ़िक्स कुछ नहीं लिखता: पैकेट असली पते रखते हैं और दोनों सिरे सहमत होते हैं कि वे पते कहाँ रहते हैं।
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
बाहर निकालना दूर की तरफ़ से शुरू करें, जहाँ बाधाएँ बदलना सबसे कठिन है। अगर वहाँ का सर्वर क्लाइंट पते लॉग में लिखता है, उन्हें अनुमति-सूची से जाँचता है या किसी दूसरे सिस्टम को सौंपता है, तो स्रोत का अनुवाद उसकी एकमात्र पहचान नष्ट कर देता है। अगर दूर की तरफ़ को भी डायल करना है, तो अनुवाद पूरी तरह बाहर हो जाता है, क्योंकि वहाँ कोई नहीं जानता कि एलियस मौजूद है। सस्ते विकल्प तभी सुरक्षित होते हैं जब दूर की तरफ़ सिर्फ़ अनुरोधों का जवाब देती है।
प्रीफ़िक्स जोड़े, और आकार क्यों बराबर होने चाहिए
NETMAP nat तालिका का एक लक्ष्य है जो समान लंबाई के प्रीफ़िक्स जोड़े पर काम करता है। इसके अंदर प्रति-पता तालिका नहीं है: यह प्रीफ़िक्स हटाता है, होस्ट बिट्स रखता है और उन्हें नए प्रीफ़िक्स से फिर जोड़ता है, इसीलिए /24, /24 पर मैप होता है और कभी /25 पर नहीं। स्थिति दिशा तय करती है: PREROUTING में गंतव्य मेल फिर से लिखता है कि पैकेट कहाँ जा रहा है, और POSTROUTING में स्रोत मेल लिखता है कि वह कहाँ से आया।
192.168.2.17 का होस्ट आपके क्लाइंटों को 10.50.1.17 के रूप में दिखता है, और आख़िरी ऑक्टेट सजावट नहीं है — दोनों तरफ़ एक ही संख्या है। कल 192.168.2.40 पर एक होस्ट जोड़ें और उसका एलियस 10.50.1.40 होगा, बिना किसी नियम को संपादित किए।
क्लाइंटों को अभी भी एलियस रेंज के लिए आपके बॉक्स की ओर इशारा करने वाला रूट चाहिए, जब तक एलियस ऐसी सबनेट में न पड़े जहाँ वे पहले से पहुँचते हैं। गेटवे को एलियस के लिए रूट की ज़रूरत नहीं, क्योंकि गंतव्य अनुवाद रूट खोज से पहले PREROUTING में चलता है। फ़ॉरवर्डिंग भी चालू होनी चाहिए, वरना कर्नेल फिर से लिखने के बाद पैकेट गिरा देता है। नीचे के तीन कमांड Debian शैली के गेटवे पर पूरा सेटअप हैं, जहाँ क्लाइंट br0 पर, एलियस 10.50.1.0/24 पर और टनल tun0 पर है।
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEजवाब को खुद अपना वापसी रास्ता खोजना होगा
गंतव्य को फिर से लिखना सिर्फ़ तय करता है कि पैकेट कहाँ पहुँचाया जाएगा। दूर की तरफ़ के सर्वर को अभी भी ऐसे पते का जवाब देना है जहाँ वह पहुँच सके, और इसे व्यवस्थित करने के दो तरीक़े हैं। स्रोत का अनुवाद करें ताकि जवाब आपके बॉक्स पर लौटें, या स्रोत को अछूता छोड़ें और दूर की तरफ़ को क्लाइंट रेंज का रूट दें।
बाहर जाते समय मास्करेडिंग छोटा रास्ता है: POSTROUTING में एक नियम और दूर की तरफ़ आपका टनल पता देखती है, इसलिए उसे अपना रूट नहीं चाहिए। क़ीमत यह है कि सभी उपयोगकर्ता एक ही पते में मिल जाते हैं, और प्रति-उपयोगकर्ता लॉग का अर्थ ख़त्म हो जाता है। स्रोत को अछूता रखना वह जानकारी बचाता है, पर तब दूर की साइट को क्लाइंट रेंज के जवाब टनल से वापस भेजने पड़ते हैं। एक OpenVPN सर्वर पर यह भेजा गया push "route 10.50.9.0 255.255.255.0" है, साथ में एक पंक्ति route 192.168.2.0 255.255.255.0।
महँगी विफलता हर चीज़ का आधा करना है। अगर आप कुछ ट्रैफ़िक मास्करेड करते हैं जबकि दूर की तरफ़ दूसरे ट्रैफ़िक के लिए वापसी रूट भी रखती है, तो जवाब ऐसे इंटरफ़ेस पर आते हैं जहाँ कनेक्शन-ट्रैकिंग प्रविष्टि कभी नहीं देखी गई। क्लाइंट उस अनुरोध के लिए समय-समाप्ति बताता है जिसे सर्वर ने पूरा होने के रूप में दर्ज किया था। किसी प्रवाह की दोनों दिशाओं को एक ही netfilter इंस्टेंस से गुज़रना चाहिए: एक गेटवे अनुवाद कर रहा है, दो फ़ायरवॉल क्रम में नहीं।
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nप्रविष्टि को दोनों दिशाओं में पढ़ें: मूल टपल गंतव्य पर आपका एलियस रखता है, जबकि जवाबी टपल असली पता ले जाता है। अगर जवाबी टपल नहीं है, तो समस्या नियम में नहीं, वापसी रास्ते में है। अगर PREROUTING काउंटर कभी नहीं हिले, तो पैकेट उस हुक तक कभी पहुँचा ही नहीं।
टकराव और वह खोज जो पहले चलती है
दो अलग रेंज टकरा सकती हैं और दोनों विफलताएँ ख़राब नियम के बजाय टूटी टनल जैसी दिखती हैं। आप जो एलियस बनाते हैं वह पूरे रास्ते पर अप्रयुक्त होना चाहिए, और दूर की तरफ़ की असली रेंज आपके नेटवर्क पर पहले से मौजूद नहीं होनी चाहिए। दोहराव ग़लत होस्ट की ओर रुक-रुक कर ट्रैफ़िक पैदा करता है, जिसे अस्वीकृत कनेक्शन से अधिक कठिन जाँचा जाता है। नियम जोड़ने से पहले रूटिंग तालिका से पूछें।
गेटवे पर, ip route get 192.168.2.17 को टनल डिवाइस का नाम बताना चाहिए; स्थानीय ब्रिज का मतलब है कि दूर की रेंज छाया में है और कोई nat नियम उसे ठीक नहीं करेगा। अगर आपका अपना नेटवर्क पहले से 192.168.2.0/24 इस्तेमाल करता है, तो टकराव पर मैपिंग चढ़ाने के बजाय दूर की साइट को फिर से क्रमांकित करें।
असली क्लाइंट से जाँचना, फिर उसे बनाए रखना
ऐसी मशीन से जाँचें जो एलियस का सचमुच उपयोग करेगी, गेटवे से नहीं, क्योंकि स्थानीय रूप से बना ट्रैफ़िक कभी उसी तरह PREROUTING से नहीं गुज़रता। एलियस वाले एक होस्ट से कनेक्शन खोलें और काउंटरों तथा conntrack प्रविष्टि को साथ आते देखें, फिर उसे बंद करें और पुष्टि करें कि प्रविष्टि चली जाती है। पुरानी प्रविष्टि आधे-खुले कनेक्शन की ओर इशारा करती है, जिसका आम मतलब है कि जवाब कभी वापस नहीं आया।
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17दो या तीन सफल कनेक्शन अंकगणित साबित करते हैं, पर वे स्थायित्व या अगले इंजीनियर के बारे में कुछ नहीं कहते। नियम वहाँ सहेजें जहाँ बूट प्रक्रिया उन्हें पढ़ती है, जो Debian और Ubuntu पर iptables-save > /etc/iptables/rules.v4 और netfilter-persistent सक्षम होने का अर्थ है। रीबूट पर गायब होने वाली मैपिंग बिलकुल न होने से बुरी है, क्योंकि रुकावट किसी हाल के बदलाव के बिना आती है जिसे दोष दिया जा सके।
नियमों के पास एक टिप्पणी छोड़ें: एलियस रेंज, असली रेंज, जोड़ी का कारण और कौन सी तरफ़ शुरू कर सकती है। वह टिप्पणी डिज़ाइन को ऐसे नियमों के ढेर से अलग करती है जिन्हें कोई मिटाने की हिम्मत नहीं करता। यह बाद के सवाल का भी फ़ैसला करती है, जब दूर की साइट एक होस्ट जोड़ती है और कोई ऐसा पता जिसे किसी ने कॉन्फ़िगर नहीं किया, पहले से जवाब दे रहा होता है। अगर टिप्पणी कहती है कि दूर की तरफ़ को वापसी रूट चाहिए, तो अगला व्यक्ति जानता है कि मास्करेड नियम हटाने से कनेक्टिविटी टूटती है। यहाँ दस्तावेज़ीकरण सस्ता है; रात तीन बजे NAT निर्भरता को फिर से खोजना नहीं।