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-ով՝ 1380 macOS-ի մի քանի կառուցվածքներում, և հաճախորդը կարող է այն վերագրանցել։ Դաշտերի ցանկն այնքան կարճ է, որ մեկ անգամ կարելի է նայել 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-ին. 1400 MTU-ի դեպքում բեռնվածությունը 1372 բայթ է:

ping -D -s 1372 10.8.0.5

Պատասխանը նշանակում է, որ այդ չափի փաթեթներն անցնում են թունելով։ Լռությունը, երբ փոքր ping-երը հաջողվում են, մատնանշում է MTU-ին կամ ուղու վրա ICMP-ն գցող ինչ-որ բանի, այլ ոչ նույնականացմանը, որն արդեն ավարտվել էր նախքան ինտերֆեյս ստանալը։

Ապացուցեք, որ նպատակակետն է ընտրում թունելը

Կարևոր հարցը ոչ թե այն է, թե արդյոք utun4 գոյություն ունի, այլ այն, թե արդյոք դեպի մեկ կոնկրետ հասցե տրաֆիկը դուրս է գալիս դրա միջով։ route -n get-ը պատասխանում է դրան մեկ նպատակակետի համար և տպում է դարպասը և ինտերֆեյսը, որոնք կօգտագործվեին:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Եթե նույն հրամանը հաղորդում է en0, ապա ձեր բաժանված թունելի կարգավորումը անում է այն, ինչ ասվել է նրան, և ինտերֆեյսի ոչ մի ստուգում դա չի փոխի։ Օգտագործեք netstat -rn -f inet-ը, երբ անհրաժեշտ են լռելյայն երթուղին և ամբողջ աղյուսակը մեկ տեսքով։

Հաշվիչներն են որոշում՝ փաթեթներն իսկապես շարժվում են։ netstat -ib-ը հաղորդում է փաթեթների և բայթերի ընդհանուրները յուրաքանչյուր ինտերֆեյսի համար՝ ներառյալ utun գրառումները. թվերը կուտակային են, այնպես որ կարդացեք դրանք երկու անգամ՝ ընդմիջումով, և համեմատեք:

netstat -ib | grep utun4

Սառեցված հաշվիչները, երբ հավելվածը շարունակում է կրկնել փորձը, նշանակում են, որ միջուկը երբեք փաթեթ չի հանձնել ինտերֆեյսին։ Երկու ուղղությամբ աճող հաշվիչները, երբ հավելվածը դեռ ձախողվում է, հետազոտությունը տեղափոխում են թունելի հեռավոր ծայրը։

Երբ ընդհանրապես utun չի հայտնվում

Հաջող թվացող մուտքից հետո դատարկ ինտերֆեյսների ցանկը սովորաբար նշանակում է, որ թունելը երբեք չի մեկնարկել, ոչ այն, որ ifconfig-ը թաքցնում է այն։ Ստուգեք հաճախորդի սեփական կարգավիճակը, ապա համակարգինը. ցանցային ընդլայնումը, որը երբեք չի հաստատվել կամ որը macOS-ը անջատել է թարմացումից հետո, իր հետևից ինտերֆեյս չի թողնում։ Հաստատումը գտնվում է Համակարգի կարգավորումներում՝ Login Items & Extensions-ի տակ, և այնտեղի հնացած գրառումը արժե մեկ անգամ նորից փոխարկել նախքան որևէ բան վերատեղադրելը։

utun համարակալումը կայուն չէ վերամիացումների միջև։ Դուք կարող եք ստանալ utun5 այնտեղ, որտեղ տասը րոպե առաջ utun4 կար, որովհետև հին ինտերֆեյսը քանդվում է, և միջուկը տալիս է հաջորդ ազատ ինդեքսը։ Անունը կոշտ կոդավորող սկրիպտները այդ պահին լուռ կոտրվում են. ավելի լավ է համադրել հասցեով կամ երթուղով։

Ընթերցման կողմը պահեք միայն-ընթերցվող։ sudo ifconfig utun4 down-ը ընդհատում է թունելը, և ամբողջական թունելի պրոֆիլում այն տանում է նաև ձեր հեռավոր սեսիան, ինչը վատ փոխանակում է, երբ դուք ընդամենը ապացույցներ էիք հավաքում։ Այստեղ անհրաժեշտ ոչինչ root չի պահանջում. դրոշների, հասցեների և հաշվիչների ընթերցումը աշխատում է որպես սովորական օգտատեր։

Հաջորդ անգամ, երբ Mac-ի թունելը վատ վարվի, ստուգումները կատարեք հերթականությամբ. հաստատեք, որ utun է հայտնվել ifconfig -l-ով, կարդացեք դրա դրոշները, հասցեները և MTU-ն, վերագրեք այն գործընթացի, հարցրեք route -n get-ին, թե որ ինտերֆեյսն է օգտագործում նպատակակետը, ապա դիտեք, թե ինչպես է netstat -ib-ը շարժվում։ Յուրաքանչյուր քայլ բացառում է տարբեր շերտ, և առաջինը, որ սխալ վերադառնա, այնտեղ է, որտեղ պատկանում է ուղղումը։