Android, iOS සහ Windows හි ping නොමැතිව VPN තත්ත්වය පරීක්ෂා කරන්නේ කෙසේද

ping සනාථ කරන්නේ එක් host එකක් පිළිතුරු දුන් බව පමණි, tunnel එක ක්‍රියාත්මක බව නොවේ. Android, iOS සහ Windows හි තත්ත්ව API වලින් අසන්න, පසුව ඔබේ යෙදුමට සැබවින්ම අවශ්‍ය මාර්ගය සත්‍යාපනය කරන්න.

192.0.2.10 වෙත ping කිරීමෙන් ඔබට කියන්නේ එක් ලිපිනයක් ICMP ප්‍රතිරාවයට පිළිතුරු දුන් බව පමණි, ඊට වඩා නැත. tunnel නොමැති ජාලයක එය තවමත් සාර්ථක විය හැක, ලිපිනය දේශීය උපජාලයේ තිබිය හැකි බැවිනි; නිරෝගී tunnel එකක් සමඟ එය අසාර්ථක විය හැක, මන්ද සේවාදායකය HTTPS සපයන අතරතුර ICMP ඉවත් කරන බැවිනි. ඔබේ script එකට අවශ්‍ය පරීක්ෂාව වන්නේ වේදිකා තත්ත්ව විමසුම සහ යෙදුම භාවිත කරන ගමනාන්තයට මාර්ග පරීක්ෂණයයි. ඒවා වෙන් වූ ක්ෂේත්‍ර දෙකක් ලෙස සලකන්න, කිසිවිටෙකත් එක් බූලියන් එකක් ලෙස නොව.

ප්‍රතිරාව පිළිතුරක් සැබවින්ම සනාථ කරන්නේ කුමක්ද

ICMP යනු interface හෝ tunnel පිළිබඳ අවබෝධයක් නොමැති ළඟාවීමේ ප්‍රොටොකෝලයකි. පිළිතුරක් පැමිණි විට, kernel එක host එකක් පිළිතුරු දුන් බව වාර්තා කරයි; ඉල්ලීම ගෙන ගිය මාර්ගය හෝ පිළිතුර ගෙන ආ මාර්ගය එය වාර්තා නොකරයි. පෙරහන සංඥාව තවත් ශබ්ද සහිත කරයි, මන්ද ප්‍රතිරාව ඉල්ලීම් අවහිර කරන firewall එකක් එහි පිටුපස ඇති ports ගැන කිසිවක් නොකියයි. තවද බෙදුණු tunnel profile එකකට අනෙක් සියලුම ගමනාන්ත ක්‍රියා කරන අතර පරීක්ෂා කළ ලිපිනය හිතාමතා බැහැර කළ හැක.

ඔබට සැබවින්ම දැනගැනීමට අවශ්‍ය වන්නේ යෙදුම ගමන් කරන මාර්ගයේ නිශ්චිත සේවාවක් භාවිත කළ හැකිද යන්නයි. යෙදුම ඇමතුම් කරන host සහ port තෝරන්න, පසුව යෙදුම් ස්ථරයේ පිළිතුරක් ඉල්ලා සිටින්න.

ළඟාවීම සහ tunnel තත්ත්වය වෙනස් කරුණු වන අතර, එකක් සත්‍ය වන විට අනෙක අසත්‍ය විය හැක. ඒවා වෙන් කර තැබීමෙන් දෝෂය කාගේදැයි දැනගත හැක. ඒවා එක් පරීක්ෂාවකට එකතු කිරීමෙන් කිසිවෙකුට මාර්ගගත කළ නොහැකි ටිකට් එකක් සෑදේ.

Android වෙතින් ping නොව ප්‍රවාහනය අසන්න

