गेटवे पर OpenVPN क्लाइंट का ट्रैफ़िक कहाँ देखें

आप जानना चाहते हैं कि जुड़ा हुआ क्लाइंट किन गंतव्यों तक पहुँचता है, इसलिए आप VPN सर्वर पर एक शेल खोलकर ss टाइप करते हैं। कुछ उपयोगी नहीं दिखता, और टनल टूटा होने का निष्कर्ष थोड़ा बहुत आसानी से आ जाता है। रूट किया गया OpenVPN गेटवे क्लाइंट के पैकेट आगे भेजता है; वह उनके TCP कनेक्शन समाप्त नहीं करता और उनके लिए सॉकेट नहीं रखता। साक्ष्य कहीं और रहता है, और वह कहाँ, यह इस पर निर्भर करता है कि टनल से निकलने के बाद ट्रैफ़िक को कैसे संभाला जाता है।

तय करें कि आप कौन-सी व्यवस्था देख रहे हैं

दो सामान्य रूप बिल्कुल अलग साक्ष्य देते हैं। रूटिंग गेटवे डीकैप्सुलेट करता है, आगे भेजता है और संभवतः स्रोत-NAT करता है, इसलिए क्लाइंट का कनेक्शन स्थानीय सॉकेट के बिना शुरू से अंत तक बना रहता है।

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

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

पहले पता को सत्र से जोड़ें

सर्वर की सत्र स्थिति से शुरू करें और क्लाइंट का वर्तमान आंतरिक पता पहचानें। पूल के पते पुन: उपयोग होते हैं, इसलिए अकेला पता एक पट्टा है, व्यक्ति नहीं।

समय और प्रमाणित पहचान एक साथ दर्ज करें, और ध्यान दें कि उस क्लाइंट के पीछे पूरा लैन छिपा है या नहीं। यदि दूर का सिरा किसी सबनेट को रूट करता है, तो आप जो आंतरिक पते देखते हैं वे मूल होस्ट या अनूदित हो सकते हैं।

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

रूटिंग गेटवे पर फ़्लो तालिका पढ़ें

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

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

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

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

पढ़ने की पुष्टि के लिए एक सीमित कैप्चर

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

प्रॉक्सी लॉग, और जो आपने देखा उसकी सीमाएँ

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

हर अनुरोध डिफ़ॉल्ट रूप से लॉग होता है यह मानने के बजाय तैनात संस्करण का लॉगिंग कॉन्फ़िगरेशन जाँचें।

अंत में, दायरे के बारे में सटीक रहें। गंतव्य पता और पोर्ट मेटाडेटा हैं, न URL और न पृष्ठ सामग्री, क्योंकि आंतरिक HTTPS सत्र टनल की परवाह किए बिना अपनी सुरक्षा रखता है। बताएं कि आपने क्या देखा, किस अवलोकन बिंदु से, और किस समय।