Mac VPN utun අතුරුමුහුණත සක්‍රීයයි, නමුත් ගමන් කරන දත්ත අසාර්ථකද? ifconfig පරීක්ෂා කරන්න

ifconfig utun නම, ලිපිනය සහ MTU පෙන්වයි, නමුත් එය අයිති කුමන යෙදුමටද හෝ පැකට්ටු යන්නේ කොහේද යන්න නොපෙන්වයි. සැබෑ ප්‍රශ්නයට පිළිතුරු දෙන කියවීම-පමණක් පරීක්ෂණ පහක්.

ඔබ VPN සම්බන්ධ කළා, ifconfig ධාවනය කළා, සහ ලිපිනයක් සහිත utun4 සටහනක් හමු වුණා. ඔබට අවශ්‍ය වූ අඩවිය තවමත් කාලය ඉකුත් වී අවසන් වෙනවා. මෙම පරතරය සාමාන්‍යයි: ලැයිස්තුව ඔප්පු කරන්නේ අතථ්‍ය අතුරුමුහුණතක් පවතින බවයි, ඔබේ සේවාදායකය එයට හිමිකම් කියන බව, ඔබට වැදගත් මාර්ගය එය තෝරන බව හෝ පැකට්ටු එය හරහා යන බව නොවේ. කිසිවක් ස්ථාපනය කිරීමට පෙරම utun සටහන් තුනක් තිබූ ලැප්ටොප් පරිගණකයක වැරදි උමගට දොස් පවරමින් සවසක් ගත කිරීමෙන් පසු මම අතුරුමුහුණතේ නාමය විශ්වාස කිරීම නතර කළා.

utun පේළියක ඇත්තටම අඩංගු වන්නේ කුමක්ද

සම්පූර්ණ චිත්‍රය අවශ්‍ය විට ifconfig -a ධාවනය කරන්න. තර්ක නොමැතිව අමතන විට, ifconfig දැන් සක්‍රීයව ඇති අතුරුමුහුණත් පමණක් මුද්‍රණය කරයි, එබැවින් ආරම්භ නොවූ උමගක් මිනිසුන් ටිකට්වල අලවන ප්‍රතිදානයෙන් අස්ථානගත විය හැකියි. ifconfig -l නම් පමණක් ලබා දෙයි, සම්බන්ධ කිරීමෙන් පසු නව utun එකක් පෙනුණාදැයි දැනගැනීමට ඇති වේගවත්ම ක්‍රමය එයයි.

එක් අතුරුමුහුණතක් කියවීම යනු ප්‍රයෝජනවත් විස්තරය ජීවත් වන තැනයි, සහ සම්බන්ධිත උමගක් සාමාන්‍යයෙන් මෙලෙස පෙනේ.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

ක්ෂේත්‍ර තුනක් පිළිතුර දරයි. UP සහ RUNNING කර්නලය අතුරුමුහුණත භාවිත කිරීමට කැමති බව කියයි. POINTOPOINT සමඟ --> සමවයස් ලිපිනය භෞතික සබැඳියක් නොව උමං අත්සනකි. mtu අගය "සම්බන්ධ වෙයි, පසුව නතර වෙයි" යන වාර්තා පන්තියම පැහැදිලි කරයි, මන්ද utun අතුරුමුහුණත් සාමාන්‍යයෙන් අඩු කළ MTU එකක් සමඟ ඉහළ එන අතර, macOS ගොඩනැගීම් කිහිපයක 1380, සහ සේවාදායකයට එය ඉක්මවා යා හැකියි. ක්ෂේත්‍ර ලැයිස්තුව එක් වරක් බැලීමට තරම් කෙටියි, Apple සපයන ifconfig අත්පොතෙහි.

අතුරුමුහුණත පිටුපස ඇති ක්‍රියාවලිය සොයන්න

ifconfig හට හිමිකාර යෙදුම පිළිබඳ සංකල්පයක් නැත. VPN සේවාදායක දෙකක්, පද්ධති සේවාවක් සහ පසුගිය සතියේ ඉතිරි වූ උමගක් සියල්ලම මෙම මට්ටමේ සමානව පෙනෙන සටහන් සාදයි. මගේම Mac එකේද, utun0 සිට utun3 දක්වා මම කිසිවක් වින්‍යාස නොකළ මුල් කාලයේම තිබුණා; Continuity සහ iCloud Private Relay ද උමං භාවිත කරයි, ඒවායින් කිසිවක් ඔබ රෝග විනිශ්චය කරන සම්බන්ධතාව නොවේ.

