Налаштування 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 клієнтський запис, що вказує на нього.