VPN रूट में अगला हॉप: गेटवे स्थानीय रूप से पहुँच योग्य क्यों होना चाहिए

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

यह रनबुक सामान्य स्थिति को कवर करता है: 192.168.20.0/24 पर एक लैपटॉप, 192.168.20.5 LAN पते वाला VPN गेटवे, और उस गेटवे के पीछे 10.70.0.0/24 दूर का नेटवर्क। नीचे दिए गए सभी कमांड मानते हैं कि आप लैपटॉप पर हैं, जब तक कि अन्यथा न कहा जाए।

दो पते, एक रूट

इच्छित प्रविष्टि 10.70.0.0/24 via 192.168.20.5 है। प्रीफ़िक्स बताता है कि पैकेट कहाँ जा रहा है; via पता बताता है कि उसे वहाँ कौन ले जा रहा है। कर्नेल ऐसा रूट स्थापित करने से मना कर देता है जिसके गेटवे तक वह आपके बताए इंटरफ़ेस से नहीं पहुँच सकता, और यही इनकार पूरी बात है: जिस अगले हॉप को पहुँच योग्य होने के लिए सुरंग चाहिए, वह सुरंग बनाने वाला अगला हॉप नहीं हो सकता।

इसलिए पहली जाँच «गेटवे चालू है क्या» नहीं, बल्कि «गेटवे इस लिंक पर है क्या» है। लैपटॉप का अपना सबनेट, उसकी ARP या पड़ोसी प्रविष्टि, और रूट में मौजूद इंटरफ़ेस — सबको सहमत होना चाहिए। जो पता केवल 10.70.0.0/24 के भीतर मौजूद है वह दूसरे रूट का गंतव्य हो सकता है, पहले का via कभी नहीं।

अगला हॉप गेटवे को किस बात के लिए बाध्य करता है

लैपटॉप पर रूट स्थापित करना केवल पहला हैंडऑफ़ तय करता है। इसके बाद गेटवे को अपना रास्ता चाहिए: फ़ॉरवर्डिंग सक्षम, 10.70.0.0/24 के लिए सुरंग रूट, और कोई भी एक्सेस नीति जो तय करती है कि इसे कौन इस्तेमाल कर सकता है। Linux पर यह net.ipv4.ip_forward=1 और एक सुरंग रूट है; उसके आगे का फ़ायरवॉल ऐसा नियम चाहता है जो फ़ॉरवर्ड होने वाले प्रवाह को अनुमति दे।

वापसी दिशा वह हिस्सा है जिसे लोग भूल जाते हैं। दूर के पक्ष के पास 192.168.20.0/24 तक वापस जाने का रूट होना चाहिए, या डिज़ाइन को लैपटॉप के स्रोत को किसी ऐसी चीज़ में बदलना चाहिए जिसे दूर का पक्ष जानता हो। गेटवे से काम करने वाला ping साबित करता है कि गेटवे दूर के नेटवर्क तक पहुँच सकता है; यह कुछ नहीं कहता कि लैपटॉप के पैकेट वापसी की यात्रा में बचते हैं या नहीं।

जो होस्ट भेजता है उसी से लुकअप जाँचें

कर्नेल से पूछें कि वह कौन-सा अगला हॉप चुनेगा, और उत्तर में मौजूद इंटरफ़ेस पढ़ें:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

यदि लुकअप गेटवे और LAN इंटरफ़ेस की रिपोर्ट करता है, तो पहला चरण इच्छा के अनुसार कॉन्फ़िगर है। यदि यह सुरंग उपकरण की रिपोर्ट करता है, तो तालिका में पहले की कोई चीज़ अधिक विशिष्ट है और जीत रही है। यदि रूट बिलकुल स्थापित नहीं होता, तो कर्नेल आपको बता रहा है कि गेटवे पहुँच योग्य नहीं है, और वह संदेश किसी भी पैकेट कैप्चर से अधिक उपयोगी है।

फिर सही जगह से परीक्षण दोहराएँ। गेटवे पर बनाया गया अनुरोध गेटवे के अपने स्रोत पते का उपयोग करता है, जो गुम वापसी रूट या केवल कुछ स्रोतों को अनुमति देने वाली नीति छिपा सकता है। ip-route मैनुअल गंतव्य, गेटवे और onlink ओवरराइड को अलग करता है, और ओवरराइड को इस्तेमाल से पहले समझना उचित है।

पहुँच को नकली बनाने के लिए onlink का उपयोग न करें

onlink कर्नेल से कहता है कि गेटवे की पहुँच जाँच छोड़ दे और फिर भी वहाँ भेजे। यह रास्ता नहीं बनाता, जो पता वहाँ नहीं है उसके लिए ARP हल नहीं करता, और आपके Ethernet खंड पर दूर के राउटर को उत्तर देने पर मजबूर नहीं करता। यह उन गेटवे के लिए वैध है जो उत्तर देते हैं पर जुड़े हुए सबनेट में नहीं बैठते, और यह जाल है जब इसका उपयोग उस गलती को शांत करने के लिए हो जिसे आपने समझाया नहीं है।

यदि रूट केवल onlink के साथ स्थापित होता है, तो अगला सवाल यह है कि गेटवे वहाँ क्यों नहीं है जहाँ आप सोचते हैं। गलत VLAN, गलत इंटरफ़ेस पर दूसरा पता, या अंतिम ऑक्टेट में टाइपो — ये सब इसे पैदा करते हैं, और इनमें से हर एक ट्रैफ़िक बहना शुरू होते ही वापसी का रास्ता भी तोड़ देता है।

पॉइंट-टू-पॉइंट सुरंगें Ethernet नहीं हैं

सुरंग उपकरण ARP नहीं करता और अक्सर उसका पड़ोसियों का कोई अर्थपूर्ण सबनेट नहीं होता। उसके रूट अक्सर 10.70.0.0/24 dev tun0 जैसे दिखते हैं, बिना किसी via के, क्योंकि पीयर ही दूसरा एकमात्र अंतिम बिंदु है। उस तालिका में LAN-शैली का via कॉपी करने से ऐसा रूट बनता है जिसे कर्नेल अस्वीकार कर सकता है या, इससे बुरा, जो ऐसे पते की ओर इशारा करता है जिसका पीयर कभी उत्तर नहीं देता।

रनबुक में दोनों मॉडल अलग रखें: LAN रूट का पहुँच योग्य गेटवे होता है, सुरंग रूट का इंटरफ़ेस और पीयर होता है। WireGuard, OpenVPN और IPsec सभी थोड़े अलग आकार दिखाते हैं, इसलिए एक होस्ट से सामान्यीकरण करने के बजाय वह आकार दर्ज करें जो आपने वास्तव में इस्तेमाल किया।

जोड़ें, पुष्टि करें, वापस लें

पूरा बदलाव तीन कमांड और एक जाँच है, और इसे उसी क्रम में लिखा जाना चाहिए:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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