Інтерфейс utun у VPN на Mac активний, але трафік не йде? Перевірте ifconfig

ifconfig показує ім'я utun, адресу та MTU, але не те, який застосунок ним володіє або куди йдуть пакети. П'ять перевірок лише для читання, що відповідають на справжнє питання.

Ви підключили 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 — найшвидша кореляція, вона друкує кожну конфігурацію зі статусом і 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 його ховає. Перевірте стан самого клієнта, потім системи: 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 рухається. Кожен крок виключає свій шар, і перший, що повернувся неправильно, і є місцем виправлення.

Схожі статті