हरा आइकन, वही सार्वजनिक IP: VPN ने कौन-सा रूट छोड़ा

कनेक्टेड, हरा ट्रे आइकन, और पता दिखाने वाला पेज अब भी प्रदाता का पता दिखा रहा है, इसका मतलब अपने आप खराबी नहीं है। क्लाइंट दो अलग काम करता है: वह टनल बनाता है, और वह रूटिंग तालिका संपादित करता है। दोनों में से कोई भी दूसरे के बिना हो सकता है, और चयनित रूटिंग वह कॉन्फ़िगरेशन है जिसमें दूसरा जानबूझकर छोड़ दिया जाता है।

क्लाइंट ने असल में क्या इंस्टॉल किया

यह पूछने के बजाय कि टनल चालू है या नहीं, यह पूछें कि कौन-सा इंटरफ़ेस पैकेट को वास्तविक गंतव्य तक ले जाएगा। उस गंतव्य के लिए रूट के बिना टनल एक निजी सड़क है जिस पर कोई नहीं चलता।

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

पहला कमांड Linux और macOS पर जवाब देता है, और बाकी दो Windows के समकक्ष हैं जहाँ एक ही काफ़ी है। अगर जवाब भौतिक एडाप्टर का नाम लेता है, तो टनल चालू है और डिफ़ॉल्ट रूट कभी हिला नहीं। उस गंतव्य के लिए जाँच दोहराएँ जिसे टनल इस्तेमाल करना चाहिए, क्योंकि दो जाँचें, एक दूर की और एक सामान्य, बताती हैं कि कौन-सा डिज़ाइन लागू है।

चयनित रूटिंग के तीन रूप

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

जो निर्णय लेने वाला निर्देश है उसके लिए प्रोफ़ाइल पढ़ें, फिर जो उसने उत्पन्न किया उसके लिए तालिका पढ़ें। धकेला गया निर्देश क्लाइंट पर दबाया भी जा सकता है, इसलिए सर्वर को दोष देने से पहले प्रोफ़ाइल और तालिका को मेल खाना चाहिए।

दूसरे पक्ष को स्रोत पता फिर से लिखना होगा

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

नाम विभेदन अपना रास्ता लेता है

ट्रैफ़िक टनल से बाहर जा सकता है जबकि नाम खोजने वाली जाँच स्थानीय नेटवर्क के रिज़ॉल्वर के पास गई हो। दिखने वाला पता वही रहता है, जाँचें नहीं, और यही अंतर वह है जो विभाजित DNS डिज़ाइन चुनता है।

resolvectl status | head -20
resolvectl query example.org

ध्यान दें कि किस सर्वर ने जवाब दिया और क्या वह टनल से पहले की आधार रेखा से अलग है। विभाजित टनल में यह आमतौर पर वही सेटिंग होती है जिसे लोग पते की शिकायत करते समय बदलना चाहते थे, और यही वह है जिसे उन्होंने कभी नहीं देखा।

चार अवलोकन जो बात तय करते हैं

टनल बंद होने पर एग्ज़िट पता दर्ज करें, फिर चालू होने पर। दोनों स्थितियों में गंतव्य जाँच चलाएँ और हर बार इंटरफ़ेस नोट करें।

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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