Сеть в macOS: настройка и инструменты

[Artem_MacAdmin]

Знакомая боль. Ты подключаешься к новому офису, корпоративному Wi-Fi или VPN, и сеть в mac ведёт себя странно: пинг идёт, а сайты не открываются, или наоборот - DNS резолвит мусор, прокси перехватывает трафик, а в Системных настройках половина нужных полей спрятана за тремя кликами. Кликать мышкой по одному хосту - терпимо. Настраивать так парк из тридцати маков или писать скрипт для MDM - боль. Эта глава о том, как управлять сетью на macOS из терминала по-взрослому: networksetup как универсальный CLI, ifconfig и route для низкого уровня, scutil для DNS, wdutil для Wi-Fi (да, airport умер), и про то, КАК этот стек устроен изнутри, а не только какие кнопки жать.

Сразу важная оговорка про модель. В macOS сетевой стек - это BSD-ядро снизу (отсюда ifconfig, route, netstat - всё в синтаксисе BSD, не GNU) и слой configd сверху, который держит динамический System Configuration store. Когда ты меняешь настройку через networksetup или Системные настройки, ты НЕ правишь напрямую интерфейс - ты пишешь в этот store, а демон configd применяет изменения к ядру. Поэтому ifconfig покажет тебе текущее состояние интерфейса, но менять IP через ifconfig бессмысленно: configd при следующем событии перезатрёт. Запомни это разделение, оно объясняет 90 процентов граблей.

networksetup: один CLI на всю сеть mac

networksetup - это родной инструмент Apple для управления сетевыми службами. Лежит в /usr/sbin/networksetup, работает поверх того самого configd store, поэтому всё, что ты тут настроишь, переживёт перезагрузку и отразится в Системных настройках. Большинство команд на запись требуют sudo.

Первое, что нужно понять - терминология. macOS оперирует не интерфейсами (en0), а сетевыми службами (network services): "Wi-Fi", "Ethernet", "Thunderbolt Bridge". Служба - это именованная обёртка над интерфейсом с набором настроек. Смотрим список:

Код: Выделить всё

$ networksetup -listallnetworkservices
An asterisk (*) denotes that a network service is disabled.
Wi-Fi
USB 10/100/1000 LAN
Thunderbolt Bridge
*iPhone USB

Звёздочка - служба выключена. Чтобы увидеть, какой BSD-интерфейс стоит за какой службой и в каком порядке они опрашиваются (это и есть приоритет маршрута по умолчанию):

Код: Выделить всё

$ networksetup -listnetworkserviceorder
(1) Wi-Fi
(Hardware Port: Wi-Fi, Device: en0)

(2) USB 10/100/1000 LAN
(Hardware Port: USB 10/100/1000 LAN, Device: en7)

Порядок здесь - НЕ косметика. Когда активны и Wi-Fi, и Ethernet, шлюз по умолчанию берётся от службы, которая выше в списке. Это аналог метрики маршрута. Поднять Ethernet над Wi-Fi:

Код: Выделить всё

sudo networksetup -ordernetworkservices "USB 10/100/1000 LAN" "Wi-Fi" "Thunderbolt Bridge"

Имена надо передать ВСЕ и в нужном порядке - команда переустанавливает весь список целиком.

Настройка IPv4. Включить DHCP на службе или прибить статику:

Код: Выделить всё

$ sudo networksetup -setdhcp "Wi-Fi"
$ sudo networksetup -setmanual "USB 10/100/1000 LAN" 192.168.10.50 255.255.255.0 192.168.10.1
$ networksetup -getinfo "Wi-Fi"
DHCP Configuration
IP address: 192.168.10.23
Subnet mask: 255.255.255.0
Router: 192.168.10.1

Аргументы setmanual - адрес, маска, роутер, именно в таком порядке. Никаких CIDR-сокращений, это BSD-мир, маска полная.



DNS в mac: почему resolv.conf врёт и при чём тут scutil