පද්ධතිය සමඟ වින්‍යාසයක් ලියාපදිංචි කරන උමං සඳහා, scutil --nc list වේගවත්ම සහසම්බන්ධයයි, එය සෑම වින්‍යාසයක්ම එහි තත්ත්වය සහ සේවා ID සමඟ මුද්‍රණය කරයි, සහ සම්බන්ධිත එකක් එසේ සලකුණු කර ඇත.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

වින්‍යාසයක් ලියාපදිංචි කරනු වෙනුවට තමන්ගේම උමං ක්‍රියාවලියක් ධාවනය කරන සේවාදායක එහි කිසිදා නොපෙනේ. Tunnelblick සහ විධාන රේඛා openvpn අවස්ථාව එම කණ්ඩායමට වැටේ, එබැවින් ක්‍රියාවලි වගුව ද පරීක්ෂා කරන්න: ps -Ao pid,comm | grep -i openvpn. ක්‍රියාවලියක් උමගට හිමිකම් කළ පසු, utun අංකය එම ක්‍රියාවලියට පමණක් අයත් වේ, වෙන කිසිවකට නොවේ.

මාර්ගය පරීක්ෂා කිරීමට පෙර ලිපිනය පරීක්ෂා කරන්න

අතුරුමුහුණතක් භාවිත කළ හැකි ලිපිනයක් නොමැතිව සක්‍රීය විය හැකියි. IPv6-පමණක් පැතිකඩක් සබැඳි-දේශීය fe80:: සටහනක් පෙන්වන අතර inet පේළියේ කිසිවක් නොපෙන්වයි, සහ තල්ලු කළ ලිපිනය යෙදීමට අසමත් වූ සේවාදායකයාද හරියටම එම හැඩයම ඉතිරි කරයි. ඔබේ ගමනාන්තය IPv4 නම් සහ උමගට IPv4 ලිපිනයක් නොමැති නම්, මාර්ගගත කිරීමේ ප්‍රශ්නය දැනටමත් විසඳී ඇත.

MTU වෙනම පරීක්ෂාවක් ලැබිය යුතුයි, මන්ද මෙම අසාර්ථකත්වය ප්‍රමාණ ගැටලුවක් ලෙස නොපෙනේ. එය සත්‍යාපනය වී පසුව විශාල මාරුවක් ආරම්භ වූ වහාම නිහඬ වන සම්බන්ධතාවක් ලෙස පෙනේ. කැබලි නොකළ යුතු පරීක්ෂණයක්, පැකට්ටුව අතුරුමුහුණතේ MTU ට ගැළපෙන ප්‍රමාණයෙන් යවන්න; MTU 1400 නම් ගෙවීම 1372 බයිට් වේ:

ping -D -s 1372 10.8.0.5

පිළිතුරක් ලැබුණොත් එම ප්‍රමාණයේ පැකට්ටු උමග හරහා යනවා. කුඩා පිං සාර්ථක වන විට නිහඬතාව MTU එකට හෝ මාර්ගයේ ICMP ඉවත දමන දෙයකට යොමු කරයි, සත්‍යාපනයට නොවේ, එය ඔබට අතුරුමුහුණතක් ලැබීමටත් පෙර අවසන් වී තිබුණි.

ගමනාන්තය උමග තෝරන බව ඔප්පු කරන්න

වැදගත් ප්‍රශ්නය utun4 තිබේද යන්න නොව, එක් නිශ්චිත ලිපිනයකට යන දත්ත එයින් පිටව යන්නේද යන්නයි. route -n get එක් ගමනාන්තයක් සඳහා එයට පිළිතුරු දෙන අතර භාවිත කරන ද්වාරය සහ අතුරුමුහුණත මුද්‍රණය කරයි:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

එම විධානයම en0 ලෙස වාර්තා කරන්නේ නම්, ඔබේ split tunneling වින්‍යාසය කී දේ කරමින් සිටී, අතුරුමුහුණත කොපමණ පරීක්ෂා කළත් එය වෙනස් නොවේ. netstat -rn -f inet භාවිත කරන්න පෙරනිමි මාර්ගය සහ සම්පූර්ණ වගුව එක් දසුනකින් අවශ්‍ය විට.

