Рабочий и гостевой Wi-Fi через разные выходы: схема с одним VPS

В небольшом офисе одна и та же радиосеть обслуживает двух очень разных людей. Первый пришёл на переговоры, ему нужно открыть почту, новости и мессенджер, и он ничего не должен знать о вашей внутренней CRM. Второй сидит за рабочим столом: ему нужны внутренние сервисы, админка, файловое хранилище и, возможно, определённый внешний адрес, с которого вас видят партнёры. Если оба подключены к одному и тому же Wi-Fi, вы получаете не сеть, а общую кухню, где у всех есть доступ к холодильнику.

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

Два вопроса, которые звучат как один

Фраза «пусть гости ходят через провайдера, а сотрудники через VPS» описывает выход: куда уходит пакет, когда он покидает офис. Фраза «гости не должны видеть рабочие ресурсы» описывает права: что пакету вообще разрешено делать внутри сети. Это разные механизмы, и один не заменяет другой.

Выбор выхода — это маршрутизация. Роутер смотрит на пакет и решает, в какое подключение его отправить: в основной канал провайдера или в туннель до VPS. Права — это работа фильтрации: пакет можно отбросить, не дав ему дойти ни до внутреннего сервера, ни до самого роутера. Можно красиво отправить гостей другим путём и при этом оставить им открытой дорогу к CRM. Можно, наоборот, надёжно закрыть CRM, но пустить всех через один и тот же выход. Нужны оба решения, и принимать их нужно по отдельности.

Ровно поэтому два имени сети (два SSID) сами по себе ничего не защищают. Название — это этикетка на двери. Защита появляется, когда за этикеткой стоит отдельный сегмент с собственными правилами. В документации Keenetic о гостевой сети сказано, что гостевой сегмент отделён от домашних ресурсов, а доступ к службам самого роутера и изоляция клиентов друг от друга настраиваются отдельно (Keenetic: гостевая сеть). Из этого стоит вынести практический вывод: «гостевая сеть» — это набор нескольких независимых свойств, и каждое из них нужно осознанно проверить, а не считать включённым по умолчанию.

Сначала сегменты: кто где живёт

Прежде чем думать о VPS, нарисуйте на бумаге два прямоугольника. В первом живут рабочие устройства: ноутбуки, телефоны сотрудников, принтер, может быть, NAS. Во втором — всё, что принадлежит приходящим людям. Между ними нет стрелки. Стрелки есть только от каждого прямоугольника наружу, к интернету, и от рабочего прямоугольника к внутренним сервисам.

Теперь нужно уточнить, что именно вы называете внутренними сервисами. Их три вида, и у каждого свои пути:

• устройства и серверы в рабочем сегменте офиса, например принтер или локальный файловый сервер;
• служебные страницы самого роутера, куда гостю заходить незачем;
• сервисы, которые стоят не в офисе, а на VPS или у внешнего хостинга и доступны только через рабочий выход, — например, внутренняя CRM, закрытая по IP.

Третий пункт часто забывают. Если CRM пускает только с адреса вашего VPS, то гостю до неё не добраться по определению, пока он идёт через провайдера. Но это не изоляция, а побочный эффект выбора выхода. Стоит кому-то изменить привязку гостей, и защита пропадёт без единого предупреждения. Поэтому разумно закрывать CRM ещё и собственной авторизацией, а не только фильтром по адресу.

Гостевой пакет: два путешествия

Проследим путь одного пакета от телефона гостя. Допустим, гость открывает обычный внешний сайт. Телефон получает адрес из гостевого диапазона, отправляет запрос на роутер, роутер видит, что пакет идёт вне локальных диапазонов, и отправляет его в канал провайдера. Сайт видит публичный адрес офиса, а ответ возвращается тем же путём. Ничего необычного, и именно это нам и нужно: гостевому трафику не нужен ни туннель, ни VPS, он не должен занимать вашу полосу до сервера и не должен расходовать его ресурсы.

Второе путешествие. Гость вводит в браузере адрес внутренней CRM. Здесь возможны три сценария, и интересно посмотреть, чем они различаются.

1. CRM в локальной сети офиса. Пакет адресован частному адресу из рабочего диапазона. Если правила между сегментами не запрещают, роутер просто доставит его. Выход тут вообще ни при чём: пакет не выходит в интернет. Спасает только фильтрация между сегментами.
2. CRM на VPS, закрытая по адресу. Пакет уходит через провайдера, сервер видит чужой адрес и отказывает. Защита работает, но держится на выборе выхода и на списке разрешённых адресов на сервере.
3. CRM на VPS, доступная любому из интернета. Гость заходит так же, как и любой человек во внешнем мире. От этого защищает только вход по логину и паролю. Разделение Wi-Fi тут ничего не решает.

