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 અને માર્ગ પરીક્ષણ ખરા પ્રશ્નનો જવાબ આપે છે.