Android, iOS आणि Windows वर पिंगशिवाय VPN स्थिती कशी तपासावी

192.0.2.10 ला पिंग केल्याने तुम्हाला फक्त एवढे कळते की एका पत्त्याने ICMP प्रतिध्वनीला उत्तर दिले, एवढेच. टनेल नसलेल्या नेटवर्कवरही ते यशस्वी होऊ शकते, कारण पत्ता स्थानिक सबनेटवर असू शकतो; निरोगी टनेल असतानाही ते अयशस्वी होऊ शकते, कारण सर्व्हर HTTPS देत असताना ICMP टाकून देतो. तुमच्या स्क्रिप्टला आवश्यक असलेली तपासणी म्हणजे प्लॅटफॉर्म स्थिती चौकशी आणि ॲप वापरत असलेल्या गंतव्यस्थानापर्यंत मार्ग चाचणी. त्यांना दोन स्वतंत्र फील्ड म्हणून घ्या, कधीही एक बुलियन म्हणून नाही.

प्रतिध्वनी उत्तर खरोखर काय सिद्ध करते

ICMP हा पोहोचक्षमता प्रोटोकॉल आहे ज्याला इंटरफेस किंवा टनेलची कल्पना नाही. उत्तर आल्यावर कर्नेल सांगते की एका होस्टने उत्तर दिले; विनंती कोणत्या मार्गाने गेली आणि उत्तर कोणत्या मार्गाने आले हे ते सांगत नाही. फिल्टरिंग सिग्नल अधिक गोंगाट करणारा बनवते, कारण प्रतिध्वनी विनंत्या अडवणारा फायरवॉल त्याच्या मागील पोर्टबद्दल काहीही सांगत नाही. आणि विभाजित टनेल प्रोफाइल चाचणी केलेला पत्ता जाणूनबुजून वगळू शकते, तर इतर सर्व गंतव्ये कार्यरत असतात.

तुम्हाला खरोखर जाणून घ्यायचे आहे की ॲप ज्या मार्गाने जाते त्या मार्गावर विशिष्ट सेवा वापरण्यायोग्य आहे का. ॲप कॉल करत असलेला होस्ट आणि पोर्ट निवडा, नंतर ॲप्लिकेशन स्तरावर उत्तराची मागणी करा.

पोहोचक्षमता आणि टनेलची स्थिती या वेगळ्या वस्तुस्थिती आहेत, आणि एक सत्य असताना दुसरी असत्य असू शकते. त्या वेगळ्या ठेवल्यास बिघाड कोणाचा आहे हे कळते. त्या एका तपासणीत एकत्र केल्यास असे तिकीट तयार होते जे कोणीही मार्गस्थ करू शकत नाही.

Android ला पिंग नाही, ट्रान्स्पोर्ट विचारा

Android स्थितीच्या प्रश्नाचे उत्तर ConnectivityManager द्वारे थेट देते. सक्रिय नेटवर्कच्या क्षमतांमध्ये VPN ट्रान्स्पोर्ट फ्लॅग असतो, जो रहदारी VPN इंटरफेसवरून मार्गस्थ होत असताना सेट होतो. हा कॉल स्थानिक, स्वस्त आणि कोणताही दूरचा होस्ट उत्तर देतो की नाही यावर अवलंबून नाही.

ही Java आवृत्ती सक्रिय नेटवर्क नसताना अपवाद टाकण्याऐवजी false परत करते. ती सक्रिय नेटवर्क वाचते, म्हणून वापरकर्त्याने सेटिंग्जमध्ये निवडलेले प्रोफाइल प्रतिबिंबित करते.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

बदलाच्या सूचनांसाठी, टाइमरवर पोलिंग करण्याऐवजी NetworkCallback नोंदवा. त्याला VpnService.prepare शी गोंधळू नका, जे फक्त वापरकर्त्याने VPN साठी परवानगी दिली का ते सांगते, पॅकेट वाहत आहेत का ते नाही. रद्द करणे VpnService.onRevoke द्वारे येते, पण सेटिंग्जमध्ये प्रोफाइल विसरल्याने कोणतेही प्रसारण होत नाही.

iOS: इंटरफेस नावे एक ह्युरिस्टिक आहेत, करार नाही

अनेक iOS स्निपेट्स प्रॉक्सी सेटिंग्ज तपासतात, __SCOPED__ शब्दकोश शोधतात आणि tap, tun, utun2, ppp किंवा ipsec सारख्या इंटरफेस की शोधतात. हा दृष्टिकोन नामकरणाची परंपरा आहे, दस्तऐवजीकृत हमी नाही, म्हणून इंटरफेसचे नाव बदलणारे OS अपडेट तो तोडू शकते. टनेलपेक्षा जास्त जगणाऱ्या जुन्या नोंदींसाठी true सांगण्याची प्रवृत्तीही त्याला आहे.

कॉन्फिगरेशन तुमच्या ॲपकडे असल्यास, त्याऐवजी NEVPNManager खरी स्थिती देते. ते तुमच्या ॲपने सुरू केलेल्या टनेलचे वर्णन करते; प्रति-ॲप VPN सह, इतर ॲप त्या टनेलच्या पूर्णपणे बाहेर असू शकतात.