Эти три сценария показывают, почему вопрос «куда пойдёт пакет» нельзя подменять вопросом «пустят ли его». В первом случае ответ даёт фильтр между сегментами. Во втором — два фактора вместе. В третьем — только аутентификация приложения.

Рабочий сегмент: политика, которая ведёт через VPS

Теперь посмотрим на второй прямоугольник. Рабочим устройствам нужно, чтобы внешний трафик шёл через сервер, который вы арендуете. Причины могут быть разные: внешний адрес с постоянным значением для списков доступа партнёров, единая точка выхода для всех сотрудников, доступ к ресурсам, закрытым по адресу VPS. Это ваш выбор, и он ничем не хуже и не лучше выхода через провайдера, пока вы понимаете, зачем он вам.

На роутерах Keenetic такая задача выражается через политики подключений. По документации, политика состоит из выбранных подключений и их приоритетов, и к ней можно привязать зарегистрированное устройство или сегмент (Keenetic: политики подключений). Там же отмечено важное свойство: незарегистрированные устройства основных сегментов по умолчанию используют политику по умолчанию. Из этого следуют два практических вывода.

Во-первых, если вы хотите, чтобы весь рабочий сегмент шёл через туннель, привязывайте к политике именно сегмент. Привязка отдельных устройств хороша для исключений, но любой новый ноутбук, который не зарегистрирован, уйдёт по общему выходу, и вы заметите это не сразу.

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

Что делает AllowedIPs в туннеле до VPS

Если туннель построен на WireGuard, ключевой параметр маршрутизации называется AllowedIPs. В справочнике wg(8) он описан так: это список адресов, с которых peer может присылать трафик, и одновременно список направлений, которые будут отправляться этому peer (WireGuard wg(8)). Там же уточнено, что IPv4 и IPv6 перечисляются отдельно.

Практический смысл такой. Если вы хотите отправлять через VPS весь внешний трафик рабочего сегмента, в AllowedIPs для сервера на стороне клиента указывают диапазон «всё». Если нужно отправлять через сервер только отдельные сети, например адрес внутренней CRM, перечисляют только их, а остальное идёт напрямую. Это два разных рабочих варианта:

• Весь внешний трафик через VPS. Единый внешний адрес для сотрудников, но весь поток зависит от канала до сервера и от его ресурсов.
• Только внутренние сервисы через VPS. Обычный интернет идёт напрямую и не зависит от туннеля, а закрытые сервисы доступны через сервер.

Отдельная ловушка — раздельный учёт семейств адресов. Если вы указали «всё» только для IPv4, а у устройств есть работающий IPv6, то часть запросов может пойти мимо туннеля прямо через провайдера. Это нужно проверять отдельным запросом, а не предполагать.

Ресурсы VPS под такую схему подбирают от скромных. Туннельный сервер для небольшой команды — не тяжёлая нагрузка, и тарифы вроде Ba с 1 vCPU и 2 ГБ RAM или Uab с 2 vCPU и 4 ГБ можно использовать как отправную точку для теста, но не как обещание ёмкости: решать будет реальный трафик ваших сотрудников. VPS MAATRIX даёт root-доступ, NVMe и процессоры AMD EPYC, а локации в публичном предложении — UK, US, RU и FR (страница аренды VPS). Страну выхода стоит выбирать по задаче: например, где расположены сервисы, к которым нужен короткий путь, и какой адрес ожидают ваши партнёры.

DNS: куда сотрудник спрашивает дорогу

Маршрут пакета определяется только после того, как у клиента есть адрес назначения. А адрес он узнаёт из DNS. Если гостевые и рабочие устройства спрашивают один и тот же резолвер, а резолвер знает внутренние имена, то гость может узнать, что у вас есть crm.company.example и какой у неё адрес. Доступа это не даёт, но выдаёт структуру. Поэтому внутренние имена разумно хранить в резолвере, который отвечает только рабочему сегменту.

Вторая проблема — несовпадение выхода и DNS. Рабочий трафик идёт через VPS, а запросы имён уходят к провайдерскому резолверу. Результат: провайдер видит список всех сайтов, которые посещают сотрудники, хотя сами соединения идут через сервер. Кроме того, ответы могут зависеть от региона резолвера, и сайт, показывающий разное содержимое по странам, отдаст адрес, неудобный для выхода через другую страну. Для рабочего сегмента честнее настроить так, чтобы DNS-запросы тоже шли по туннелю или к заранее выбранному резолверу, а для гостевого оставить обычный путь через провайдера.

Проверка здесь простая и не требует догадок. С рабочего устройства откройте любой сервис, показывающий внешний адрес, и посмотрите, чей он, затем отдельно проверьте, какой резолвер отвечает. Если адрес принадлежит VPS, а резолвер провайдерский, значит, маршрут и DNS настроены по-разному, и это нужно осознанно либо принять, либо исправить.

