eth0 पर ट्रैफ़िक का मतलब यह नहीं कि VPN सुरंग लीक हो रही है

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

हर सुरंग पैकेट फिर भी तार से गुज़रता है

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

UDP मोड में बाहरी प्रवाह हर दिशा में पता और पोर्ट की एक ही जोड़ी होता है, इसीलिए स्वस्थ सुरंग eth0 पर लगभग उबाऊ लगती है। पहले उसी एक जोड़ी को खोजना चाहिए।

एक बार में एक इंटरफ़ेस कैप्चर करें

जब गिनतियों की तुलना करनी हो तो एक बार में एक इंटरफ़ेस कैप्चर करें। any स्यूडो-इंटरफ़ेस एक साथ हर डिवाइस इकट्ठा करता है, इसलिए अग्रेषित पैकेट प्रवेश और निकास दोनों पर दिखता है और स्थानीय रूप से बना पैकेट दो अलग रूपों में दो बार दिखता है। बराबर पैकेट गिनती और असमान बाइट गिनती सामान्य है, क्योंकि लिफ़ाफ़ा उससे बड़ा है जो वह ढोता है। ARP, DHCP और IPv6 राउटर की घोषणाएँ स्थानीय लिंक की हैं और आपके एप्लिकेशन के बारे में कुछ नहीं कहतीं।

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

पते और पोर्ट को प्रोफ़ाइल के अपने मानों से बदलें। अगर वह प्रवाह स्थिर है तो सुरंग कुछ ढो रही है।

कर्नेल से पूछें कि वह कौन सा डिवाइस चुनता है

कर्नेल से पूछें कि वह कौन सा डिवाइस चुनेगा, फिर तार पर पुष्टि करें। रूट खोज ही निर्णय है, और कैप्चर इस बात का सबूत है कि निर्णय का पालन हुआ। वे अलग सवालों के जवाब देते हैं और आपको दोनों चाहिए।

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

बँटा हुआ नतीजा आम खोज है: IPv4 सुरंग में जाता है और IPv6 भौतिक एडाप्टर पर जाता है, क्योंकि प्रोफ़ाइल ने केवल IPv4 रूट भेजे। यह असली लीक है, और केवल IPv4 वाले कैप्चर में यह अदृश्य है। IPv6 के लिए फ़िल्टर करें और ऐसे पतों पर नज़र रखें जो न सर्वर हैं और न link-local।

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

जब कैप्चर वास्तव में लीक हो

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

रूट या अपवाद ठीक करें, फ़ायरवॉल नहीं। फिर नए कनेक्शन से दोबारा कैप्चर करें और IPv4 व IPv6 अलग-अलग जाँचें, क्योंकि एक को ठीक करने से दूसरे के बारे में कुछ नहीं कहा जाता। tcpdump की मार्गदर्शिका ऊपर इस्तेमाल किए गए इंटरफ़ेस और दिशा चयनकों को समझाती है।