د 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، او کلاینټ کولی شي له دې تېر شي۔ د ساحو لیست دومره لنډ دی چې یو ځل پکې وګورئ هغه ifconfig لارښود چې Apple ورسره ورکوي۔

هغه پروسه ومومئ چې د انټرفیس شاته ده

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

ځواب یعنې د هغې اندازې پاکټونه له تونل تېرېږي۔ چوپتیا هغه وخت چې کوچني پینګونه بریالي کېږي، 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 یې پټوي۔ د کلاینټ خپل حالت وګورئ، بیا د سیسټم: یو Network Extension چې هېڅکله نه دی تصویب شوی، یا چې macOS له تازه کولو وروسته بند کړی، هېڅ انټرفیس نه پرېږدي۔ تصویب په System Settings کې د Login Items & Extensions لاندې دی، او هلته زوړ ننوتنه د دې ارزښت لري چې مخکې له هر څه بیا نصبولو یو ځل بیا بدله شي۔

د utun شمېرنه په بیا نښلولو کې ثابته نه ده۔ تاسو کولی شئ utun5 ترلاسه کړئ هلته چې utun4 لس دقیقې مخکې و، ځکه زوړ انټرفیس ړنګېږي او کرنل بل ازاد شاخص ورکوي۔ هغه سکریپټونه چې نوم په کلکه لیکي، په هماغه شېبه کې په خاموشۍ ماتېږي; پرځای یې پتې یا لارې سره سمون وکړئ۔

د لوستلو اړخ یوازې-لوستلو وساتئ۔ sudo ifconfig utun4 down تونل پرې کوي، او په بشپړ-تونل پروفایل کې ستاسو لرې غونډه هم ورسره وړي، چې کله یوازې شواهد غونډوئ بدله معامله ده۔ هغه څه چې دلته یې اړتیا لرئ root نه غواړي: بیرغونه، پتې او شمېرونکي لوستل ستاسو په عادي کارونکي کې کار کوي۔

بل ځل چې Mac تونل بد چلند وکړ، کتنې په ترتیب سره وکړئ: تایید کړئ چې utun راڅرګند شو ifconfig -l سره، د هغه بیرغونه، پتې او MTU ولولئ، هغه یوې پروسې ته وټاکئ، route -n get وپوښتئ چې منزل کوم انټرفیس کاروي، بیا netstat -ib خوځښت وګورئ۔ هر ګام بېل پوړ لرې کوي، او لومړی هغه چې غلط راوګرځي هماغه ځای دی چې سمون پکې اړین دی۔