Kiolesura cha utun cha VPN kwenye Mac kiko hai lakini trafiki inashindikana? Angalia ifconfig

Uliunganisha VPN, ukaendesha ifconfig, na ukapata ingizo utun4 lenye anwani. Tovuti uliyohitaji bado inaisha kwa muda. Pengo hili ni la kawaida: orodha inathibitisha kwamba kiolesura pepe kipo, si kwamba mteja wako anamiliki, kwamba njia unayojali inakichagua au kwamba pakiti zinapita ndani yake. Niliacha kuamini jina la kiolesura baada ya mchana mzima nikilaumu handaki isiyo sahihi kwenye kompyuta mpakato iliyokuwa na ingizo tatu za utun kabla ya kuweka kitu chochote.

Kile ambacho mstari wa utun unacho kweli

Endesha ifconfig -a unapotaka picha kamili. Ikiitwa bila hoja, ifconfig inachapisha tu violesura ambavyo viko hai sasa, ndiyo sababu handaki iliyoshindwa kuanza inaweza kukosekana kwenye matokeo ambayo watu hubandika kwenye tiketi. ifconfig -l inarudisha majina tu, na hiyo ni njia ya haraka zaidi kujua kama utun mpya ulionekana baada ya kuunganisha.

Kusoma kiolesura kimoja ndiko kunakoishi maelezo muhimu, na handaki iliyounganishwa kwa kawaida huonekana hivi.

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

Sehemu tatu hubeba jibu. UP na RUNNING zinasema kerneli iko tayari kutumia kiolesura. POINTOPOINT pamoja na --> anwani ya mwenza ni sahihi ya handaki na si ya kiungo halisi. mtu thamani inaeleza tabaka zima la ripoti za "inaunganisha, kisha inakwama", kwa sababu violesura vya utun kwa kawaida huinuka na MTU iliyopunguzwa, 1380 katika baadhi ya miundo ya macOS, na mteja anaweza kuipuuza. Orodha ya sehemu ni fupi vya kutosha kuipitia mara moja kwenye mwongozo wa ifconfig ambao Apple hutoa.

Pata mchakato ulio nyuma ya kiolesura

ifconfig haina dhana ya programu inayomiliki. Wateja wawili wa VPN, huduma ya mfumo na handaki iliyobaki kutoka wiki iliyopita zote hutoa ingizo zinazoonekana sawa katika ngazi hii. Kwenye Mac yangu mwenyewe, utun0 hadi utun3 zilikuwepo kabla ya kuweka kitu chochote; Continuity na iCloud Private Relay pia hutumia handaki, na hakuna hata moja yao ni muunganisho unaochunguza.

Kwa handaki zinazosajili usanidi na mfumo, scutil --nc list ni uwiano wa haraka zaidi, inachapisha kila usanidi na hali yake na kitambulisho cha huduma, na iliyounganishwa imewekwa alama hivyo.

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

Wateja wanaoendesha mchakato wao wa handaki badala ya kusajili usanidi hawaonekani kamwe hapo. Tunnelblick na openvpn ya mstari wa amri huanguka katika kundi hilo, kwa hivyo angalia pia jedwali la michakato: ps -Ao pid,comm | grep -i openvpn. Mara mchakato unamiliki handaki, nambari ya utun ni ya mchakato huo na si ya kitu kingine.

Jaribu anwani kabla ya kujaribu njia

Kiolesura kinaweza kuwa hai bila anwani inayoweza kutumika. Wasifu wa IPv6 pekee unaonyesha ingizo fe80:: la kiungo cha ndani na hakuna kitu kwenye mstari inet, na mteja aliyeshindwa kutumia anwani iliyosukumwa huacha umbo lile lile. Ikiwa lengo lako ni IPv4 na handaki haina anwani ya IPv4, swali la uelekezaji tayari limetatuliwa.

