टनेलमार्फत टाढाको /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 मा चल्छ। फर्वार्डिङ पनि खुला हुनुपर्छ, नत्र कर्नेलले पुनर्लेखनपछि प्याकेट फ्याँक्छ। तलका तीन आदेश ग्राहकहरू br0 मा, उपनाम 10.50.1.0/24 मा र टनेल tun0 मा रहेको Debian शैलीको गेटवेमा पूरै कन्फिगरेसन हुन्।
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जवाफले आफैं फर्कने बाटो खोज्नुपर्छ
गन्तव्य पुनर्लेखनले प्याकेट कहाँ पुर्याइन्छ मात्र तय गर्छ। टाढाको सर्भरले अझै आफू पुग्न सक्ने ठेगानामा जवाफ दिनुपर्छ, र त्यो मिलाउने दुई तरिका छन्। जवाफहरू तपाईंको बाक्समा फर्कन स्रोत अनुवाद गर्नुहोस्, वा स्रोत जस्ताको तस्तै राखेर टाढाको पक्षलाई ग्राहक दायराको रुट दिनुहोस्।
बाहिर जाने बाटोको masquerade छोटो मार्ग हो: POSTROUTING मा एउटा नियम र टाढाको पक्षले तपाईंको टनेल ठेगाना देख्छ, त्यसैले आफ्नै रुट चाहिँदैन। मूल्य यो हो कि हरेक प्रयोगकर्ता एउटै ठेगानामा खुम्चिन्छ, र प्रयोगकर्ता-अनुसारका लगको अर्थ सकिन्छ। स्रोत अक्षुण्ण राख्दा त्यो जानकारी रहन्छ, तर त्यसपछि टाढाको साइटले ग्राहक दायराका जवाफहरू टनेलबाट फर्काउनुपर्छ।OpenVPN सर्भरमा त्यो push गरिएको push "route 10.50.9.0 255.255.255.0", साथै route 192.168.2.0 255.255.255.0 लाइन हो।
महँगो असफलता भनेको प्रत्येकको आधा गर्नु हो। केही ट्राफिक masquerade गर्दा टाढाको पक्षले अर्को ट्राफिकका लागि फर्कने रुट पनि बोकेको छ भने, जवाफहरू त्यस्तो इन्टरफेसमा आउँछन् जहाँ कनेक्सन ट्र्याकिङ प्रविष्टि कहिल्यै देखिएको थिएन। सर्भरले सेवा दिएको भनी लेखेको अनुरोधका लागि ग्राहकले टाइमआउट रिपोर्ट गर्छ। प्रवाहका दुवै दिशाले एउटै netfilter इन्स्ट्यान्स पार गर्नुपर्छ: एउटा गेटवेले अनुवाद गर्छ, शृंखलामा दुई फायरवाल होइन।
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nप्रविष्टि दुवै दिशाबाट पढ्नुहोस्: मूल tuple ले गन्तव्यमा तपाईंको उपनाम राख्छ, जबकि जवाफ tuple ले वास्तविक ठेगाना बोक्छ। जवाफ tuple छैन भने समस्या नियम होइन, फर्कने बाटो हो। PREROUTING काउन्टरहरू कहिल्यै सरेनन् भने प्याकेट त्यो hook सम्म पुगेन।
टक्करहरू र पहिले चल्ने खोजी
दुई फरक दायरा ठोक्किन सक्छन्, र दुवै असफलता खराब नियमभन्दा बिग्रिएको टनेलजस्तो देखिन्छन्। तपाईंले बनाउने उपनाम पूरै बाटोमा अप्रयुक्त हुनुपर्छ, र वास्तविक टाढाको दायरा तपाईंको नेटवर्कमा पहिले नै हुनुहुँदैन। दोहोरोले बेलाबखत गलत होस्टतर्फ ट्राफिक उत्पन्न गर्छ, जसलाई अस्वीकृत कनेक्सनभन्दा पहिचान गर्न कठिन हुन्छ। नियम थप्नुअघि रुटिङ तालिकालाई सोध्नुहोस्।
गेटवेमा, ip route get 192.168.2.17 ले टनेल उपकरणको नाम बताउनुपर्छ; स्थानीय bridge भनेको टाढाको दायरा छायामा परेको हो र कुनै 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 सक्षम गरेर हो। रिबुटमा हराउने म्यापिङ नभएकोभन्दा नराम्रो हुन्छ, किनकि अवरोध दोष दिनसक्ने हालैको परिवर्तनबिना आउँछ।
नियमहरूको छेउमा टिप्पणी छोड्नुहोस्: उपनाम दायरा, वास्तविक दायरा, जोडीको कारण र कुन पक्षले सुरु गर्न सक्छ। त्यो टिप्पणीले डिजाइनलाई कसैले मेट्ने आँट नगर्ने नियमहरूको थुप्रोबाट छुट्याउँछ। यसले पछिको प्रश्न पनि टुंग्याउँछ: टाढाको साइटले होस्ट थप्दा कसैले कन्फिगर नगरेको ठेगाना पहिले नै जवाफ दिन्छ। टिप्पणीले टाढाको पक्षलाई फर्कने रुट चाहिन्छ भन्छ भने, अर्को व्यक्तिले masquerade नियम हटाउँदा जडान टुट्छ भन्ने जान्छ। यहाँ कागजात सस्तो छ; राति तीन बजे NAT निर्भरता फेरि पत्ता लगाउनु सस्तो छैन।