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 चा प्रश्न सोपा होतो: जे ज्ञात आहे ते त्याच्या वयासह दाखवा, आणि जेव्हा अज्ञात असेल तेव्हा अज्ञात म्हणा।