क्या ट्रैफ़िक वास्तव में VPN से होकर जाता है? इसे कैसे सत्यापित करें
रूट लुकअप, पहला हॉप, भौतिक एडाप्टर पर कैप्चर और बाहर से पता जाँच — हर एक प्रश्न के अलग हिस्से का उत्तर देता है।
दो विफलताएँ सिस्टम ट्रे के आइकन से एक जैसी दिखती हैं: वह ट्रैफ़िक जो सुरंग में जाता है और वह ट्रैफ़िक जो चुपचाप उसके चारों ओर से निकल जाता है। क्लाइंट दोनों स्थितियों में Connected दिखाता है, क्योंकि Connected का अर्थ केवल यह है कि सुरंग का इंटरफ़ेस मौजूद है और क्लाइंट ने अपने मनचाहे रूट इंस्टॉल कर लिए हैं। क्या किसी एक एप्लिकेशन के एक पैकेट ने उन रूट का उपयोग किया, यह अलग प्रश्न है, जिसका उत्तर स्टैक में कहीं और दिया जाता है। चार माप अधिकांश हल कर देते हैं — रूट लुकअप, पहला हॉप, भौतिक एडाप्टर पर कैप्चर और बाहर से अवलोकन — और सर्वर का अपना सत्र दृश्य शेष कवर करता है।
उस रूट से शुरू करें जिस पर पैकेट जाएगा
रूटिंग तालिका ही निर्णय है, इसलिए पूरी तालिका पढ़कर अनुमान लगाने के बजाय उससे एक गंतव्य के बारे में पूछें। Linux पर, ip route get वह इंटरफ़ेस और स्रोत पता बताता है जो कर्नेल ने चुना:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows पर, Find-NetRoute -RemoteIPAddress 203.0.113.10 उसी कारण से route print -4 से अधिक उपयोगी है: यह जीतने वाले रूट की सूचना देता है, सभी मौजूदा रूट की नहीं। फिर भी तालिका को उसकी 0.0.0.0 पंक्ति के लिए एक बार पढ़ें। वहाँ /1 की जोड़ी का अर्थ है कि पूर्ण-सुरंग क्लाइंट ने डिफ़ॉल्ट रूट फिर से लिखा है: OpenVPN का redirect-gateway def1 विकल्प सुरंग के माध्यम से 0.0.0.0/1 और 128.0.0.0/1 इंस्टॉल करता है, जो सबसे लंबे प्रीफ़िक्स मिलान पर मौजूदा 0.0.0.0/0 को हरा देता है और भौतिक डिफ़ॉल्ट रूट को हटाता नहीं है। इसीलिए दो डिफ़ॉल्ट रूट साथ रह सकते हैं जबकि सब कुछ फिर भी सुरंग में जाता है।
दो विवरण तालिका को झूठा बनाते हैं। पहला, डिफ़ॉल्ट रूट की संख्या के बजाय मिले हुए प्रीफ़िक्स को देखें, क्योंकि इंटरफ़ेस मीट्रिक या /1 की जोड़ी विजेता तय करती है। दूसरा, पहले से मौजूद कनेक्शन उसी पथ पर बना रहता है जिससे वह स्थापित हुआ था; सुरंग उठने के बाद खुला सत्र रीसेट होने तक पुराने रूट का उपयोग कर सकता है, और इसीलिए फिर से कनेक्ट करना रूटिंग समस्या ठीक करता हुआ लगता है। चलता हुआ क्लाइंट — ps ax | grep openvpn — केवल यह सिद्ध करता है कि प्रक्रिया शुरू हुई है।
एक आंतरिक और एक सार्वजनिक नाम का पता लगाएँ
रूट लुकअप इरादा दिखाता है; पथ डिलीवरी दिखाता है। कनेक्ट रहते हुए उस नाम का पता लगाएँ जो आंतरिक होना चाहिए और उस नाम का जो नहीं होना चाहिए, और पहले हॉप की तुलना करें:
traceroute intranet.corp.example
traceroute 1.1.1.1दोनों के लिए एक ही पहला हॉप का अर्थ है कि आंतरिक नाम कभी सुरंग में नहीं गया और खराबी उसके ऊपर है, आमतौर पर ऐसा नाम जो सार्वजनिक पते पर हल होता है या ऐसा रूट जो कभी इंस्टॉल नहीं हुआ। यदि आंतरिक ट्रैफ़िक 10.8.0.1 से बाहर जाता है जबकि सार्वजनिक ट्रैफ़िक 192.168.1.1 से बाहर जाता है, तो स्प्लिट टनलिंग ठीक वही कर रही है जिसके लिए उसे कॉन्फ़िगर किया गया था। जो ट्रेस VPN गेटवे तक पहुँचकर केवल टाइमआउट लौटाता है वह आमतौर पर रिटर्न-पाथ या सर्वर फ़ायरवॉल की समस्या है, गायब फ़ॉरवर्ड रूट नहीं।
फ़िल्टर किया गया ICMP इस जाँच को झूठा बनाता है: दोनों ट्रेस में तारे मृत सुरंग जैसे दिखते हैं और आमतौर पर वह फ़ायरवॉल होता है। जहाँ संभव हो TCP पोर्ट जाँचें — Linux पर traceroute -T -p 443 — और याद रखें कि ट्रेस यह नहीं बताता कि किस रिज़ॉल्वर ने उत्तर दिया: कोई नाम स्थानीय रूप से हल होकर भी सुरंग से पहुँचा जा सकता है।
भौतिक एडाप्टर पर कैप्चर करें, सुरंग पर नहीं
भौतिक लिंक ही एकमात्र जगह है जो दिखाती है कि नेटवर्क वास्तव में क्या देखता है। सुरंग ऊपर होने पर दफ़्तर जाने वाला सत्र VPN सर्वर को संबोधित एन्क्रिप्टेड पेलोड के रूप में दिखना चाहिए, 10.20.5.7 के लिए कनेक्शन के रूप में नहीं:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5पहला फ़िल्टर स्थानीय रूप से बाहर जाते नाम विश्लेषण को पकड़ता है, जो सबसे आम और सबसे शांत लीक है — पेज फिर भी लोड होता है, रिज़ॉल्वर ने बस क्वेरी देखी। दूसरा आंतरिक पते पर होने वाला सामान्य ट्रैफ़िक पकड़ता है जो केवल सुरंग के अंदर ही होना चाहिए। Windows पर, pktmon बिना ड्राइवर वही काम करता है: pktmon filter add -p 53, फिर pktmon start --capture --pkt-size 128, फिर pktmon stop और pktmon format pktmon.etl -o capture.txt। ये फ़्लैग Windows संस्करणों में थोड़े भिन्न होते हैं, इसलिए सिंटैक्स पर भरोसा करने से पहले pktmon filter add /? जाँचें।
लीक खोजने के लिए भौतिक इंटरफ़ेस पर कैप्चर करें; सुरंग पर कैप्चर वही पैकेट रखता है जिनके होने का आपको पहले से विश्वास है, और सर्वर पर यह अपठनीय बाहरी पैकेट रखता है जिनका स्रोत गेटवे है। किसी भी इंटरफ़ेस के बाइट काउंटर पैकेट का वर्णन करते हैं, प्रोग्राम का नहीं; ट्रैफ़िक को प्रक्रिया से जोड़ने के लिए ऐसे मॉनिटर की ज़रूरत है जो सॉकेट को प्रक्रियाओं से मैप करे।
किसी बाहरी सेवा से पूछें, और फिर हर एप्लिकेशन के लिए दोबारा पूछें
एकमात्र जाँच जो निकास सिद्ध करती है वह बाहर से आया उत्तर है: ऐसी सेवा जो देखे गए स्रोत पते को लौटाए। इसे शेल से चलाएँ, जहाँ आप इंटरफ़ेस चुन सकते हैं, और दो बार चलाएँ:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipअलग उत्तर आपको दोनों पथों का प्रमाण और किसी विशिष्ट एप्लिकेशन को जाँचने का तरीका देते हैं: उसे बाइंड करें, या एक ही रूट वाले नेटवर्क नामस्थान में चलाएँ, और देखें कि दूर का छोर कौन सा पता दर्ज करता है। समान उत्तर दिलचस्प विफलता है: या तो बाइंडिंग का असर नहीं हुआ, या होस्ट और दूर के छोर के बीच कुछ पहुँचने से पहले स्रोत पता फिर से लिख देता है। Windows पर, curl --interface एडाप्टर का नाम नहीं, पता माँगता है।
VPN पता बताने वाला ब्राउज़र ब्राउज़र को सिद्ध करता है। मेल क्लाइंट, पैकेज मैनेजर, बैकअप एजेंट या दूसरा ब्राउज़र प्रोफ़ाइल अलग-अलग पथ ले सकते हैं, खासकर जब प्रॉक्सी सेटिंग या स्प्लिट-टनल रूट उनमें से किसी एक को ढक देता है। पता बदलना अपने आप में लीक का प्रमाण नहीं है: लोड बैलेंसर देखे गए एग्रेस के अनुसार अलग उत्तर दे सकता है, इसलिए पेज नहीं, दर्ज किए गए स्रोत पते की तुलना करें।
सहकर्मी की पुष्टि के लिए सर्वर दृश्य का उपयोग करें
सर्वर दूसरे प्रश्न का उत्तर देता है: क्या सहकर्मी जुड़ा है, कितना ढोया है और क्या सत्र फिर से शुरू हुआ। सर्वर पर सहकर्मी सक्रिय हो जबकि क्लाइंट काउंटर मुश्किल से हिलें, इसका अर्थ है कि एप्लिकेशन ट्रैफ़िक सुरंग में नहीं जा रहा, चाहे क्लाइंट तालिका कुछ भी कहे। और जो सहकर्मी ऐसे उपयोगकर्ता के लिए बहुत डेटा ले जा रहा है जो कहता है कि कुछ काम नहीं कर रहा, वह दूसरी जाँच है।
यहाँ दो जाल हैं। मास्करेड सुरंग हर प्रवाह को गेटवे से आया हुआ दिखाती है, इसलिए लॉग और प्रति-क्लाइंट हिसाब एक ही पते पर सिमट जाते हैं। और क्लाइंट को स्थानीय होस्ट माना जाता है, इसलिए कि कोई VPN से फ़ाइलें कॉपी कर रहा है या नहीं, इस प्रश्न का उत्तर सर्वर पर फ़ाइल-साझाकरण ट्रैफ़िक या सर्वर पर होस्ट ऑडिट देता है — सुरंग देखने से एंडपॉइंट और मात्रा मिलती है, फ़ाइल नाम नहीं।
डिज़ाइन निर्णय को लीक से अलग पहचानें
सुरंग के बाहर सब कुछ लीक नहीं है। लिंक-लोकल और ब्रॉडकास्ट ट्रैफ़िक डिज़ाइन से स्थानीय रहता है, multicast से मिला प्रिंटर LAN पर घोषणा जारी रखता है, और DHCP को स्थानीय रूप से बाहर जाना ही होता है। किसी विशिष्ट इंटरफ़ेस से बंधा एप्लिकेशन जानबूझकर रूटिंग तालिका को बायपास करता है, और केवल फ़ायरवॉल नियम, नामस्थान या नीति रूट उसे बदलते हैं।
IPv6 चेकलिस्ट में अपनी अलग पंक्ति का हक़दार है। जो सुरंग केवल IPv4 ढोती है वह दोहरे-स्टैक होस्ट के पास दूसरा उपयोगी पथ छोड़ देती है, और दोहरा-स्टैक गंतव्य उसे प्राथमिकता देगा — DNS सहित, यदि रिज़ॉल्वर IPv6 से पहुँच योग्य है। IPv4 परिणाम को पूर्ण मानने से पहले एडाप्टर पर IPv6 बंद करें या पुष्टि करें कि सुरंग उसे ढोती है।
जब जाँचें आपस में मेल नहीं खातीं, तो असंगति ही आमतौर पर खराबी का नाम बताती है:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
काम करने वाला क्रम: कनेक्ट करने से पहले और बाद में रूटिंग तालिका सहेजें, एक आंतरिक और एक सार्वजनिक नाम का पता लगाएँ, भौतिक एडाप्टर पर DNS कैप्चर करें, विशिष्ट एप्लिकेशन के लिए शेल से निकास पता लौटाएँ, फिर मात्रा के लिए सर्वर पढ़ें। यदि पहले चार मेल खाते हैं, तो सुरंग वही ढो रही है जो आप सोचते हैं और शेष समस्या उसके ऊपर है। यदि उनमें से दो नहीं मिलते, तो जो जोड़ी नहीं मिलती वही खराबी है, आइकन नहीं।