C# OpenVPN स्थिति अवलोकनकर्ता: सत्र हेर्नुहोस्, NIC होइन

टनेल मर्दै गर्दा पनि तपाईंको एप्लिकेसन काम गरिरहन्छ। Wi-Fi अझै सक्रिय छ, इन्टरनेट अझै जवाफ दिन्छ, र एप्लिकेसन जुन निजी API मा निर्भर छ त्यो पहुँचविहीन भएको छ। मानिसहरूले यहाँ सामान्यतया जुन .NET घटनातिर लाग्छन्, NetworkAvailabilityChanged, त्यसले त्यो अवस्थाको बिल्कुल वर्णन गर्दैन। त्यसले मेसिनको समग्र स्थितिमा भएको परिवर्तन रिपोर्ट गर्छ, र VPN डिस्कनेक्ट र पुनः जडान हुँदा पनि त्यो स्थिति सत्य रहन सक्छ। अवलोकनकर्ताले टनेलको मालिक क्लाइन्ट हेर्नुपर्छ, नेटवर्क स्ट्याकको सारांश होइन।

उपलब्धता समग्र मान हो, तपाईंको टनेल होइन

NetworkAvailabilityChanged मेसिनको समग्र उपलब्धता जवाफ बदलिँदा सक्रिय हुन्छ, र त्यो जवाफले loopback वा टनेलबाहेक प्रत्येक सक्रिय इन्टरफेस गणना गर्छ।

Wi-Fi सक्रिय हुँदा VPN खस्दा त्यसले नाप्ने कुनै पनि कुरा बदलिँदैन, त्यसैले तपाईंलाई महत्त्वपूर्ण भएको ठ्याक्कै त्यही खराबीको समयमा घटना शान्त रहन सक्छ।

स्थिति प्रवाह टनेलको मालिक क्लाइन्टको हो

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

व्यवस्थापन च्यानल विशेषाधिकार प्राप्त नियन्त्रण सतह हो, त्यसैले नयाँ श्रोता नखोल्नुहोस् र GUI सँग पहिले नै भएको च्यानलका लागि नझगड्नुहोस्।

पुस्ता रक्षकहरूले पुराना नतिजा रोक्छन्

प्रत्येक अवलोकन विशिष्ट जडान प्रयासको हो। नयाँ प्रयास सुरु हुँदा, च्यानल हराउँदा र क्लाइन्टले बाहिरिएको रिपोर्ट गर्दा पुस्ता काउन्टर बढाउनुहोस्।

A जडानका बेला सुरु भएको जाँच विचार गर्नुहोस्। टनेल खस्छ, B जडान सुरु हुन्छ, र त्यसपछि A को ढिलो HTTP सफलता आउँछ। रक्षक नभए त्यो पुरानो नतिजाले B अझै प्रमाणित हुँदै गर्दा डिस्प्ले हरियो बनाउँछ। रद्द गर्नाले बर्बाद हुने काम घट्छ, र पुस्ता जाँचले नै पुरानो पूर्णता हालको स्थिति बन्नबाट रोक्छ:

var generation = _generation;
var reachable = await ProbeAsync(token);
if (generation != _generation) return;
Publish(reachable);

UI पठाउने वरिपरि पनि त्यही नियम लागू गर्नुहोस्, किनकि मार्शल गरिएको अपडेट पुस्ता अगाडि गएपछि पनि आउन सक्छ।

सुरुवात र पुनः जडान एउटै जीवनचक्र हो

पहिलो जडान, पुनः जडान र च्यानल हानिलाई एउटै नियमसमूहसहित एउटै जीवनचक्र मान्नुहोस्:

• इन्टरफेसले अनुमति दिएको ठाउँमा एउटै चरणमा हालको स्थिति पढ्नुहोस् र सूचनाहरू सदस्यता लिनुहोस्।
• प्रत्येक अवलोकनलाई जडान पहिचान र पुस्ताले ट्याग गर्नुहोस्।
• पुनः जडान, बाहिरिने वा हराएको अवलोकन च्यानलमा तयारी अवैध गर्नुहोस्।
• मालिकले सुरुवात पूरा भएको रिपोर्ट गरेपछि मात्र निजी स्रोत जाँच्नुहोस्।
• अझै हालको पुस्ताका नतिजा मात्र प्रकाशित गर्नुहोस्।

हराएको च्यानल भन्नाले अज्ञात, विच्छेदित होइन। अज्ञात रिपोर्ट गर्नु प्रमाणित गर्न नसकिने विच्छेद रिपोर्ट गर्नुभन्दा इमानदार हुन्छ, र यसले पुनः प्रयास तर्कलाई अनुमानमा काम गर्नबाट रोक्छ।

प्रमाण रिपोर्ट गर्नुहोस्, बुलियन होइन

नामकृत सत्र स्थिति र स्रोत तयारी अलग मानका रूपमा फर्काउनुहोस्, प्रत्येकसँग उमेर। निर्णय गर्नुपर्ने उपभोक्ताले त्यसपछि देख्न सक्छ कि अन्तिम सफल जाँच चालीस सेकेन्ड पुरानो छ, जुन ताजा जानकारीभन्दा फरक जानकारी हो।

सार्वजनिक IP खोज यो प्रमाण होइन कि निजी API ले आवश्यक मार्ग प्रयोग गर्यो, त्यसैले यसलाई त्यस्तै हो जस्तो प्रस्तुत नगर्नुहोस्।

प्रवर्तन अवलोकनकर्ताबाहिर राख्नुहोस्

कलब्याक घटनापछि चल्छ। घटना र ह्यान्डलरबीच मेसिनबाट कुनै प्याकेट गएन भन्ने यसले ग्यारेन्टी दिन सक्दैन। यदि डिजाइनलाई अवरोध चाहिन्छ भने नेटवर्किङ नीतिले त्यो दिनुपर्छ, र अवलोकनकर्ताको काम आफ्नो कलरलाई प्रमाण बुझाउनु हो। दुवै मिसाउँदा बुलियन राखेकै कारण आफूलाई फायरवाल ठान्ने कोड बन्छ। प्रवर्तन तहलाई निरस र परीक्षणयोग्य राख्नुहोस्, र अवलोकनकर्तालाई पाठक नै रहन दिनुहोस्।

त्यसपछि UI को प्रश्न सरल हुन्छ: जे ज्ञात छ त्यो यसको उमेरसहित देखाउनुहोस्, र अज्ञात हुँदा अज्ञात भन्नुहोस्।