Интерфейс 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 движется. Каждый шаг исключает свой слой, и первый, что вернулся неверным, и есть место исправления.

Похожие статьи