Тут живёт классическая ловушка. Ты открываешь /etc/resolv.conf, видишь там nameserver, правишь его - и ничего не меняется. Причина: на macOS /etc/resolv.conf генерируется автоматически демоном configd и НЕ является источником истины для системного резолвинга. Большинство приложений резолвят через библиотеку, которая ходит в configd, а не читает этот файл. resolv.conf оставлен ради совместимости со старыми BSD-утилитами, и то отражает лишь основной (primary) резолвер.

Настоящая картина DNS на mac - в scutil. Это must-have команда:

Код: Выделить всё

$ scutil --dns
DNS configuration

resolver #1
  nameserver[0] : 192.168.10.1
  nameserver[1] : 1.1.1.1
  if_index : 14 (en0)
  flags    : Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  domain   : corp.local
  nameserver[0] : 10.0.0.53
  flags    : Supplemental, Request A records

Читаем по делу. resolver #1 - дефолтный путь для всех имён. А вот resolver #2 с полем domain - это scoped/supplemental резолвер: имена в зоне corp.local пойдут на 10.0.0.53, всё остальное - на дефолтный. Так macOS реализует split-DNS, и часто именно из-за supplemental-резолвера от VPN-клиента "ломается" разрешение имён - часть запросов внезапно уходит не туда. Если у тебя VPN, и внутренние хосты не резолвятся или резолвятся наружу - первым делом смотри scutil --dns и ищи, кто добавил scoped-резолвер.

Прописать DNS правильно - через networksetup, не через файл:

Код: Выделить всё

$ sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 8.8.8.8
$ networksetup -getdnsservers "Wi-Fi"
1.1.1.1
8.8.8.8

Сбросить DNS обратно на полученные по DHCP - передать спецслово Empty:

Код: Выделить всё

sudo networksetup -setdnsservers "Wi-Fi" Empty

Очистить кэш резолвера после правок (mac кэширует агрессивно):

Код: Выделить всё

$ sudo dscacheutil -flushcache
$ sudo killall -HUP mDNSResponder

Обе команды вместе - сброс кэша DNS на современных macOS. mDNSResponder - тот самый демон, что отвечает и за обычный DNS, и за mDNS/Bonjour.

mDNS, Bonjour и магия .local

Имена вида mac-studio.local разрешаются не через DNS-сервер, а через mDNS - multicast DNS, та самая Bonjour. Когда ты пингуешь сосед.local, mac не идёт на DNS, а рассылает multicast-запрос в локальный сегмент на 224.0.0.251:5353, и хост с этим именем отвечает сам. Поэтому .local работает без всякого DNS-сервера и ломается, как только в сети криво настроен реальный DNS-домен .local (древняя болячка Active Directory). За это снова отвечает mDNSResponder. Грабли: если корпоративный домен называется company.local, unicast-DNS и mDNS дерутся за эту зону, и резолвинг становится непредсказуемым - вот почему .local под AD считается антипаттерном. Проверить, что слышно в сети по Bonjour:

Код: Выделить всё

dns-sd -B _ssh._tcp

- покажет хосты, анонсирующие SSH.

Wi-Fi из терминала: airport мёртв, да здравствует wdutil

Если ты гуглил "wifi mac терминал" пару лет назад, тебе советовали бинарь airport из глубин CoreWLAN.framework. Забудь. Начиная с macOS Sonoma 14.4 Apple официально вывела airport из строя - утилита осталась, но печатает предупреждение и больше не выдаёт данные. На замену - wdutil (Wireless Diagnostics utility). Важная разница: wdutil ТРЕБУЕТ sudo на любую операцию, тогда как airport раньше работал и без рута для базовой инфы. И ещё: с macOS Sequoia в выводе wdutil из соображений приватности MAC-адрес, SSID и BSSID редактируются (показываются как redacted), если ты не дашь полные права.

Сводка по текущему подключению:

Код: Выделить всё

$ sudo wdutil info
NETWORK
    AWDL                 : On
