Настройки VPN на Mac не запускают сервер: где живёт шлюз

В macOS под именем VPN скрываются две разные задачи, а панель настроек занимается только одной из них. Если вы хотите, чтобы трафик этого Mac выходил через провайдера или удалённый шлюз, достаточно записи клиента. Если вы хотите из гостиничного номера добраться до принтера, NAS или страницы администрирования в домашней сети, что-то в этой сети должно принимать подключения извне, а нынешний Mac по умолчанию не является этим чем-то. Три вопроса определяют, какой у вас случай, и на них стоит ответить до того, как вводить адрес в поле.

Запись клиента называет пункт назначения, а не слушателя

В разделе «Системные настройки > Сеть > VPN» на macOS Ventura и новее поля, которые старые версии держат в настройках сети, описывают, как добраться до чужой конечной точки: адрес сервера, удалённый ID, учётная запись или сертификат и необязательные правила подключения по требованию. Сохранение такой записи сохраняет подключение в сетевой конфигурации вашего Mac. Ничто в этом процессе не привязывает порт, не открывает слушателя и не регистрирует удалённого пользователя.

Это можно проверить из оболочки. На Mac, который вы подозреваете в обслуживании, выполните sudo lsof -nP -iUDP и поищите порты, которые использует ваш протокол: 500 и 4500 для IKEv2, 1194 для стандартного OpenVPN, 51820 для WireGuard. Машина, которая является только клиентом, показывает сокеты, связанные с удалённым адресом и портом, а не подстановочную привязку, до которой дотянулся бы кто угодно в интернете. Туннели, работающие внутри Network Extension, могут скрываться от lsof, поэтому в любом случае проверьте и панель состояния приложения; чего вы не найдёте, так это настройки Apple, превращающей этот Mac в шлюз.

Три вопроса разделяют две роли

Пройдите их по порядку. Первый обычно решает остальное, а третий — то место, где чаще всего ошибается планирование, специфичное для Mac.

1. Кто начинает разговор? Если ваш Mac звонит наружу и другая сторона отвечает, нужен клиент. Если устройства в интернете должны звонить внутрь, чтобы добраться до вашей сети, нужен шлюз с публичной точкой входа, а Mac может остаться клиентом этого шлюза.

2. Что должно быть доступно, пока туннель поднят? Одна служба на одном хосте — это решение о пробросе портов. Целая подсеть, включая разрешение имён, — это решение о маршрутизации и DNS, и оно меняет то, что шлюз должен передавать, а не то, что говорит запись клиента.

3. Какая версия ОС работает на принимающей стороне? Для Mac у этого вопроса жёсткий ответ. Apple указывает VPN как удалённый из macOS Server 5.7.1, а само приложение macOS Server было прекращено 21 апреля 2022 года; уведомление об истории службы — это страница, которую стоит прочитать, когда старый учебник ведёт вас через флажок службы VPN, которой больше нет.

Когда первый ответ — «начинает кто-то снаружи», перестаньте искать переключатель в клиентской панели Mac и выберите хост, который завершит туннель.

Где вместо этого может жить шлюз

Четыре варианта покрывают большинство домашних и малых офисных случаев. Маршрутизатор с настоящим режимом сервера, в отличие от клиентского режима с другой надписью, завершает туннель на краю и держит число хостов низким, ценой привязки к поддержке протоколов той прошивки. NAS или постоянно включённый мини-ПК запускает серверный пакет производителя и оставляет читаемые журналы. Небольшая облачная ВМ даёт вам публичный адрес, которым вы управляете, и добирается до дома через второй туннель. Mesh-оверлей на WireGuard или управляемый сервис, передающий между узлами, обходит входящий проброс портов, заставляя оба конца звонить наружу.

Граница между этими вариантами — обычно ваше интернет-соединение, а не программа. Если провайдер помещает вас за NAT операторского уровня, никакой проброс портов на маршрутизаторе не даст достижимой точки входа, и честный ответ — схема с ретранслятором или mesh. Сравните WAN-адрес, который сообщает маршрутизатор, с адресом, который видит внешний мир; если они различаются и значение маршрутизатора лежит в частном или общем диапазоне, планируйте случай с ретранслятором.

Какой бы хост вы ни выбрали, пробрасывайте один протокол на одном порту, а не диапазон, и держите Mac вне входящего пути, если только этот конкретный продукт не документирует серверную роль для той версии macOS, которую вы запускаете.

Подтвердите роль, прежде чем раздавать профили

На кандидате в шлюзы докажите, что слушатель существует, вместо того чтобы полагаться на установщик. На macOS это означает sudo lsof -nP -iUDP с фильтром по портам выше, плюс sudo pfctl -s nat, если правила фильтра пакетов входят в замысел. В Linux ss -lunp показывает те же факты без двусмысленности.

Затем проверьте извне сети, используя сам протокол. Ping доказывает мало: ICMP часто фильтруют, и он ничего не говорит об UDP 51820. Клиентское рукопожатие с подробным журналом, запущенное с телефона на мобильных данных, — самая дешёвая настоящая проверка, потому что оно проходит тем же путём, которым пойдёт удалённый коллега.

Только после этого трогайте клиентские профили. На Mac scutil --nc list печатает VPN-службы, известные системе; если только что построенного шлюза среди них нет, вы настраиваете другую машину, не ту, которую проверяли. Если рукопожатие удаётся в LAN, но не снаружи, неисправность во входящем пути: правило NAT, CGNAT провайдера или брандмауэр на шлюзе, именно в этом порядке.

Прежде чем что-либо строить, решите четыре пункта:

• Какая сторона инициирует соединение, ваш Mac или удалённое устройство.
• Действительно ли версия ОС и продукт принимающего хоста поддерживают серверную роль.
• Даёт ли провайдер вообще достижимый публичный адрес.
• Какой единственный порт и протокол примет шлюз и какая служба за ним отвечает.

Следующий шаг конкретен: выберите хост-шлюз, подтвердите его слушателя снаружи и только затем создайте на Mac клиентскую запись, указывающую на него.