मास्करेड की धोरण-आधारित राउटिंग: VPN गेटवेमार्फत LAN रहदारी

संपूर्ण LAN VPN टनेलमागे ठेवणे सोपा भाग आहे; दूरची बाजू त्या क्लायंटना कसे पाहते हे ठरवणे सोपे नाही। मास्करेड प्रत्येक LAN स्रोत गेटवेच्या टनेल पत्त्यावर पुन्हा लिहितो, त्यामुळे दूरची बाजू एका पीअरला उत्तर देते। धोरण-आधारित राउटिंग मूळ पत्ते टिकवते आणि दूरच्या बाजूने त्यांच्यापर्यंत कसे पोहोचायचे हे माहीत असणे आवश्यक करते। दोन्हीपैकी कोणतेही डीफॉल्ट नाही; निवड दूरची बाजू कोणाची आहे आणि प्रति-उपकरण ओळख महत्त्वाची आहे का यावर अवलंबून असते।

दोन्ही रचना वेगवेगळ्या गोष्टींचे वचन देतात

मास्करेड LAN एका दिसणाऱ्या होस्टपर्यंत कमी करतो: गेटवे। दूरचे नेटवर्क त्या एकाच पत्त्याला उत्तर देते, आणि गेटवे उत्तरे प्रवाह सुरू करणाऱ्या क्लायंटकडे परत भाषांतरित करतो। दूरच्या बाजूला तुमच्या खाजगी प्रीफिक्ससाठी मार्गाची गरज नसते, म्हणूनच ही रचना ते वाहून नेण्यास नकार देणाऱ्या प्रदात्यासोबतही टिकते। गेटवे प्रत्येक कनेक्शनचा स्रोत होतो, त्यामुळे दूरची बाजू दोन क्लायंटमध्ये फरक करू शकत नाही।

धोरण-आधारित राउटिंग प्रत्येक क्लायंटचा पत्ता अभंग ठेवते। दूरचे नेटवर्क खरा स्रोत पाहते आणि तो लॉग करू शकते, प्रति-होस्ट नियम लागू करू शकते किंवा उत्तर थेट त्या पत्त्यावर पाठवू शकते। हीच दृश्यता संपूर्ण मुद्दा आहे, आणि ती एका जबाबदारीसह येते: दूरच्या बाजूकडे LAN प्रीफिक्ससाठी टनेलमधून परत जाणारा मार्ग असला पाहिजे। नियम सुरू करण्यापूर्वी तो मार्ग नियोजित करा, कारण टनेल काहीही झाले तरी वर येईल आणि फक्त उत्तरेच कमी पडतील।

अपयशाच्या पद्धती वचनांइतक्याच वेगळ्या आहेत। अनुपस्थित मास्करेड नियम खाजगी स्रोतांसह बाहेर पडणारे आणि कधीही परत न येणारे पॅकेट तयार करतो। अनुपस्थित परतीचा मार्ग धोरण-आधारित राउटिंगमध्ये तेच लक्षण देतो, पण दुरुस्ती गेटवेवर नाही, दूरच्या राउटरवर करायची असते।

मास्करेड: दूरच्या बाजूला एकच पीअर

मास्करेडच्या मार्गाला महत्त्वाचा क्रम आहे। कोणताही NAT नियम उपयोगी होण्यापूर्वी फॉर्वर्डिंग सुरू असले पाहिजे, फिल्टर टेबलने दोन्ही दिशांनी जाण्यास परवानगी दिली पाहिजे, आणि त्यानंतरच टनेल इंटरफेसवर भाषांतर लागू होते।

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

क्लायंटना अजूनही गेटवेपर्यंत मार्ग हवा आहे। एकतर गेटवे त्यांचा डीफॉल्ट राउटर आहे, किंवा ते दूरच्या प्रीफिक्ससाठी विशिष्ट मार्ग बाळगतात; जर वेगळा राउटर डीफॉल्ट राहिला, तर त्या राउटरला टनेलच्या गंतव्यांसाठी स्थिर मार्ग हवा, नाहीतर गेटवे पाहण्यापूर्वी पॅकेट चुकीच्या हॉपवर जाते।

DNS हा वेगळा निर्णय आहे। दूरच्या बाजूचा रिझॉल्व्हर त्याचे उत्तर क्लायंटपर्यंत परत जाऊ शकले तरच उत्तर देतो। मास्करेडमध्ये क्वेरी गेटवेकडून आल्यासारखी दिसते, त्यामुळे रिझॉल्व्हरचा परतीचा मार्ग आधीच पूर्ण आहे; धोरण-आधारित राउटिंगमध्ये रिझॉल्व्हरला इतर कोणत्याही दूरच्या सेवेसारखाच परतीचा मार्ग हवा।

धोरण-आधारित राउटिंग: स्रोत ठेवा, परतीचा मार्ग जोडा