WIFI
    MAC Address          : aa:bb:cc:dd:ee:ff
    SSID                 : CorpWiFi
    BSSID                : 11:22:33:44:55:66
    Channel              : 6g149/160
    RSSI                 : -54 dBm
    Noise                : -92 dBm
    Tx Rate              : 1200 Mbps
    Security             : WPA3 Personal

RSSI минус 54 - сильный сигнал (чем ближе к нулю, тем лучше; хуже минус 75 - уже проблемы). Noise минус 92 - чистый эфир. Channel 6g149 - это 6 ГГц, Wi-Fi 6E. Это и есть та диагностика, за которой раньше ходили в airport -I.

А вот управление Wi-Fi (включить/выключить адаптер, подключиться к сети) живёт в networksetup и работает без проблем:

Код: Выделить всё

$ networksetup -getairportpower en0
Wi-Fi Power (en0): On
$ sudo networksetup -setairportpower en0 off
$ networksetup -getairportnetwork en0
Current Wi-Fi Network: CorpWiFi
$ sudo networksetup -setairportnetwork en0 "GuestWiFi" "пароль_сети"

setairportnetwork добавит сеть в известные и подключится. Пароль в командной строке светится в истории shell - в скриптах для MDM это передают иначе, но руками так быстрее всего. Узнать имя интерфейса (обычно en0, но на маках с Ethernet-портом Wi-Fi может быть en1):

Код: Выделить всё

networksetup -listallhardwareports

Интерфейсы, маршруты, прокси: BSD-низ

ifconfig в mac - чистый BSD, отличается от Linux-овского. Состояние интерфейса:

Код: Выделить всё

$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether aa:bb:cc:dd:ee:ff
    inet 192.168.10.23 netmask 0xffffff00 broadcast 192.168.10.255
    inet6 fe80::1c4d:...%en0 prefixlen 64 secured scopeid 0xe
    status: active

Маска тут в hex (0xffffff00 = /24) - чистая BSD-эстетика. status: active значит линк есть. Помни: править IP через ifconfig бесполезно, configd перезатрёт - это для чтения и отладки.

Таблица маршрутов - через netstat -rn (флаг -r маршруты, -n без резолва имён):

Код: Выделить всё

$ netstat -rn
Routing tables
Internet:
Destination        Gateway            Flags        Netif
default            192.168.10.1       UGScg          en0
192.168.10/24      link#14            UCS            en0

Строка default с шлюзом 192.168.10.1 на en0 - твой маршрут по умолчанию. Если их два (от Wi-Fi и Ethernet) - вот тебе и асимметрия, решается порядком служб (см. выше). Временно добавить маршрут руками - route (тоже BSD-синтаксис):

Код: Выделить всё

sudo route add -net 10.8.0.0/24 192.168.10.254

Такой маршрут не переживёт перезагрузку - для постоянного нужен LaunchDaemon или настройка VPN-профиля.

Прокси. networksetup рулит и им - web (HTTP), secure web (HTTPS), а также авто-прокси через PAC:

Код: Выделить всё

$ sudo networksetup -setwebproxy "Wi-Fi" proxy.corp.local 3128
$ sudo networksetup -setsecurewebproxy "Wi-Fi" proxy.corp.local 3128
$ sudo networksetup -setautoproxyurl "Wi-Fi" "http://wpad.corp.local/wpad.dat"
$ networksetup -getwebproxy "Wi-Fi"
Enabled: Yes
Server: proxy.corp.local
Port: 3128

Выключить прокси, не стирая настройки:

Код: Выделить всё

sudo networksetup -setwebproxystate "Wi-Fi" off

Locations, VLAN/bridge и аварийный сброс

Locations (Размещения) - это именованные наборы ВСЕХ сетевых настроек сразу. Удобно, когда ты таскаешь ноут между домом, офисом и стендом с фиксированными IP. Создать и переключиться:

Код: Выделить всё

$ sudo networksetup -createlocation "Office" populate
$ networksetup -listlocations
Automatic
Office
$ sudo networksetup -switchtolocation "Office"

