LAN राउटर और VPN क्लाइंट: दो डिवाइस, दो रूट टेबल

दो डिवाइस पैकेट आगे भेजते हैं और हर एक अपनी टेबल रखता है। LAN राउटर जानता है कि दूर का प्रीफ़िक्स VPN क्लाइंट का है, और VPN क्लाइंट जानता है कि उस प्रीफ़िक्स तक अपने टनल से कैसे पहुँचना है। केवल पहली टेबल कॉन्फ़िगर करें और पैकेट ऐसी मशीन पर पहुँचता है जिसके पास कोई मेल खाता रूट नहीं है, इसलिए वह फिर डिफ़ॉल्ट से बाहर चला जाता है। पूरी खराबी यही है, और LAN की ओर से यह रूटिंग लूप जैसी दिखती है, क्योंकि लगभग वही है।

किसी रूट को छूने से पहले दोनों हॉप खींचें

एक उदाहरण लेआउट लें: LAN होस्ट 192.168.50.0/24 पर, सामान्य राउटर 192.168.50.1 पर, एक समर्पित क्लाइंट 192.168.50.15 पर, और दूर का LAN 10.60.0.0/24 पर जो केवल उस टनल से पहुँचा जा सकता है जो वह क्लाइंट रखता है। दोनों निजी रेंज में से कोई भी दूसरे को ओवरलैप नहीं करती, और टनल का अपना एड्रेस प्लान है।

दोनों निजी रेंज मायने रखती हैं क्योंकि वे तय करती हैं कि कौन-सा डिवाइस जवाब दे सकता है। दूर की ओर पैकेट को क्लाइंट के टनल एड्रेस से आते देखेगी, और उसके जवाब को 192.168.50.0/24 तक वापस जाने का रास्ता खोजना होगा। अगर केवल बाहर जाने की दिशा कॉन्फ़िगर है, तो अनुरोध काम कर सकता है जबकि जवाब गायब हो जाता है।

चरण 1: राउटर को टनल की ओर नहीं, क्लाइंट की ओर इंगित करें

LAN राउटर पर एक गंतव्य रूट जोड़ें जिसका अगला हॉप क्लाइंट का LAN एड्रेस है:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

वह रिकॉर्ड कहता है “इसे उस मशीन तक पहुँचाओ जो टनल कर सकती है”। यह नहीं बताता कि टनल कैसे बनता है, और यह क्लाइंट के अपने रूट का विकल्प नहीं है। मैनेज्ड राउटर पर समकक्ष डिवाइस के स्टैटिक-रूट पेज में रहता है; Linux राउटर पर यह उस इंटरफ़ेस के कॉन्फ़िगरेशन में आता है जो LAN का मालिक है, उस शेल में नहीं जिसे आप बंद करेंगे।

दूसरे कमांड का जवाब देखें। अगर वह क्लाइंट को gateway और LAN इंटरफ़ेस को device बताता है, तो पहला हॉप सही है और बाकी काम दूसरी मशीन पर है।

चरण 2: क्लाइंट को टनल की ओर अपना रूट दें

क्लाइंट अब 10.60.0.0/24 के लिए पैकेट पाता है और अपनी टेबल देखता है। अगर उसके टनल कॉन्फ़िगरेशन ने उस प्रीफ़िक्स के लिए रूट इंस्टॉल किया है, तो पैकेट एन्क्रिप्टेड चलता रहता है। अगर नहीं, तो पैकेट सामान्य डिफ़ॉल्ट से मेल खाता है और 192.168.50.1 पर लौट जाता है, जो उसे फिर क्लाइंट को भेजता है।

कुछ जोड़ने से पहले देखें:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

हर टेबल में प्रीफ़िक्स रूट का न होना वही निष्कर्ष है जो आप खोज रहे हैं। इसे टनल के अपने कॉन्फ़िगरेशन से जोड़ें, ताकि अगला पुनः-कनेक्शन इसे फिर इंस्टॉल करे; हाथ से किया ip route add सेशन के साथ गायब हो जाता है और खराबी को सबसे असुविधाजनक समय पर लौटा देता है। अगला हॉप टनल इंटरफ़ेस है या वह एड्रेस जो VPN अपने पीयर के रूप में देता है, क्लाइंट पर निर्भर, और पीयर एड्रेस मौजूदा प्रोफ़ाइल से आना चाहिए, पुराने नोट से नहीं।