धोरण-आधारित राउटिंग टेबल आणि ती निवडणाऱ्या नियमाने सुरू होते। LAN इंटरफेसवरून येणारी रहदारी समर्पित टेबलकडे पाठवली जाते, आणि ती टेबल टनेलमधून डीफॉल्ट मार्ग बाळगते। मुख्य टेबल अस्पर्शित राहते, त्यामुळे गेटवेनेच निर्माण केलेली रहदारी वेगळ्या मार्गाने जाऊ शकते।

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

त्यानंतर दूरच्या बाजूने LAN प्रीफिक्स टनेलमधून परत राउट केला पाहिजे। हे या गेटवेवर नाही, दूरच्या राउटरवरचे संरचना आहे। गेटवेने मुख्य टेबल अपेक्षित असलेल्या पेक्षा वेगळ्या इंटरफेसवर येणारी उत्तरेही स्वीकारली पाहिजेत; कडक मोड ती पॅकेट टाकून देतो तेव्हा सैल उलट-मार्ग फिल्टरिंग (rp_filter 2 वर सेट) नेहमीचे समायोजन आहे।

दोन टनेल सक्रिय असताना प्रत्येक प्रवाह प्रवेशाच्या वेळी टॅग करा आणि टॅगला टेबल निवडू द्या। फक्त इनपुट इंटरफेस पाहणारा नियम दोन्ही टनेलची रहदारी एकाच टेबलकडे पाठवतो, त्यामुळे दुसरे टनेल पहिल्याचे प्रवाह चोरते। तो टॅग पुन्हा जोडणी टिकून राहणाऱ्या कनेक्शनने तपासा, कारण तेव्हाच मिश्र धोरण समोर येते।

मालकी आणि दूरची बाजू काय लॉग करते यावरून ठरवा

जर टनेल प्रदात्याकडे संपत असेल, तर मास्करेड वापरा। तो ऑपरेटर तुमच्या खाजगी LAN श्रेणी राउट करणार नाही, आणि तुमच्या गेटवेमागील वैयक्तिक क्लायंटमध्ये फरक करण्याचे कारण त्याच्याकडे नाही। एक दिसणारा पीअर हाच त्याचे धोरण समर्थन देणारा एकमेव नमुना आहे, म्हणून तोच द्या आणि भाषांतर तुमच्या काठावर ठेवा। प्रदाता एक पीअर पाहतो, जे त्याचे धोरण नेमके अपेक्षित असते, आणि तुमचे क्लायंट ती एकच ओळख वारसा घेतात।

जर दोन्ही टोके तुमची असतील आणि दूरच्या सेवा स्रोत पत्त्यांवर कार्य करत असतील, तर धोरण-आधारित राउटिंग आपल्या अतिरिक्त मार्गास पात्र आहे। तेव्हा फायरवॉल नियम, प्रति-वापरकर्ता प्रवेश आणि ऑडिट लॉग क्लायंटमध्ये फरक करू शकतात। जर दूरच्या बाजूला फक्त पोहोचण्याची गरज असेल, तर मास्करेड सोपे आहे आणि परतीच्या मार्गाच्या चुकांचा एक वर्ग दूर करते।

संकरित रचना सामान्य आहेत: तुमच्या नेटवर्कमध्ये धोरण-आधारित राउटिंग, प्रदात्याच्या काठावर मास्करेड। महत्त्वाचे म्हणजे कोणता हॉप भाषांतर करतो आणि कोणता हॉप राउट करतो हे लिहून ठेवणे, कारण एका क्लायंटसाठी अपघाताने जोडलेला NAT नियम त्याच साखळीतील प्रत्येक क्लायंटचा स्रोत लपवतो।

एका क्लायंटकडून तपासा, नंतर दुसऱ्या क्लायंटकडून

रहदारी सुरू होते तिथे चाचणी चालवा। होस्ट वापरतो तो मार्ग तपासा, टनेल इंटरफेसवर पॅकेट दिसू लागल्याचे पहा, आणि भाषांतरासाठी conntrack तपासा। हा क्रम सिद्ध करतो की पॅकेटने इच्छित मार्ग घेतला, फक्त कुठेतरी पोहोचले नाही।

पुन्हा जोडणीनंतर चाचणी पुन्हा करा। इंटरफेसचे नाव घेणारा मास्करेड नियम नवीन टनेल पत्त्यावर टिकतो; जुन्या पत्त्याचे नाव घेणारा नियम टिकत नाही। नंतर दुसरा LAN होस्ट तपासा, कारण एका मशीनवर चालणारी रचना अनेकदा त्या मशीनच्या स्वतःच्या मार्गावर अवलंबून असते, गेटवेच्या धोरणावर नाही।

निवडलेला नमुना, भाषांतरित किंवा जतन केलेला स्रोत आणि परतीच्या मार्गाचा मालक गेटवेच्या टिपांमध्ये लिहा। नाहीतर क्लायंट किंवा टनेल जोडणारी पुढची व्यक्ती अंदाज लावेल, आणि अंदाज हाच चालणाऱ्या LAN-ते-VPN संरचनेला अर्धवट बनवण्याचा मार्ग आहे।