WINDOWS + MACBOOK: РАБОЧЕЕ МЕСТО, СЕРВЕР И ДВА VPN

Как мы с GPT совместили локальную сеть, отдельные учётки, обмен файлами и Kill Switch — и что пошло не по плану. 10 ноября 2026 года.

Всем привет! Товарищ отдал мне свой старый MacBook Pro. Он грелся, я его продул, привёл в порядок — и задумался: а что теперь с ним делать? У меня уже есть привычный Windows-компьютер, на котором я работаю и рисую. К Mac я пока только привыкаю. Выбрасывать такую машину из рабочего процесса жалко, но и превращать её в дорогую подставку для чашки не хотелось.

Сначала вариантов было два: сделать из Mac отдельное рабочее место — например, для сына или товарища, со своей учёткой и Google, Chat GpT, Claude возможно, — либо отдать его под вычисления, скрипты и задачи, чтобы лишний раз не нагружать основной Windows. А потом пришла мысль: почему обязательно выбирать сейчас? Можно совместить оба сценария. Днём на Mac кто-то работает под своей учёткой, а когда он свободен, я использую его как вспомогательный компьютер для своих задач.

Сразу ПРЕДУПРЕЖДАЮ — я не утверждаю, что это единственный и самый правильный способ. Это просто мой с ИИ вариант домашней настройки, с ОШИБКАМИ и неожиданными находками. Вдруг кому-то пригодится.

Что хотел получить:

Windows остаётся главным рабочим местом. Mac — запасным рабочий и потенциальным сервачком-узлом (Видеокарта на маке слабовата, Blender версия ниже против винды) да и давно на маке не работал. Оба компьютера чтобы в одной домашней сети были, видят нужные общие файлы и при этом используют каждый свой VPN безопасно. На маке чтобы скрипты считались, тесты там от своей аналитической разработки… и не мешались и чтобы на обоих операционках тестились. Хотелось оставить Kill Switch включённым, а не чинить локальную сеть за счёт отключения защиты.

Мои  машино- морды:

Подготовка: всё не так страшно

С обычной подготовкой Mac особой драмы не было. GPT вёл меня по инструкции точно. После восстановления системы через Recovery создал отдельную учётную запись "Shmut", настроил сеть. Установщик и архив, как там её… не помню…  A…zia VPN передавали с Windows на Mac по локальной сети. Для доступа проверяли SSH, а общую папку настроили через SMB. На Mac появилась папка Shared_Work, доступная с моего Windows.

Отдельные учётки нужны прежде всего для удобства и разделения файлов и настроек пользователей. Но не стоит путать их с полной изоляцией: VPN, сетевые службы и нагрузка на процессор могут влиять на весь компьютер. Этот сценарий одновременного использования мне ещё предстоит испытать.

А вот с двумя VPN начались трудности:

Пока VPN были выключены, компьютеры общались без проблем: Windows получал ответы Mac, а проверки TCP-портов SSH (22) и SMB (445) проходили. Через папку Shared_Work удалось перенести установщик и конфигурацию A…ezia.

Потом мы включили VPN на обоих устройствах — и Windows перестал видеть не только Mac, но даже домашний роутер. Ping отвечал «Общий сбой», проверка порта 445 показывала False. Переключение VPN на Mac не помогло. Мы успели проверить маршруты, ARP и подключения через PowerShell. С железом всё выглядело нормально.

Подозреваемый — Kill Switch

В A…ziaVPN 5.1.0.6 на Windows был включён Soft Kill Switch. Отключили его, не выключая сам VPN, — и локалка ожила: роутер ответил на четыре запроса из четырёх, порт 445 снова стал доступен. Но оставлять Kill Switch выключенным не хотелось: при обрыве VPN трафик потенциально мог уйти через обычное подключение. А — это прям нежелательно для меня!)

Заодно заметили показательную деталь. Когда связь не работала, Test-NetConnection выбирал интерфейс A…ziaVPN с адресом 100.106.135.47. Когда работала — обычный Ethernet 192.168.1.64. Значит, проблема была на стороне маршрутизации или фильтрации Windows VPN, а не в Wi-Fi Mac или проводе Windows.

Решение: локальная сеть отдельно, интернет — через VPN

На Windows настроили раздельное туннелирование в режиме «Напрямую», добавив исключение 192.168.1.0/24 для локальной сети. После этого снова включили VLESS и Kill Switch. Mac в это время работал через A…ziaWG со своим Kill Switch.

Контрольная проверка Test-NetConnection 192.168.1.67 -Port 445 показала InterfaceAlias: Ethernet, SourceAddress: 192.168.1.64 и TcpTestSucceeded: True. А главное — в Проводнике Windows открылась папка \192.168.1.67\Shared_Work и стали видны файлы с Mac. То есть заработал реальный доступ к папке, не только проверка порта. Маленькая победа! Уррра!