populate копирует текущие службы в новое размещение (без него получишь пустое). Дальше внутри "Office" правишь IP/DNS/прокси, и одной командой переключаешься между профилями - быстрее, чем перенастраивать руками.

VLAN и bridge тоже создаются через networksetup:

Код: Выделить всё

sudo networksetup -createVLAN "vlan100" en0 100

и

Код: Выделить всё

sudo networksetup -createBridge "br0" en0 en7

. Это редкая задача на десктопе, но на маках в роли мини-серверов или при тестах сети - реальный кейс.

Аварийный сброс сети, когда совсем всё запуталось (дубли служб, мёртвые прокси, сломанный DNS). Народный способ - снести конфигурационные plist и перезагрузиться, чтобы configd собрал всё заново:

Код: Выделить всё

$ sudo rm /Library/Preferences/SystemConfiguration/preferences.plist
$ sudo rm /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist
$ sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
$ sudo reboot

Это удалит ВСЕ сетевые службы, размещения, известные Wi-Fi-сети и вернёт macOS к чистому "Automatic". Перед таким - бэкап папки. Менее радикально: удалить и пересоздать конкретную службу через networksetup -removenetworkservice / -createnetworkservice.

Где это в Системных настройках (System Settings, а не старые Preferences). Все эти штуки живут в Системные настройки -> Сеть: там службы, их детали (кнопка Details для IP/DNS/прокси), а Размещения - в меню троеточия. Wi-Fi-диагностика - в отдельном Wireless Diagnostics (Option-клик по значку Wi-Fi). Но CLI быстрее и скриптуется, поэтому он и нужен профи.

Мини-лаба (повтори руками)

• Выполни networksetup -listnetworkserviceorder и найди, какой en-интерфейс стоит за твоим Wi-Fi.
• Сними текущий DNS: networksetup -getdnsservers "Wi-Fi", запиши. Поставь 1.1.1.1, проверь через scutil --dns, что в resolver #1 появился он. Верни обратно (или Empty).
• Запусти sudo wdutil info и найди RSSI и Channel своего подключения. Оцени уровень сигнала.
• Глянь netstat -rn, найди строку default - запиши свой шлюз. Сравни с networksetup -getinfo "Wi-Fi".
• Сделай dns-sd -B _airplay._tcp на пару секунд (Ctrl-C) - увидишь устройства AirPlay по Bonjour в твоей сети.

Контрольные вопросы

• Почему правка /etc/resolv.conf не меняет реальный DNS на macOS и какой командой смотреть истинную DNS-конфигурацию?
• Чем supplemental (scoped) резолвер в выводе scutil --dns отличается от resolver #1 и как это связано с поломками DNS под VPN?
• Какой утилитой Apple заменила airport начиная с Sonoma 14.4 и в чём её ключевое отличие по правам и приватности?
• Как из терминала поднять Ethernet выше Wi-Fi по приоритету маршрута по умолчанию, не трогая мышку?

Итог

Сеть в macOS - это BSD-низ (ifconfig, route, netstat для чтения и отладки) плюс слой configd, которым ты управляешь через networksetup: службы, IP, DNS, прокси, Wi-Fi-питание, размещения, VLAN и bridge. DNS смотри только через scutil --dns, помня про supplemental-резолверы и то, что resolv.conf - устаревший артефакт. Имена .local - это mDNS/Bonjour через mDNSResponder, а не DNS-сервер. Wi-Fi-диагностику бери в wdutil (airport мёртв с 14.4, и всё под sudo). Освоив этот набор, ты настроишь сеть на одном маке за минуту и заскриптуешь её на сотне.

[legacydruid]

Блин, я полдня правил resolv.conf и не понимал почему dns не меняется. scutil --dns все объяснил, спасибо. supplemental-резолвер от корпоративного впн как раз и ломал мне внутренние хосты

[PythonAddict]

А есть способ подключиться к скрытой wifi сети через networksetup, где ssid не вещается? setairportnetwork ругается что сеть не найдена