Android, iOS र Windows मा ping बिना VPN स्थिति कसरी जाँच्ने

192.0.2.10 मा ping गर्दा तपाईंलाई एउटा ठेगानाले ICMP इकोलाई जवाफ दियो भन्ने मात्र थाहा हुन्छ, त्यति मात्र। टनेल नभएको नेटवर्कमा पनि यो सफल हुन सक्छ, किनभने ठेगाना स्थानीय सबनेटमा हुन सक्छ; स्वस्थ टनेल हुँदा पनि यो असफल हुन सक्छ, किनभने सर्भरले HTTPS सेवा गर्दा ICMP छोडिदिन्छ। तपाईंको स्क्रिप्टलाई चाहिने जाँच भनेको प्लेटफर्म स्थिति प्रश्न र एपले प्रयोग गर्ने गन्तव्यसम्मको मार्ग परीक्षण हो। यिनलाई दुई छुट्टै फिल्डका रूपमा लिनुहोस्, कहिल्यै एउटै बुलियनका रूपमा होइन।

इको जवाफले साँच्चै के प्रमाणित गर्छ

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

तपाईं साँच्चै जान्न चाहनुभएको कुरा भनेको एपले हिँड्ने मार्गमा कुनै विशेष सेवा प्रयोगयोग्य छ कि छैन भन्ने हो। एपले कल गर्ने होस्ट र पोर्ट छान्नुहोस्, त्यसपछि एप्लिकेसन तहमा जवाफको माग गर्नुहोस्।

पहुँचयोग्यता र टनेल स्थिति बेग्लाबेग्लै तथ्य हुन्, र एउटा सत्य हुँदा अर्को असत्य हुन सक्छ। तिनलाई छुट्टाएर राख्दा खराबी कसको हो भन्ने थाहा हुन्छ। तिनलाई एउटै जाँचमा मिलाउँदा कसैले पनि रुट गर्न नसक्ने टिकट बन्छ।

Android लाई ping होइन, ट्रान्सपोर्ट सोध्नुहोस्

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, मार्ग र नीति स्वतन्त्र रूपमा असफल हुन्छन् र फरक-फरक टोलीमा पुग्छन्। टर्मिनलको ping राम्रो म्यानुअल जाँच रहन्छ। स्वचालनका लागि यो कनेक्टिभिटीको कमजोर परिभाषा हो, जहाँ प्लेटफर्म API र मार्ग परीक्षणले वास्तविक प्रश्नको जवाफ दिन्छन्।