स्थिती वाचण्यापूर्वी प्राधान्ये पुन्हा लोड करा, कारण टनेल वर-खाली होताना मूल्य बदलते:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

प्लॅटफॉर्म स्थिती फ्लॅग तरीही रहदारी पीअरपर्यंत पोहोचते हे सिद्ध करत नाही. तीच पोकळी मार्ग चाचणी भरते, आणि म्हणूनच सपोर्टसाठी एक बुलियन पुरत नाही.

Windows प्रोफाइल खरे स्थिती फील्ड उघड करतात

Windows VPN प्रोफाइल अडॅप्टरपासून वेगळे ठेवते, आणि Get-VpnConnection ला माहीत असलेल्या प्रत्येक प्रोफाइलसाठी ConnectionStatus दाखवते. Windows क्लायंट किंवा प्रोव्हिजनिंग पॅकेजद्वारे तयार केलेली प्रोफाइल येथे दिसतात. हे cmdlet सर्वसाधारण टनेल डिटेक्टर नाही.

नामांकित प्रोफाइलसाठी फील्ड वाचा, आणि प्रोफाइल सर्व वापरकर्त्यांची असल्यास -AllUserConnection जोडा:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

तृतीय-पक्ष क्लायंट त्यांचे टनेल सुरू असतानाही या cmdlet ला अदृश्य राहतात, म्हणून रिकामा निकाल म्हणजे अज्ञात, डिस्कनेक्ट नाही. अडॅप्टरच्या याद्याही तितक्याच दिशाभूल करणाऱ्या आहेत: विक्रेत्याचा अडॅप्टर निष्क्रिय असतानाही टिकू शकतो, आणि काही अडॅप्टर फक्त सत्रादरम्यान असतात. Windows च्या मालकीच्या प्रोफाइलसाठी rasdial शाखा करता येण्याजोगा एक्झिट कोड सांगतो. हे सर्व स्थानिक विश्वासाचे वर्णन करते, पीअरची पोहोच नाही.

स्थिती अधिक मार्ग: दोन-भाग तपासणी

कनेक्ट केलेली प्रोफाइल पॅकेट कुठे जातात याबद्दल काहीही सांगत नाही. विभाजित टनेलिंग टनेल सुरू ठेवून तुम्हाला महत्त्वाचे असलेले गंतव्य वगळू शकते. always-on प्रोफाइल मृत सर्व्हरसहही कनेक्ट राहतात, आणि टनेल पडल्यावर kill switch जाणूनबुजून रहदारी अडवतो.

दोन्ही स्तर तपासा: VPN ट्रान्स्पोर्ट किंवा प्रोफाइल सक्रिय आहे याची पुष्टी करा, नंतर गंतव्य त्या मार्गाने सोडवले जाते आणि उत्तर देते याची पुष्टी करा. Linux वर, कर्नेलला कोणता इंटरफेस वापरेल ते विचारा:

ip route get 192.0.2.10
resolvectl query intranet.example.test

क्लायंट तुमच्या नियंत्रणाबाहेर असल्यास, दोन्ही निकाल नोंदवा आणि नमुना स्तराकडे बोट दाखवू द्या. कनेक्ट आणि अयशस्वी मार्ग चाचणी विभाजित टनेलिंग, DNS किंवा धोरण सुचवते. डिस्कनेक्ट आणि कार्यरत मार्ग चाचणी म्हणजे दुसरा मार्ग रहदारी नेत आहे.

क्रमाने चालवता येणारी चाचणी

कोणतीही नेटवर्क स्थिती बदलण्यापूर्वी आधी प्लॅटफॉर्म स्थिती नोंदवा. होस्टनाव सोडवा आणि पत्ता कुटुंब नोंदवा, कारण AAAA नोंद A नोंदीपेक्षा वेगळा मार्ग घेऊ शकते. सेवा पोर्ट उघडा आणि केवळ हातमिळवणीऐवजी ॲप्लिकेशन उत्तराची मागणी करा. प्रत्येक निरीक्षण स्वतःच्या लॉग फील्डमध्ये ठेवा.

dig आणि curl असलेल्या Linux मशीनवर, तीन कमांड सोडवणूक, मार्ग आणि सेवा स्वतः झाकतात. टनेल सुरू असताना आणि नंतर बंद असताना त्या चालवा:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

चार स्वतंत्र फील्ड एका बुलियनपेक्षा चांगले आहेत, कारण स्थिती, DNS, मार्ग आणि धोरण स्वतंत्रपणे अयशस्वी होतात आणि वेगवेगळ्या टीमकडे जातात. टर्मिनलमधील पिंग चांगली हाताने तपासणी राहते. ऑटोमेशनसाठी ती कनेक्टिव्हिटीची खराब व्याख्या आहे, जिथे प्लॅटफॉर्म API आणि मार्ग चाचणी खऱ्या प्रश्नाचे उत्तर देतात.