ट्रॅफिक खरंच 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 मधून फाइली कॉपी करत आहे का या प्रश्नाचे उत्तर सर्व्हरवरील फाइल-शेअरिंग ट्रॅफिक किंवा सर्व्हरवरील होस्ट ऑडिट देते — सुरंग पाहिल्याने टोके आणि प्रमाण मिळते, फाइलींची नावे नाही.
रचना निर्णय आणि गळती वेगळी ओळखा
सुरंगाबाहेरचे सर्व काही गळती नाही. लिंक-स्थानिक आणि प्रसारण ट्रॅफिक रचनेनुसार स्थानिक राहते, मल्टिकास्टने सापडलेला प्रिंटर 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 कॅप्चर करा, विशिष्ट ॲप्लिकेशनसाठी शेलमधून बाहेर पडण्याचा पत्ता परत मिळवा, नंतर प्रमाणासाठी सर्व्हर वाचा. पहिली चार जुळली तर सुरंग तुम्हाला वाटते तेच वाहत आहे आणि उर्वरित समस्या त्याच्या वर आहे. दोन जुळल्या नाहीत तर न जुळणारी जोडीच बिघाड, चिन्ह नाही.