رابط utun در VPN مک بالا است اما ترافیک عبور نمی‌کند؟ 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، و کلاینت می‌تواند آن را بازنویسی کند. فهرست فیلدها آن‌قدر کوتاه است که یک بار در راهنمای ifconfig که Apple عرضه می‌کند مرور شود.

فرایندی را که پشت رابط است پیدا کنید

ifconfig هیچ مفهومی از برنامه مالک ندارد. دو کلاینت VPN، یک سرویس سیستم و یک تونل باقی‌مانده از هفته گذشته همه ورودی‌هایی می‌سازند که در این سطح یکسان به نظر می‌رسند. روی Mac خودم، utun0 تا utun3 پیش از آنکه چیزی تنظیم کنم وجود داشتند؛ Continuity و iCloud Private Relay هم از تونل استفاده می‌کنند و هیچ‌یک از آن‌ها اتصالی نیست که در حال عیب‌یابی آن هستید.

برای تونل‌هایی که پیکربندی را در سیستم ثبت می‌کنند، scutil --nc list سریع‌ترین تطبیق است. هر پیکربندی را با وضعیت و شناسه سرویسش چاپ می‌کند و متصل با این نشانه مشخص می‌شود:

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 گزارش کند، پیکربندی تونل شکافته شما همان کاری را می‌کند که به آن گفته شده و هیچ بازرسی رابطی آن را تغییر نمی‌دهد. وقتی مسیر پیش‌فرض و کل جدول را در یک نما می‌خواهید از netstat -rn -f inet استفاده کنید.

شمارنده‌ها روشن می‌کنند که بسته‌ها واقعاً حرکت می‌کنند یا نه. netstat -ib مجموع بسته و بایت هر رابط را، با احتساب ورودی‌های utun، گزارش می‌کند؛ اعداد تجمعی‌اند، پس دوبار با فاصله بخوانید و مقایسه کنید:

netstat -ib | grep utun4

شمارنده‌های یخ‌زده در حالی که برنامه مدام تلاش می‌کند یعنی هسته هرگز بسته‌ای به رابط نداد. شمارنده‌هایی که در هر دو جهت بالا می‌روند و برنامه هنوز شکست می‌خورد، بررسی را به انتهای دور تونل منتقل می‌کنند.

وقتی هیچ utun ظاهر نمی‌شود

فهرست خالی رابط‌ها پس از ورودی که موفق به نظر می‌رسید معمولاً یعنی تونل هرگز شروع نشد، نه اینکه ifconfig آن را پنهان می‌کند. ابتدا وضعیت خود کلاینت را بررسی کنید، بعد سیستم را: افزونه شبکه‌ای که هرگز تأیید نشد یا macOS پس از به‌روزرسانی غیرفعالش کرد، هیچ رابطی برجا نمی‌گذارد. تأیید در تنظیمات سیستم زیر Login Items & Extensions است و یک ورودی کهنه آنجا ارزش دارد پیش از نصب دوباره هر چیزی یک بار خاموش و روشن شود.

شماره‌گذاری utun بین اتصال‌های دوباره پایدار نیست. ممکن است جایی که ده دقیقه پیش utun4 بود utun5 بگیرید، چون رابط قدیمی برچیده می‌شود و هسته ایندکس آزاد بعدی را می‌دهد. اسکریپت‌هایی که نام را سخت‌کد می‌کنند در همان لحظه بی‌صدا می‌شکنند؛ بهتر است بر اساس نشانی یا مسیر تطبیق دهید.

سمت خواندن را فقط-خواندنی نگه دارید. sudo ifconfig utun4 down تونل را قطع می‌کند و در پروفایل تونل کامل، نشست دور شما را هم با خود می‌برد، که وقتی فقط مشغول جمع‌آوری شواهد بودید معامله بدی است. هیچ‌یک از چیزهایی که اینجا لازم دارید به root نیاز ندارد: خواندن پرچم‌ها، نشانی‌ها و شمارنده‌ها با کاربر عادی کار می‌کند.

دفعه بعد که تونل Mac بدرفتاری کرد، بررسی‌ها را به ترتیب انجام دهید: با ifconfig -l تأیید کنید utun ظاهر شده، پرچم‌ها، نشانی‌ها و MTU آن را بخوانید، آن را به فرایندی نسبت دهید، از route -n get بپرسید مقصد از کدام رابط استفاده می‌کند، سپس حرکت netstat -ib را تماشا کنید. هر گام لایه‌ای متفاوت را حذف می‌کند و اولین گامی که اشتباه برگردد جای اصلاح است.