VPN को बारेमा iftop स्क्रिनले के प्रमाणित गर्न सक्छ र के सक्दैन

iftop स्क्रिनले एक पटकमा एउटा प्रश्नको उत्तर दिन्छ: तपाईंले निर्देशित गरेको इन्टरफेसबाट कुन होस्ट जोडीहरू बाइट साटासाट गर्दै छन्। यसले प्रत्येक अनुप्रयोगले VPN नीति पालना गर्छ कि गर्दैन भन्ने उत्तर दिँदैन, र खाली स्क्रिनले केही पनि चुहिएन भनी प्रमाणित गर्दैन। यी दुई भनाइबीचको खाडलमै अधिकांश लिक-परीक्षण बहसहरू गलत हुन्छन्। डिस्प्लेको वास्तविक अर्थ तीन सर्तले निर्धारण गर्छ, र ती तीनै तपाईंले प्रयोग गरेको कमाण्ड लाइनमा देखिन्छन्।

तीन सर्तले स्क्रिनको अर्थ निर्धारण गर्छन्

सर्तहरू हुन्: कुन इन्टरफेस देखाइँदै छ, फिल्टर र उपकरण आफैले के लुकाइरहेका छन्, र परीक्षणले वास्तवमा के गर्यो। यही क्रममा उत्तर दिनुहोस्, किनभने पहिलोमा गल्ती भए बाँकी दुई अर्थहीन हुन्छन्।

इन्टरफेसको सर्त महत्त्वपूर्ण छ किनभने सुरुङ दृश्य र भौतिक दृश्यले एउटै ट्राफिकका फरक तहहरू देखाउँछन्। सुरुङ इन्टरफेसतिर हेर्दा सुरुङभित्रका प्रवाह देखिन्छन्; भौतिक इन्टरफेसतिर हेर्दा सुरुङको वाहक, साथै त्यो लिङ्क साझा गर्ने कुनै पनि वैध सेटअप, नियन्त्रण वा स्थानीय ट्राफिक देखिन्छ। दुवैमध्ये कुनै दृश्य गलत छैन, र कुनै पनि पूरा चित्र होइन। तपाईं कुन हेर्दै हुनुहुन्छ भनी नाम दिनु नै प्रमाण र धारणाबीचको भिन्नता हो।

सर्त एक: कुन इन्टरफेस देखाइन्छ

iftop ले इन्टरफेसलाई स्पष्ट रूपमा -i सँग लिन्छ, र तपाईंले त्यसो नगर्दा हुने व्यवहार यसको म्यानुअलले वर्णन गर्छ: यसले एउटा छान्छ, जुन सुरुङको सट्टा बाहिरबाट देखिने यन्त्र हुन सक्छ। त्यो पूर्वनिर्धारित ब्यान्डविथ उपकरणका लागि उपयुक्त र लिक परीक्षणका लागि खराब छ।

सधैं इन्टरफेस दिनुहोस्, र त्यसलाई नतिजाको छेउमा लेख्नुहोस्। इन्टरफेसको नाम बिनाको स्क्रिनसट पुनरुत्पादनयोग्य हुँदैन।

सर्त दुई: फिल्टर र उपकरणले के लुकाउँछन्

iftop ले फिल्टर अभिव्यक्ति स्वीकार गर्छ, र फिल्टरले बाहिर राखेको प्रवाह अनुपस्थितिका कारण होइन, रचनाका कारण अदृश्य हुन्छ। उपकरणले पनि पूर्वनिर्धारित रूपमा ठेगाना लेबल गर्न होस्टनेम खोज गर्छ, र ती खोजले आफ्नै DNS ट्राफिक उत्पन्न गर्छ, अर्थात् तपाईंले अवलोकन गर्न नचाहेको ट्राफिक। -n ले खोज बन्द गर्छ र प्रदर्शनलाई सांख्यिक बनाउँछ; पछि DNS पङ्क्तिहरू लुकाउनु प्रश्नहरू उत्पन्न नगर्नुसँग बराबर होइन।

यो भिन्नता स्पष्ट भन्न लायक छ, किनभने यो अन्य उपकरणहरूमा पनि देखिन्छ: कुनै गतिविधिको प्रदर्शन दबाउनु त्यसलाई रोक्नुसँग बराबर होइन। यदि DNS खोजहरू तपाईंको परीक्षणको भाग हुन् भने, खोज बन्द राखेर परीक्षण चलाउनुहोस्, ताकि अवलोकन अवलोकनकर्ताबाट दूषित नहोस्।

सर्त तीन: परीक्षणले वास्तवमा के गर्यो

एउटा अनुप्रयोगबाट, एउटा गन्तव्यतिर, एउटा ठेगाना परिवारमा एउटै अनुरोधले त्यो अनुरोधबारे केही प्रमाणित गर्छ। यसले फरक अनुप्रयोग, फरक गन्तव्य वा अर्को ठेगाना परिवारबारे केही पनि प्रमाणित गर्दैन, र यस्तै प्रकारको जाँचमा IPv6 सबैभन्दा बढी बिर्सिने परिवार हो।

त्यसैले सुरु गर्नुअघि अनुरोध परिभाषित गर्नुहोस्: हानिरहित गन्तव्य, तपाईंलाई महत्त्वपूर्ण अनुप्रयोगबाट, तपाईंलाई महत्त्वपूर्ण परिवारमा, सुरुङ त्यसको स्वीकृत अवस्थामा। त्यसपछि प्राप्त गर्ने पक्ष वा क्लाइन्टको आफ्नै निदान जाँच्नुहोस्, किनभने टाढाको छेउले के आयो भन्ने कुरा स्थानीय स्क्रिनले जान्न नसक्ने तरिकाले जान्दछ। त्यसपछि सुरुङ उपलब्ध नहुने स्वीकृत अवस्था चलाउनुहोस् र ट्राफिक रोकिन्छ कि भनी हेर्नुहोस्, किनभने आवश्यकता सामान्यतया वास्तवमा यही व्यवहारबारे हुन्छ।

DNS ले आफ्नै अवलोकन पाउनुपर्छ। प्रश्नको प्राप्तकर्ता र प्रश्नले लिएको मार्ग दुई तथ्य हुन्, र ब्यान्डविथ स्क्रिनले दुवैमध्ये कुनै देखाउँदैन।

iftop लाई समर्थक प्रमाणका रूपमा प्रयोग गर्ने

त्यसपछि मात्र iftop मूल्य थप्छ, र त्यो पुष्टिका रूपमा थप्छ। sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" ले अपेक्षित प्रवाह अपेक्षित इन्टरफेसमा देखिन्छ कि भनी, निष्क्रियताको दाबीलाई जाँचयोग्य बनाउने बाइट गणनासहित देखाउँछ।

यसलाई सकेट-स्तर दृश्यका लागि ss -tnp सँग र कर्नेलले छान्ने मार्गका लागि ip route get सँग तुलना गर्नुहोस्, अनि एउटा मेसिनबारेको एउटा धारणाको सट्टा एउटा अनुरोधका तीन अवलोकन तपाईंसँग हुन्छन्। iftop म्यानुअल ले इन्टरफेस छनोट, फिल्टर सिन्ट्याक्स र खोज व्यवहार दस्तावेजीकरण गर्छ, र यी नै लिक परीक्षण निर्भर हुने तीन कुरा हुन्। ब्यान्डविथ स्क्रिनले गतिविधिको स्थान पहिचान गर्छ; मार्ग, अपवाद र असफलताको व्यवहारले त्यो गतिविधि आवश्यकता पूरा गर्छ कि गर्दैन भनी निर्धारण गर्छ।