පැකට්ටු ඇත්තටම ගමන් කරනවාද යන්න කවුන්ටර තීරණය කරයි. netstat -ib utun සටහන් ඇතුළුව එක් එක් අතුරුමුහුණතෙහි පැකට්ටු සහ බයිට් එකතුව වාර්තා කරයි; සංඛ්‍යා සමුච්චිතයි, එබැවින් ඒවා පරතරයකින් දෙවරක් කියවා සසඳන්න:

netstat -ib | grep utun4

යෙදුම නැවත උත්සාහ කරන අතර කවුන්ටර අවහිර වී ඇත්නම්, කර්නලය කිසිදා පැකට්ටුවක් අතුරුමුහුණතට භාර දී නැත. යෙදුම තවමත් අසාර්ථක වන අතර කවුන්ටර දෙදිශාවටම ඉහළ යන්නේ නම්, විමර්ශනය උමගේ අනෙක් කෙළවරට ගමන් කරයි.

utun කිසිසේත් නොපෙනෙන විට

සාර්ථක ලෙස පෙනුණු පිවිසුමකින් පසු අතුරුමුහුණත් ලැයිස්තුව හිස් නම්, සාමාන්‍යයෙන් උමග කිසිදා ආරම්භ නොවී යන්නයි, ifconfig එය සඟවනවා නොවේ. සේවාදායකයේම තත්ත්වය, පසුව පද්ධතියේ තත්ත්වය පරීක්ෂා කරන්න: කිසිදා අනුමත නොවූ හෝ යාවත්කාලීනයකින් පසු macOS අක්‍රීය කළ Network Extension එකක් පිටුපස අතුරුමුහුණතක් ඉතිරි නොකරයි. අනුමැතිය System Settings තුළ, Login Items & Extensions යටතේ ඇත, සහ එහි ඇති පැරණි සටහනක් කිසිවක් නැවත ස්ථාපනය කිරීමට පෙර නැවත සක්‍රීය කිරීම වටී.

utun අංකනය නැවත සම්බන්ධ වීම් අතර ස්ථාවර නොවේ. ඔබට utun5 ලැබිය හැකියි utun4 මිනිත්තු දහයකට පෙර තිබූ තැන, මන්ද පැරණි අතුරුමුහුණත කඩා දමනු ලබන අතර කර්නලය ඊළඟ නිදහස් දර්ශකය ලබා දෙයි. නාමය දෘඩ ලෙස ලියන ලද ස්ක්‍රිප්ට් එම මොහොතේ නිශ්ශබ්දව කැඩී යයි; ඒ වෙනුවට ලිපිනය හෝ මාර්ගය සමඟ ගළපන්න.

කියවීමේ පැත්ත කියවීමට-පමණක් තබන්න. sudo ifconfig utun4 down උමගට බාධා කරයි, සහ සම්පූර්ණ-උමං පැතිකඩක එය ඔබේ දුරස්ථ සැසියද රැගෙන යයි, එය සාක්ෂි රැස් කරන විට නරක මාරුවකි. මෙහි අවශ්‍ය කිසිවකට root අවශ්‍ය නැත: ධජ, ලිපින සහ කවුන්ටර කියවීම ඔබේ සාමාන්‍ය පරිශීලකයාට ක්‍රියා කරයි.

ඊළඟ වතාවේ Mac උමගක් නරක ලෙස හැසිරුණොත් පරීක්ෂණ පිළිවෙලට කරන්න: ifconfig -l සමඟ utun පෙනුණාදැයි තහවුරු කරන්න, එහි ධජ, ලිපින සහ MTU කියවන්න, එය ක්‍රියාවලියකට ආරෝපණය කරන්න, route -n get ගෙන් ගමනාන්තය භාවිත කරන අතුරුමුහුණත විමසන්න, පසුව netstat -ib චලනය නිරීක්ෂණය කරන්න. සෑම පියවරක්ම වෙනස් ස්ථරයක් බැහැර කරයි, සහ මුලින්ම වැරදි ලෙස පැමිණෙන පියවර යනු නිවැරදි කිරීම අවශ්‍ය තැනයි.

අදාළ ලිපි