Продолжение приключений: появляется «Сервачок»

С VPN вроде разобрались. Файлы передаются, компьютеры друг друга видят. Можно было на этом закончить и спокойно жить дальше. Но какой тогда жопыт? Тем более Mac-то я изначально хотел приспособить под двух хозяев, да и потренироваться на нём было интересно.

Днём за ним может сидеть сын, заниматься своими делами, а вечером и ночью я хочу использовать Mac для своих скриптов, тестов и прочих вычислительных экспериментов. Причём иногда нам придётся работать одновременно. (Ну это теоретически просто для возможности, может и гамать просто будем… )

Поэтому решил создать отдельного пользователя macOS. Сын остаётся со своей учёткой администратора, а под мои задачи создаём стандартного пользователя с гордым именем «Сервачок». Зашёл без Apple Account — пока не понадобится. Настроил удалённый вход по SSH, разрешил подключение для нового пользователя и создал собственную папку Serverok.

Вроде всё просто. Но, тогда и писать вроде не о чем.

Новая папка есть, а попасть в неё нельзя

Старая общая папка Shared_Work с Windows открывалась прекрасно. А вот новая Serverok — никак.

Проверяю порт 445 — доступен. Значит, компьютер на связи и SMB отвечает. Но при попытке открыть папку Windows то показывает пустоту, то отказывается создавать файлы, то вообще ничего толкового не сообщает.

Мы с GPT перепроверяли права, настройки общего доступа, SMB и пароли. Запутался с именами тоже  servacok и serverok пару раз тупанул.

Пытался подключиться из Windows через PowerShell:

net use \\192.168.1.67\Serverok /user:servacok *

Звёздочка в конце означает, что пароль запрашивается отдельно. При вводе символы не отображаются — это нормально, хотя поначалу кажется, что компьютер просто игнорирует клавиатуру. Но и это не помогло.

Windows помнит старого хозяина

Потом обнаружил ещё одну интересную вещь. В диспетчере учётных данных Windows сохранился пользователь сына — Shmut, через которого мы раньше подключались к Mac.

А теперь пытались зайти на тот же компьютер уже под servacok.

Windows обычно не любит одновременные SMB-подключения к одному серверу с разными учётными данными. Мы попробовали заменить сохранённые данные, но новую папку так и не открыли.

Точную причину не установили. Возможно, дело было в сочетании сохранённых подключений, авторизации и прав доступа.

И тут я подумал: а зачем нам вообще продолжать мучить SMB, если задача — не просто смотреть файлы, а удалённо управлять Mac?

Нашли другой вход — SSH

Решили попробовать подключиться напрямую к учётке Сервачка. Открыл PowerShell на Windows: ssh servacok@192.168.1.67

Подтверждаем ключ компьютера при первом подключении, вводим пароль...И получаю приглашение командной строки Mac:

servacok@MacBook-Pro-Shmut ~ %

Работает!

Теперь я могу со своего Windows зайти непосредственно в отдельную учётную запись MacBook. Причём оба VPN продолжают работать, а папки сына мне для этого не нужны.

Но как передавать файлы?

SFTP — оказывается, можно и без общей папки

Выходим из SSH командой exit и подключаемся другим способом:

sftp servacok@192.168.1.67

Получаем:

Connected to 192.168.1.67.

sftp>

Проверяем, можно ли создавать каталоги:

mkdir transfer_test

ls

Папка появилась! Значит, записывать файлы на Mac уже можем. Теперь проверим не на пустых папках, а на чём-нибудь настоящем. Взял PNG-изображение размером около 30 МБ из загрузок Windows и отправили на Mac командой put.

Результат порадовал: 100% передачи, скорость около 56,1 МБ/с.

Файл успешно появился в: /Users/servacok/transfer_test/

Затем переместили тестовый каталог в нашу специально созданную папку: /Users/servacok/Serverok/transfer_test/

Проверил — всё на месте.

Вот теперь можно действительно сказать: Windows умеет передавать файлы отдельному пользователю Mac, а SSH позволяет удалённо заходить в его систему.

И всё это без необходимости добивать вторую SMB-папку.

Что получилось на этом этапе

• Оба VPN работают одновременно.

• Kill Switch включён в проверенной конфигурации.

• Общая папка Shared_Work доступна по SMB.

• Отдельный пользователь servacok создан.

• SSH-подключение из Windows работает.

• SFTP позволяет создавать папки и передавать файлы.

• Тестовый файл около 30 МБ успешно передан.

• SMB-доступ к Serverok так и не заработал, но для наших задач он уже не обязателен.

Получается, что мы начинали с обычной локальной папки, потом воевали с VPN, затем с пользователями и SMB, а в итоге пришли к SSH и SFTP.

Теперь осталось главное — научить Сервачка принимать задания с Windows, запускать Python, Blender и возвращать результаты.