लूप, जब होता है, व्यवहार में अनंत नहीं है: हर पास पर TTL घटता है और पैकेट समय-समाप्ति संदेश के साथ मर जाता है। इसीलिए बार-बार किया traceroute चक्र का संकेत दे सकता है, जबकि जो क्लाइंट केवल फ़ॉरवर्ड नहीं कर रहा वह वही पैकेट चुपचाप गिरा देता है।

चरण 3: फ़ॉरवर्डिंग की अनुमति दें और वापसी का रास्ता चुनें

प्राप्त करना और फ़ॉरवर्ड करना अलग-अलग अनुमतियाँ हैं। क्लाइंट पर net.ipv4.ip_forward=1 कर्नेल स्तर पर ट्रांज़िट की अनुमति देता है, और फ़ायरवॉल नियम को अभी भी इसे LAN इंटरफ़ेस और टनल के बीच अनुमति देनी होगी। जो नियम क्लाइंट के अपने प्रबंधन पेज तक पहुँच की अनुमति देता है वह दूर के LAN तक ट्रांज़िट की अनुमति नहीं देगा, और जब वही होस्ट स्थानीय रूप से पिंग का जवाब देता है तो यह अंतर छूट जाना आसान है।

दूर की ओर को दर्पण जैसी समस्या है। उसे जानना चाहिए कि 192.168.50.0/24 इस प्रमाणित क्लाइंट के ज़रिए पहुँचा जा सकता है। OpenVPN के साथ इसका आम तौर पर मतलब है सर्वर कॉन्फ़िगरेशन द्वारा धकेला गया प्रति-क्लाइंट रूट, या सर्वर पर क्लाइंट-विशिष्ट फ़ाइल जो क्लाइंट के पीछे के LAN की घोषणा करती है। इसके बिना, दूर का LAN या तो जवाब गिरा देता है या उसे अपने डिफ़ॉल्ट गेटवे पर भेज देता है, यानी इंटरनेट।

जब LAN प्रीफ़िक्स की घोषणा नहीं की जा सकती तो स्रोत अनुवाद विकल्प है। क्लाइंट पर सीमित masquerade नियम स्रोत को टनल एड्रेस में फिर से लिखता है, और जवाब तब स्वाभाविक रूप से लौटते हैं। यह यह भी छिपाता है कि किस LAN होस्ट ने अनुरोध किया, और अपने आप में दूर की ओर को अंदर की ओर कनेक्शन शुरू करने नहीं देता। यह समझौता जानबूझकर चुनें, बजाय एक व्यापक masquerade जोड़कर बाद में दुष्प्रभाव खोजने के।

चरण 4: दोनों फ़ैसलों को स्थायी करें, फिर असली रास्ता परखें

हर रूट का एक मालिक होता है, और मालिक वह कॉन्फ़िगरेशन है जो बूट पर या पुनः-कनेक्शन पर फिर बनता है। राउटर पर यह स्टैटिक रूट एंट्री हो सकती है; क्लाइंट पर यह VPN प्रोफ़ाइल, NetworkManager या systemd-networkd हो सकता है। टनल फिर से जोड़कर और क्लाइंट रीबूट करके सत्यापित करें, फिर बदलाव पर भरोसा करने के बजाय टेबल दोबारा पढ़ें।

टनल का बाहरी कनेक्शन ढोने वाले डिफ़ॉल्ट रूट को अछूता रखें। सेटअप को “आसान” बनाने के लिए उसे बदलना एन्क्रिप्टेड रास्ते को तोड़ देता है इससे पहले कि कोई भीतरी ट्रैफ़िक उसका उपयोग कर सके, और लक्षण ऐसा टनल है जो बदलाव के बाद कभी फिर स्थापित नहीं होता।

सामान्य LAN होस्ट से परखें, क्लाइंट से नहीं, क्योंकि क्लाइंट पर शुरू हुआ अनुरोध कभी राउटर के पहले हॉप का उपयोग नहीं करता। ऐसी सेवा लाएँ जो केवल दूर के LAN पर मौजूद है और जवाब का मुख्य भाग पुष्टि करें, फिर ट्रांज़िट होते देखने के लिए क्लाइंट के काउंटर या लॉग देखें। निजी हॉप दिखाने वाला भीतरी traceroute फ़ॉरवर्डिंग साबित करता है, एन्क्रिप्शन नहीं: बाहरी रास्ता अलग अवलोकन है, और केवल टनल के अपने इंटरफ़ेस काउंटर बताते हैं कि उससे क्या बाहर गया।