Mac VPN utun ഇന്റർഫേസ് സജീവമാണ്, പക്ഷേ ട്രാഫിക് പോകുന്നില്ലേ? ifconfig പരിശോധിക്കുക

നിങ്ങൾ 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 ചലനം നിരീക്ഷിക്കുക. ഓരോ ഘട്ടവും വ്യത്യസ്ത പാളിയെ ഒഴിവാക്കുന്നു, ആദ്യം തെറ്റായി വരുന്നതാണ് പരിഹാരം വേണ്ടിടം.