टनेलमधून दूरच्या /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 अवलंबित्व पुन्हा शोधणे स्वस्त नाही।