Android තත්ත්ව ප්‍රශ්නයට ConnectivityManager හරහා සෘජුවම පිළිතුරු දෙයි. සක්‍රීය ජාලයේ හැකියාවන් VPN ප්‍රවාහන ධජයක් දරයි, එය ගමනාගමනය VPN interface එකක් හරහා මාර්ගගත වන විට සකසයි. ඇමතුම දේශීය, ලාභදායී සහ දුරස්ථ host එකක් පිළිතුරු දෙන්නේද යන්නෙන් ස්වාධීනය.

මෙම Java අනුවාදය සක්‍රීය ජාලයක් නොමැති විට ව්‍යතිරේකයක් විසි කරනවාට වඩා false ලෙස ලබා දෙයි. එය සක්‍රීය ජාලය කියවන බැවින්, පරිශීලකයා සැකසීම් තුළ තෝරාගත් profile එක පිළිබිඹු කරයි.

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

වෙනස්කම් දැනුම්දීම් සඳහා, timer එකකින් විමසනවාට වඩා NetworkCallback ලියාපදිංචි කරන්න. එය VpnService.prepare සමඟ පටලවා නොගන්න, එය පරිශීලකයා VPN සඳහා අවසරය ලබා දුන්නේද යන්න පමණක් වාර්තා කරයි, packet ගලා යන්නේද යන්න නොවේ. අවලංගු කිරීම VpnService.onRevoke හරහා පැමිණේ, නමුත් සැකසීම් තුළ profile එකක් අමතක කිරීම කිසිදු විකාශනයක් නොසාදයි.

iOS: interface නාම heuristic එකකි, ගිවිසුමක් නොවේ

බොහෝ iOS කොටස් proxy සැකසීම් පරීක්ෂා කර, __SCOPED__ ශබ්දකෝෂය සොයාගෙන, tap, tun, utun2, ppp හෝ ipsec වැනි interface යතුරු සොයයි. එම ප්‍රවේශය නාමකරණ සම්මුතියකි, ලේඛනගත සහතිකයක් නොවේ, එබැවින් interface එකක් නැවත නම් කරන OS යාවත්කාලීනයක් එය කඩා දැමිය හැක. tunnel එකට වඩා ජීවත් වන පැරණි සටහන් සඳහා true වාර්තා කිරීමේ ප්‍රවණතාවයද එයට ඇත.

වින්‍යාසය ඔබේ යෙදුම සතු විට, ඒ වෙනුවට NEVPNManager සැබෑ තත්ත්වයක් ලබා දෙයි. එය ඔබේ යෙදුම ආරම්භ කළ tunnel එක විස්තර කරයි; යෙදුම්-එකකට VPN සමඟ, අනෙක් යෙදුම් එම tunnel එකෙන් සම්පූර්ණයෙන් පිටත සිටිය හැක.

තත්ත්වය කියවීමට පෙර මනාප යළි පූරණය කරන්න, මන්ද tunnel එක ඉහළ යන සහ පහත වන විට අගය වෙනස් වේ:

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

වේදිකා තත්ත්ව ධජය තවමත් ගමනාගමනය peer වෙත ළඟා වන බව සනාථ නොකරයි. එම හිඩැස මාර්ග පරීක්ෂණය ආවරණය කරයි, එබැවින් සහාය සඳහා එක් බූලියන් එකක් ප්‍රමාණවත් නොවේ.

Windows profiles සැබෑ තත්ත්ව ක්ෂේත්‍රයක් නිරාවරණය කරයි

Windows VPN profiles adapters වලින් වෙන් වශයෙන් නිරීක්ෂණය කරයි, සහ Get-VpnConnection එය දන්නා සෑම profile එකකටම ConnectionStatus නිරාවරණය කරයි. Windows සේවාදායකය හෝ සැපයුම් පැකේජය හරහා සාදන ලද profiles මෙහි දිස්වේ. මෙම cmdlet සාමාන්‍ය tunnel අනාවරකයක් නොවේ.

නම් කළ profile එකක් සඳහා ක්ෂේත්‍රය කියවන්න, profile එක සියලු පරිශීලකයන්ට අයත් වන විට -AllUserConnection එකතු කරන්න:

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

