साइट-से-साइट बनाम रिमोट एक्सेस VPN: दोनों क्या जोड़ते हैं
एक गेटवे जोड़ता है, दूसरा डिवाइस जोड़ता है। ट्रैफ़िक सेलेक्टरों की तुलना रूट से करें, एड्रेसिंग की योजना बनाएँ, फिर किसी वास्तविक होस्ट से फ़ॉरवर्डिंग और नीति जाँचें।
दोनों डिज़ाइनों को VPN कहा जाता है और वे अलग-अलग समस्याएँ हल करते हैं। साइट-से-साइट टनल दो गेटवे जोड़ती है, इसलिए उनके पीछे का हर होस्ट बिना कुछ इंस्टॉल किए दूसरी ओर के अनुमत पतों तक पहुँच सकता है। रिमोट-एक्सेस टनल अलग-अलग डिवाइसों को एक नेटवर्क से जोड़ती है, एक बार में एक क्लाइंट। यह तुलना ज़रूरी है क्योंकि ज़्यादातर परिनियोजन गलतियाँ एक को कॉन्फ़िगर करके दूसरे के व्यवहार की अपेक्षा करने से होती हैं, और लक्षण आमतौर पर ऐसी सेवा में टाइमआउट होता है जहाँ टनल वास्तव में पहुँची थी।
दो डिज़ाइन, दो सीमाएँ
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
कोई भी डिज़ाइन LAN ब्रॉडकास्ट डोमेन नहीं बढ़ाता। दूसरी ओर के डिवाइस स्थानीय खोज सूची में नहीं दिखते, और ऐसी अपेक्षा करना पहली मान्यता है जिसे छोड़ना चाहिए। आप जो निजी DNS नाम जानबूझकर प्रकाशित करते हैं वे किसी भी खोज प्रोटोकॉल से अधिक अनुमानित हैं, और वे आपूर्तिकर्ता बदलने पर भी टिके रहते हैं।
एक साइट पर 10.10.0.0/24 और दूसरी पर 10.20.0.0/24 लें। गेटवे A को ऐसा रूट या ट्रैफ़िक सेलेक्टर चाहिए जो 10.20.0.0/24 प्रीफ़िक्स को टनल में भेजे, और गेटवे B को उसका दर्पण प्रतिबिंब चाहिए। फिर दोनों ओर के होस्ट सामान्य IP कनेक्टिविटी का उपयोग करते हैं और कभी नहीं जानते कि कोई टनल मौजूद है। यही अदृश्यता विशेषता है, और इसीलिए विफलताएँ टनल की गलतियों के बजाय सामान्य नेटवर्क गलतियों जैसी दिखती हैं।
नीति-आधारित और रूट-आधारित एक ही टनल नहीं हैं
नीति-आधारित IPsec परिनियोजन में, बातचीत किए गए ट्रैफ़िक सेलेक्टर ठीक-ठीक तय करते हैं कि कौन-से स्रोत और गंतव्य जोड़े सुरक्षित हैं। अगर किसी गेटवे के पीछे नया सबनेट दिखाई दे और कोई सेलेक्टर उसे न ढके, तो टनल चालू रहती है और नया सबनेट बस नहीं ले जाया जाता। रूट-आधारित डिज़ाइन में इंटरफ़ेस ट्रैफ़िक लेता है और रूटिंग तालिका निर्णय करती है, जिससे प्रीफ़िक्स जोड़ना टनल की फिर से बातचीत नहीं बल्कि रूट परिवर्तन बन जाता है।
StrongSwan दोनों दृश्य सीधे दिखाता है, और उन्हें साथ पढ़ना ही यह पता लगाने का तरीका है कि आपने वास्तव में कौन-सा मॉडल परिनियोजित किया है।
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'ऐसी सेलेक्टर सूची जिसमें आपका ज़रूरी प्रीफ़िक्स छूट गया है, बिना किसी पैकेट कैप्चर के विफलता समझाती है, और गलत इंटरफ़ेस की ओर इशारा करता रूट वापसी मार्ग की दर्पण-विफलता समझाता है। कुछ भी फिर से तय करने से पहले दोनों पढ़ें, क्योंकि कुंजी नवीनीकरण ऐसा सेलेक्टर नहीं जोड़ेगा जिसे आपने कभी कॉन्फ़िगर नहीं किया।
टनल से पहले एड्रेसिंग की योजना बनाएँ
अतिव्यापी रेंज वह डिज़ाइन गलती है जिसे कॉन्फ़िगरेशन से ठीक नहीं किया जा सकता। अगर दोनों साइटें 192.168.1.0/24 इस्तेमाल करती हैं, तो 192.168.1.50 चाहने वाले होस्ट के पास दो उम्मीदवार हैं और चुनने का कोई तरीका नहीं। टनल प्रमाणीकरण करेगी, सुरक्षा संबद्धताएँ स्थापित होंगी, और रूटिंग निर्णय फिर भी गलत या अस्पष्ट ही रहेगा।
तीन ईमानदार विकल्पों में से एक चुनें: एक साइट का पुनःक्रमांकन करें, गेटवे पर अतिव्यापी रेंज का अनुवाद करें ताकि हर पक्ष अलग प्रीफ़िक्स देखे, या उन होस्टों के लिए सीधी रूटिंग छोड़ दें और सेवा को किसी और तरीके से प्रकाशित करें। हर एक की लागत है, और दो साल के क्षितिज पर पहला आमतौर पर सबसे सस्ता है। टनल बनने से पहले तय करें, क्योंकि बाद में यह बदलाव पुराने पते वाले हर डिवाइस को छूता है।
MTU का सवाल भी जल्दी सुलझाएँ। टनल उपयोगी पेलोड घटाती है, और विखंडन पर निर्भर डिज़ाइन गेटवे पर MSS स्थिर करने वाले डिज़ाइन से अलग व्यवहार करता है।
फ़ॉरवर्डिंग और नीति टनल के बाहर रहते हैं
गेटवे को टनल इंटरफ़ेस और LAN इंटरफ़ेस के बीच पैकेट फ़ॉरवर्ड करने को तैयार होना चाहिए, और दोनों दिशाओं को ऐसी नीति चाहिए जो सेवा की अनुमति दे। Linux में ये दो अलग सेटिंग हैं, साथ में फ़ायरवॉल नियम जो तय करते हैं कि फ़ॉरवर्ड किया गया प्रवाह बिल्कुल अनुमत है या नहीं।
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTप्राप्त करने वाला होस्ट तीसरी परत जोड़ता है: उसके अपने फ़ायरवॉल को अभी भी दूरस्थ सबनेट से आने वाला क्लाइंट स्वीकार करना होगा। जो फ़ाइल सर्वर केवल अपना स्थानीय /24 अनुमत करता है वह 10.20.0.7 से फ़ॉरवर्ड किया गया ट्रैफ़िक अस्वीकार करेगा, चाहे टनल कितनी भी स्वस्थ दिखे, और उस अस्वीकृति को रूटिंग विफलता के रूप में पढ़ना आसान है।
गेटवे से नहीं, होस्ट से परखें
गेटवे द्वारा भेजा गया ping फ़ॉरवर्ड किए गए उपयोगकर्ता ट्रैफ़िक से अलग स्रोत पता और अलग नीति अपना सकता है। इससे वह कमज़ोर परीक्षण बनता है और कभी-कभी भ्रामक भी: यह सफल होता है जबकि ऐप विफल होता है, या विफल होता है जबकि ऐप काम करता है।
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullवास्तविक होस्ट, वास्तविक स्रोत पता और वही वास्तविक प्रोटोकॉल इस्तेमाल करें जो ऐप उपयोग करता है। फिर वापसी मार्ग अलग से पढ़ें, क्योंकि वापसी रूट के बिना काम करती आगे की दिशा ऐसा टाइमआउट पैदा करती है जो अवरुद्ध सेवा जैसा ही दिखता है।
डिज़ाइन उस सवाल के हिसाब से चुनें जिसका आप जवाब दे रहे हैं: आप नेटवर्क जोड़ रहे हैं या डिवाइस स्वीकार रहे हैं? बाकी सब, किस आपूर्तिकर्ता को कॉन्फ़िगर करें यह भी, उसी जवाब से निकलता है।