Что происходит, когда туннель пропал

Туннели падают. Сервер перезагружают, ломается канал, истекает ключ, провайдер перестраивает маршруты. Нужно решить заранее, что должно происходить с рабочим сегментом в этот момент. Вариантов два, и оба имеют цену.

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

Заметьте, что у гостевого сегмента такой проблемы нет. У него вообще нет туннеля, поэтому потеря туннеля его не касается. Это ещё одно преимущество разных выходов: сбой рабочей схемы не превращается в сбой для всех.

Передать настройку коллеге: что на стороне сервера

У туннеля есть вторая половина — сервер, и именно её обычно забывают описать. В WireGuard каждый peer идентифицируется открытым ключом. Когда сотрудник уходит или устройство теряется, нужно убрать конкретный peer, и справочник wg(8) показывает, что это делается командой вида wg set ... peer ... remove. Важно помнить различие, которое там же подчёркнуто: изменение работающего интерфейса и изменение конфигурационного файла — разные действия. Убрали peer на живом интерфейсе, но не поправили файл — после перезапуска старый ключ вернётся. Для применения изменений из файла без пересоздания всех peer предусмотрена команда syncconf.

Ещё одна деталь, важная при передаче дел. Вывод wg showconf и машинный дамп могут содержать секреты, поэтому не вставляйте их в тикет, чат или wiki целиком. Endpoint peer обновляется по корректно аутентифицированным пакетам, то есть смена адреса клиента, например при переезде роутера на другой канал, не требует ручной правки сервера. Но это же значит, что в описании для коллеги не нужно прописывать адрес клиента как постоянный.

Если вам нужно, чтобы одна машина обслуживала не только туннель, но и внутренние сервисы, например файловое хранилище Nextcloud или автоматизации n8n, в каталоге MAATRIX они предложены с установкой, но точное состояние наличия и операционной системы проверяется в форме заказа. Подробности по размещению гостевых сервисов на одном сервере разобраны в статье про хостел, шахматку мест и гостевой Wi-Fi.

Проверка со стороны гостя

Самый честный способ узнать, получилась ли изоляция, — посмотреть на сеть глазами гостя. Подключитесь к гостевому Wi-Fi личным телефоном, не рабочим, и пройдите по списку вопросов. Вы не ищете красивого результата, вы ищете места, где разделение держится только на предположении.

1. Какой внешний адрес виден? Откройте сервис определения адреса. Он должен принадлежать провайдеру, а не VPS. Если видите адрес сервера, гостевой сегмент попал в рабочую политику.
2. Откроется ли внутренняя CRM? Попробуйте и по имени, и по адресу. Для локальной системы ответом должен быть отказ или отсутствие ответа, для системы на VPS — отказ приложения или сервера.
3. Видны ли рабочие устройства? Попробуйте обратиться к принтеру или NAS по их адресам из рабочего диапазона. Тут решает фильтрация между сегментами, а не выбор выхода.
4. Доступна ли страница управления роутером? Как отмечено в документации Keenetic, доступ к службам самого роутера настраивается отдельно от остальной изоляции, так что эту проверку нельзя считать выполненной по умолчанию.
5. Видят ли гости друг друга? Изоляция клиентов тоже отдельная настройка. Для гостиной сети с чужими людьми это обычно желаемое поведение, но проверить его нужно с двух устройств.
6. Что отвечает DNS на внутренние имена? Запрос внутреннего имени из гостевого сегмента не должен возвращать рабочий адрес.

Затем повторите ту же процедуру с рабочего устройства, но с обратным ожиданием: внешний адрес должен принадлежать VPS, CRM открывается, принтер доступен, внутренние имена разрешаются. И наконец, остановите туннель и посмотрите, что произошло именно с тем вариантом, который вы выбрали в разделе про потерю связи. Эти шесть и три проверки полезно записать в документ: через полгода их будет гораздо проще повторить по списку, чем вспоминать, что именно вы тогда щёлкали.

Гость, которому всё доступно, кроме лишнего

Вернёмся к человеку с переговоров. Он сидит в переговорной с телефоном, открывает почту, смотрит новости и отвечает в мессенджере. Всё работает, и ему не приходит в голову, что в двух метрах от него за стеной стоит рабочая сеть, и что его пакеты идут к интернету по другой дороге, чем пакеты сотрудников. Он набирает адрес вашей CRM из любопытства или по ошибке и видит отказ. Не потому, что другой выход «спрятал» её, а потому, что сегмент отделён, роутер не пускает его к рабочим устройствам, а сама система не открывается без входа.

Это и есть результат, к которому вы шли: интернет у гостя есть, а рабочих ресурсов у него нет. И обеспечили вы это тремя независимыми слоями: отдельным сегментом, правильным выбором выхода для каждой группы и проверкой, сделанной с его телефона.