Как разделить DISCO, ICMP, TSMP, Peer API и прикладной TCP после пробуждения macOS, не меняя ACL, MTU, VPN-профиль и Network Extension.
Не приравнивайте один ping ко всей связи
Официальная документация Tailscale разделяет несколько уровней проверки. Обычный `ping` использует ICMP через сетевой стек ОС; `tailscale ping` проверяет связь процессов Tailscale и показывает direct или relayed path; `tailscale ping --tsmp` проходит через WireGuard, но обходит сетевой стек хоста; `--peerapi` проверяет HTTP Peer API. Прикладной TCP-сервис добавляет ещё один уровень. Поэтому ответ DISCO, ICMP или TSMP не гарантирует, что Screen Sharing, SSH или другой TCP-сервис тоже доступен. Запишите каждый результат отдельно и не делайте вывод «туннель полностью исправен» по одной зелёной строке.
Снимите матрицу на одном известном узле
Используйте один собственный peer и один заранее известный TCP-сервис, доступ к которому разрешён владельцем tailnet. В строках матрицы укажите обычный ping, `tailscale ping`, `--icmp`, `--tsmp`, `--peerapi` и подключение к конкретному приложению. Не перебирайте порты и не сканируйте чужие узлы. Если проблема уже возникла после пробуждения, снимите матрицу один раз; не отправляйте ноутбук в повторные циклы сна, особенно если через него идёт удалённая работа. Сравнивайте с последним известным рабочим состоянием до сна, сохраняя тот же peer, сервис и сеть.
Отделите тип пути от TCP-состояния
Tailscale объясняет, что обычный `tailscale ping` может сначала идти через DERP, затем показать peer relay или direct. Переход на direct говорит о выбранном пути между процессами Tailscale, но не подтверждает прохождение прикладного TCP через сетевой стек macOS. Если direct уже появился, а Peer API и приложение продолжают ждать, зафиксируйте расхождение и не меняйте ACL, DNS или relay policy. Если не проходит даже TSMP, симптом шире и эта статья больше не описывает его точно. Если не работает только один сервис, сначала проверьте его состояние на peer, а не Network Extension клиента.
Читайте ENOSPC только как наблюдаемый код
В свежем публичном issue рядом с разрывом TCP повторялась строка `write /dev/tun: no space left on device`, хотя автор отдельно сообщил о свободном месте на диске. Один случай не позволяет объявить ENOSPC нехваткой файлового хранилища, переполнением очереди или доказанным дефектом Network Extension. Официальная справка Tailscale рекомендует на macOS искать сообщения GUI-сборки в Console по Tailscale или IPNExtension. Сохраните точное время и одну очищенную строку, но не публикуйте полный Console export: он может содержать имена устройств, адреса и другую информацию окружения.
Не ломайте рабочую конфигурацию ради восстановления
Не удаляйте VPN configuration, не переустанавливайте Tailscale, не завершайте Network Extension принудительно и не меняйте MTU, ACL, DNS и маршруты одновременно. Документация действительно упоминает MTU как отдельную причину некоторых TCP-проблем, но без контроля размера пакетов это другая ветка, а не объяснение сбоя именно после wake. Если устройство критично, используйте уже имеющийся резервный путь связи и отложите воспроизведение. Критерий остановки — одна матрица после фактического сбоя, одна очищенная строка с кодом и версия клиента; дальнейшее вмешательство выполняется только по официальной инструкции поддержки.
Передайте bugreport вместо приватного лога
Команда `tailscale bugreport`, согласно официальной CLI-справке, ставит в диагностических журналах случайный идентификатор, который можно передать команде Tailscale; сам идентификатор не используется, пока пользователь его не сообщит. Запустите её на затронутом Mac во время уже наблюдаемого состояния и сохраните ID. В отчёт добавьте версию macOS и Tailscale, вариант установки, время sleep/wake, пять результатов матрицы и тип пути. Не прикладывайте auth key, tailnet name, внутренние hostname, IP, ACL, полный Console log и сведения о личных сервисах.
Материал подготовлен редакцией VOne с применением ИИ для построения матрицы уровней связи; факты проверены по официальной документации Tailscale, а issue использован только как обезличенный сигнал.
Источники и проверка
- Tailscale Docs: Tailscale ping message types проверено 2026-08-14
- Tailscale Docs: Troubleshoot TCP connection issues проверено 2026-08-14
- Tailscale Docs: CLI reference проверено 2026-08-14
- Tailscale Docs: tailscaled daemon logs проверено 2026-08-14
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.