गेटवेमा 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 सत्रले टनेललाई वास्ता नगरी आफ्नै सुरक्षा राख्छ। तपाईंले के अवलोकन गर्नुभयो, कुन अवलोकन बिन्दुबाट र कुन समयमा भन्ने जनाउनुहोस्।