Mac VPN को बाइट काउन्टरले के प्रमाणित गर्छ र के गर्दैन
बढ्दो कुल पठाइएका बाइट एउटा अवलोकन बिन्दुमा गतिविधि हो, डेलिभरीको प्रमाण होइन। सही इन्टरफेसमा डेल्टा लिनुहोस् र त्यसलाई एपको नतिजासँग जोड्नुहोस्।
क्लाइन्टको स्थिति विन्डो खोल्नुहोस् र अंकहरू ढुक्क लाग्छन्: बाइट बढ्दै छन्, टनेल जोडिएको छ। विन्डो बन्द गर्नुहोस् र अफिस एप अझै असफल हुन्छ, अर्थात् काउन्टरहरूले कसैले नसोधेको प्रश्नको उत्तर दिए। इन्टरफेसमा बाइट गन्नु त्यही अवलोकन बिन्दुको ट्राफिक मापन गर्छ र त्यसभन्दा बढी केही होइन। तपाईंले हेरिरहेको अंकबाट त्यसले रिपोर्ट गर्ने तहसम्म, र त्यसपछि एपले वास्तवमा दिएको नतिजासम्म जानुहोस्।
अंक छान्नुअघि इन्टरफेस छान्नुहोस्
अंक देखाइने ठाउँबाट सुरु गर्नुहोस् र छेउको लेबल पढ्नुहोस्। क्लाइन्ट विन्डोले सत्रको कुल देखाउन सक्छ, टनेल इन्टरफेसले भित्री IP बाइट देखाउन सक्छ, र भौतिक एडाप्टरले इन्क्रिप्ट गरिएको बाहिरी बाइट देखाउन सक्छ; संयोगवश बाइटमा मापिने तीन फरक काउन्टर। कमाण्ड लाइनमा, netstat -ibn प्रत्येक इन्टरफेसमा प्रत्येक ठेगानाका लागि एउटा पङ्क्ति छाप्छ, त्यसैले टनेल धेरै पटक देखिन सक्छ। पङ्क्तिलाई क्लाइन्टले वास्तवमा राख्ने इन्टरफेससँग मिलाउनुहोस्, र गन्तव्यले छान्ने मार्गसँग पुष्टि गर्नुहोस्। utun नामको यन्त्र VPN को, अर्को टनेलको, वा तपाईंलाई नपर्ने कुनै कुराको हुन सक्छ।
पढ्न सजिलो छ भनेर Wi-Fi काउन्टर नराख्नुहोस्। फरक अवलोकन बिन्दुले फरक प्रश्नको उत्तर दिन्छ।
डेल्टा लिनुहोस्, जीवनभरको कुल होइन
पङ्क्ति पढ्नुहोस्, एउटा सानो अनुमतिप्राप्त अनुरोध गर्नुहोस्, र त्यसपछि त्यही पङ्क्ति फेरि पढ्नुहोस्। फरक नै प्रमाण हो, किनकि जीवनभरको कुलमा बुट भएपछि मेसिनले गरेका सबै कुरा समावेश हुन्छन्। अन्तराल छोटो राख्नुहोस् ताकि पृष्ठभूमि ट्राफिकले यसलाई दूषित गर्ने कम अवसर पाओस्। व्यस्त मेसिनमा, nettop ले थ्रुपुटलाई कुनै प्रक्रियासँग आबद्ध गर्न सक्छ, जसले इन्टरफेस काउन्टरतर्फ फर्कनुअघि क्षेत्र साँघुरो बनाउँछ।
डेल्टा सफा छैन भनेर स्वीकार गर्नुहोस्। मेल, अपडेट र क्लाइन्टका आफ्नै किपअलाइभ सन्देशहरू सबैले योगदान गर्छन्, त्यसैले अंकलाई मापन नभई माथिल्लो सीमा मान्नुहोस्। यदि अन्तरालमा तपाईंले एप मात्र चलाउनुभयो भने, सीमा सामान्यतया उपयोगी हुन पर्याप्त कसिलो हुन्छ।
भित्री र बाहिरी काउन्टरले फरक कुरा मापन गर्छन्
भौतिक एडाप्टरले बाहिरी हेडरसहित इन्क्रिप्ट गरिएका प्याकेट गन्छ, जबकि टनेल इन्टरफेसले आफूले प्राप्त वा हस्तान्तरण गर्ने पेलोड हिसाब गर्छ। दुवै जोड्दा एउटै स्थानान्तरण दुई पटक गनिन्छ। अतिरिक्त भार, पुनःप्रेषण र इन्क्याप्सुलेसनले पनि साधारण समानता असम्भव बनाउँछन्।
विपरीत दिशामा चल्ने दुई काउन्टर एउटा खोज हो, विरोधाभास होइन। सामान्यतया यसको अर्थ ट्राफिक एउटा तहमा पस्यो र अर्को तहबाट कहिल्यै निस्किएन।
काउन्टरलाई एपको नतिजासँग जोड्नुहोस्
प्राप्त कुल प्रोटोकलको कुराकानीले बढ्न सक्छ, जबकि तपाईंले चाहेको सेवा अझै असफल हुन्छ। पठाउने क्रमको वृद्धिले अझ कम बताउँछ: यसले कर्नेलले प्याकेट स्वीकार गरेको प्रमाण दिन्छ, कसैले उत्तर दिएको होइन।
काउन्टरको छेउमा ठ्याक्कै नतिजा लेख्नुहोस्: नाम समाधान असफल, जडानको समय सकियो, TLS अस्वीकृत, वा HTTP प्रतिक्रिया आयो। यी चार फरक खराबी हुन्, र तीमध्ये एउटा मात्र टनेलसँग सम्बन्धित छ। यदि प्रमाण अझ अगाडि जानुपर्ने भए, अर्को अवलोकन बिन्दु गेटवे वा सेवाको सीमा हो, जहाँ कसैले अनुरोध पुग्यो कि पुगेन देख्न सक्छ। Mac को नेटवर्क प्राथमिकताहरू रिसेट गर्दा तपाईंले मापन गरिरहेको अवस्था नष्ट हुन्छ र तपाईंलाई केही बताउँदैन।
अर्को व्यक्तिलाई आवश्यक पर्ने टिप्पणी लेख्नुहोस्
इन्टरफेसको नाम, काउन्टरको लेबल, अन्तराल, अघि र पछिका मानहरू, र एपको नतिजा। तपाईंको दिउँसो नदोहोर्याई सहकर्मीलाई अवलोकन पुनः उत्पादन गर्न यति नै पर्याप्त छ। क्लाइन्टको संस्करण र macOS को संस्करण थप्नुहोस्, किनकि काउन्टरको अर्थ संस्करणहरूबीच बदलिन सक्छ।
पूरा प्याकेट क्याप्चर र सिस्टम डम्प छोडिदिनुहोस्। एउटा अनुरोधको क्रममा कुन स्थानीय काउन्टर सर्यो भन्ने व्याख्या गर्न यी विरलै आवश्यक हुन्छन्, र प्रतिवेदन पढ्ने सबैलाई ढिलो बनाउँछन्। यदि क्लाइन्टले आफ्नै तथ्याङ्क देखाउँछ भने, त्यसको लेबललाई तपाईंकोमा अनुवाद गर्नुको सट्टा शब्दशः उद्धृत गर्नुहोस्। टिप्पणीको उद्देश्य के मापन भयो भन्ने अभिलेख राख्नु हो, यसको अर्थ के हो भनेर बहस गर्नु होइन।