MTU inastahili ukaguzi tofauti, kwa sababu hitilafu hii haionekani kama tatizo la ukubwa. Inaonekana kama muunganisho unaojithibitisha kisha unanyamaza mara tu uhamishaji mkubwa unapoanza. Tuma uchunguzi ambao haupaswi kugawanywa, kwa ukubwa ambao pakiti inalingana na MTU ya kiolesura; kwa MTU ya 1400 mzigo ni baiti 1372:

ping -D -s 1372 10.8.0.5

Jibu linamaanisha pakiti za ukubwa huo zinapita kwenye handaki. Ukimya wakati ping ndogo zinafanikiwa unaonyesha MTU au kitu kinachotupa ICMP njiani, si uthibitishaji, ambao ulikuwa umekamilika kabla ya kupata kiolesura.

Thibitisha kuwa lengo linachagua handaki

Swali muhimu si kama utun4 lipo, bali kama trafiki kwa anwani moja maalum inatoka humo. route -n get inajibu hilo kwa lengo moja na inachapisha lango na kiolesura ambacho kingetumia:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Kama amri hiyo hiyo inaripoti en0, usanidi wako wa split tunneling unafanya kile kilichoambiwa na hakuna ukaguzi wa kiolesura utakaobadilisha hilo. Tumia netstat -rn -f inet unapohitaji njia chaguo-msingi na jedwali lote katika mtazamo mmoja.

Vihesabio huamua kama pakiti zinasonga kweli. netstat -ib inaripoti jumla za pakiti na baiti kwa kila kiolesura, ikiwa ni pamoja na ingizo za utun; nambari zinajilimbikiza, kwa hivyo zisome mara mbili kwa pengo na ulinganishe:

netstat -ib | grep utun4

Vihesabio vilivyoganda wakati programu inaendelea kujaribu vinamaanisha kerneli haikuwahi kukabidhi pakiti kwa kiolesura. Vihesabio vinavyopanda pande zote mbili wakati programu bado inashindikana huhamishia uchunguzi upande wa pili wa handaki.

Wakati hakuna utun inayoonekana kabisa

Orodha tupu ya violesura baada ya kuingia iliyoonekana kufanikiwa kwa kawaida inamaanisha handaki haikuanza kamwe, si kwamba ifconfig inaificha. Angalia hali ya mteja mwenyewe, kisha ya mfumo: Network Extension ambayo haikuidhinishwa kamwe, au ambayo macOS ilizima baada ya sasisho, haiachi kiolesura. Idhini iko katika System Settings chini ya Login Items & Extensions, na ingizo la zamani hapo linastahili kuwashwa upya kabla ya kuweka upya kitu chochote.

Uwekaji nambari wa utun si thabiti kati ya muunganisho upya. Unaweza kupata utun5 ambapo utun4 ilikuwepo dakika kumi zilizopita, kwa sababu kiolesura cha zamani kinabomolewa na kerneli inatoa kielekezi kinachofuata kilicho huru. Skripti zinazoweka jina kwa uthabiti huvunjika kimya wakati huo; badala yake linganisha na anwani au na njia.

Weka upande wa usomaji uwe wa kusoma tu. sudo ifconfig utun4 down inakatiza handaki, na kwenye wasifu wa handaki kamili inachukua pamoja kipindi chako cha mbali, ambayo ni biashara mbaya wakati ulikuwa unakusanya ushahidi tu. Hakuna unachohitaji hapa kinahitaji root: kusoma bendera, anwani na vihesabio kunafanya kazi kwa mtumiaji wako wa kawaida.

Fanya ukaguzi kwa mpangilio wakati mwingine handaki ya Mac inapotenda vibaya: thibitisha utun ilionekana kwa ifconfig -l, soma bendera zake, anwani na MTU, ihusishe na mchakato, uliza route -n get ni kiolesura kipi lengo linatumia, kisha angalia netstat -ib ikisonga. Kila hatua huondoa tabaka tofauti, na ya kwanza inayorudi vibaya ndipo mahali pa kurekebisha.