තෙවන පාර්ශව සේවාදායක බොහෝ විට ඔවුන්ගේ tunnel ක්‍රියාත්මක වන විට පවා මෙම cmdlet ට නොපෙනී පවතී, එබැවින් හිස් ප්‍රතිඵලයක් යනු නොදන්නා බවයි, විසන්ධි වීම නොවේ. adapter ලැයිස්තු ද එලෙසම නොමඟ යවයි: සැපයුම්කරුගේ adapter එකක් නිෂ්ක්‍රීයව පවතින අතරතුර පැවතිය හැක, සහ සමහර adapters සැසියක් තුළ පමණක් පවතී. Windows සතු profile එකක් සඳහා rasdial ශාඛා කළ හැකි පිටවීම් කේතයක් වාර්තා කරයි. මේ සියල්ල දේශීය විශ්වාසය විස්තර කරයි, peer ළඟාවීම නොවේ.

තත්ත්වය සහ මාර්ගය: දෙකොටස් පරීක්ෂාව

සම්බන්ධිත profile එකක් packet යන්නේ කොහේද යන්න ගැන කිසිවක් නොකියයි. බෙදුණු tunnelling එකක් tunnel එක ක්‍රියාත්මකව තබා ඔබට වැදගත් ගමනාන්තය බැහැර කළ හැක. always-on profiles මළ සේවාදායකයක් සමඟද සම්බන්ධව පවතී, සහ tunnel එක වැටෙන විට kill switch ගමනාගමනය හිතාමතා අවහිර කරයි.

ස්ථර දෙකම පරීක්ෂා කරන්න: VPN ප්‍රවාහනයක් හෝ profile එකක් සක්‍රීය බව තහවුරු කරන්න, පසුව ගමනාන්තය එම මාර්ගයෙන් විසඳා පිළිතුරු දෙන බව තහවුරු කරන්න. Linux හි, kernel එකෙන් භාවිත කරන interface එක අසන්න:

ip route get 192.0.2.10
resolvectl query intranet.example.test

සේවාදායකය ඔබේ පාලනයෙන් පිටත වන විට, ප්‍රතිඵල දෙකම ලොග් කර රටාව ස්ථරයට යොමු කිරීමට ඉඩ දෙන්න. සම්බන්ධිත සහ අසාර්ථක මාර්ග පරීක්ෂණය බෙදුණු tunnelling, DNS හෝ ප්‍රතිපත්තිය යෝජනා කරයි. විසන්ධි සහ ක්‍රියාකාරී මාර්ග පරීක්ෂණය යනු වෙනත් මාර්ගයක් ගමනාගමනය ගෙන යන බවයි.

පිළිවෙලින් ධාවනය කළ හැකි පරීක්ෂණයක්

කිසිදු ජාල තත්ත්වයක් වෙනස් කිරීමට පෙර මුලින්ම වේදිකා තත්ත්වය සටහන් කරන්න. host නාමය විසඳා ලිපින පවුල සටහන් කරන්න, මන්ද AAAA වාර්තාවක් A වාර්තාවකට වඩා වෙනස් මාර්ගයක් ගත හැක. සේවා port එක විවෘත කර හුදෙක් handshake එකක් වෙනුවට යෙදුම් පිළිතුරක් ඉල්ලා සිටින්න. සෑම නිරීක්ෂණයක්ම එහිම ලොග් ක්ෂේත්‍රයේ තබන්න.

dig සහ curl සහිත Linux යන්ත්‍රයක, විධාන තුනක් විසඳීම, මාර්ගය සහ සේවාවම ආවරණය කරයි. tunnel එක ඉහළ ඇති විට සහ නැවත පහත ඇති විට ඒවා ධාවනය කරන්න:

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 සහ මාර්ග පරීක්ෂණය සැබෑ ප්‍රශ්නයට පිළිතුරු දෙයි.

අදාළ ලිපි