के ट्राफिक साँच्चै 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 क्याप्चर गर्नुहोस्, निश्चित एप्लिकेसनका लागि शेलबाट बाहिरिने ठेगाना फर्काउनुहोस्, त्यसपछि मात्राका लागि सर्भर पढ्नुहोस्। पहिला चार मिले भने सुरुङले तपाईंले सोचेको कुरा बोकिरहेको छ र बाँकी समस्या त्यसको माथि छ। दुई नमिले भने नमिल्ने जोडी नै खराबी हो, आइकन होइन।