Защищённый удалённый доступ к корпоративной сети

Какие задачи решает удалённый доступ к офису

Типичный запрос малого бизнеса звучит одинаково: бухгалтер должен работать в 1С из дома, менеджеры — открывать общую папку с договорами, а директор — подключаться к рабочему компьютеру по RDP из поездки. Всё это ресурсы внутри офисной сети, у которых нет и не должно быть публичного адреса в интернете. Защищённый удалённый доступ к корпоративной сети решает задачу так: устройство сотрудника получает шифрованный туннель до офисного шлюза и становится частью локальной сети — с внутренним адресом, маршрутами к нужным подсетям и корпоративным DNS.

Альтернатива, к которой прибегают из экономии времени, — проброс портов RDP или базы 1С наружу — плохой вариант: открытый RDP находят сканеры за часы, а дальше идут перебор паролей и шифровальщики. VPN для сотрудников убирает сервисы из публичного интернета: снаружи виден только один UDP-порт WireGuard, который без правильного ключа даже не отвечает.

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

Три архитектуры: site-to-site, road-warrior, облачный шлюз

Схема зависит от того, что соединяем: два офиса, сотрудников с офисом или сотрудников с сервером в облаке.

Site-to-site: офис — офис

Два роутера держат между собой постоянный туннель, и локальные сети обоих офисов (или офиса и склада) видят друг друга напрямую. Сотрудникам ничего настраивать не нужно — маршрутизация происходит на роутерах. Требование: хотя бы у одной стороны должен быть публичный IP-адрес или проброшенный UDP-порт; вторая сторона может инициировать соединение из-за NAT.

Road-warrior: сотрудник — офис

Классический удалённый доступ. На офисном роутере поднимается WireGuard-интерфейс, для каждого сотрудника создаётся peer со своим ключом и внутренним адресом (например, 10.10.0.11/32), а на ноутбуке или телефоне сотрудника стоит приложение WireGuard с конфигом. Туннель поднимается по требованию, и человек работает с 1С или RDP так, будто сидит в офисе.

Облачный шлюз

Если офиса как такового нет или провайдер не даёт публичный IP-адрес, роль шлюза берёт арендованный сервер: и офисный роутер, и сотрудники подключаются к нему, а он маршрутизирует трафик между ними. Так же подключают серверы 1С, вынесенные в облако. Плюс — независимость от публичного адреса в офисе; минус — ещё один узел, который нужно обслуживать и защищать.

Схемы комбинируются: типичный малый бизнес держит site-to-site между офисом и складом и road-warrior для пяти-десяти сотрудников на удалёнке — всё на одном роутере.

Почему WireGuard подходит бизнесу

Для офисного шлюза важны три свойства протокола, и у WireGuard они выражены сильнее, чем у IPsec и OpenVPN.

Производительность. WireGuard реализован в ядре Linux и в RouterOS 7, использует современные быстрые алгоритмы и минимальный заголовок. На практике это значит, что роутер среднего класса обслуживает десяток сотрудников без заметной нагрузки на процессор, а видеозвонки через туннель не «плывут». Официальное описание протокола — на wireguard.com.

Простота ключей. Никаких сертификатов, центров сертификации и сроков истечения. У каждой стороны пара ключей — приватный и публичный; peer идентифицируется публичным ключом. Конфиг сотрудника — десяток строк, которые можно прочитать глазами и понять, куда он ведёт. Что означает каждая строка, разобрано в материале разбор конфига WireGuard.

Отдельный профиль на сотрудника. Это главное управленческое преимущество. Один peer — один человек — одно устройство. Сотрудник уволился, ноутбук украли, ключ засветился в переписке — администратор удаляет один peer, и доступ прекращается мгновенно, никого больше это не затрагивает. Так же выдают временный доступ подрядчику: peer с адресом /32 и AllowedIPs только к нужному серверу, удаляемый по окончании работ. Общий «один конфиг на всех» в бизнесе недопустим именно потому, что отозвать его без остановки всех остальных невозможно.

Ограничение, о котором стоит знать: в WireGuard нет встроенной авторизации по логину и паролю и нет второго фактора. Владение ключом равно доступу. Поэтому ключ хранят как пароль, а второй фактор реализуют уровнем выше — в самой 1С, на RDP-шлюзе или при входе в систему.

Политика доступа: AllowedIPs только к нужным подсетям

Самая частая ошибка при настройке офисного VPN — выдать сотруднику AllowedIPs = 0.0.0.0/0. Тогда весь интернет-трафик сотрудника, включая личные сервисы и видео, идёт через офисный канал: провайдерский тариф офиса быстро упирается в потолок, а администратор становится невольным наблюдателем чужой личной жизни. Для корпоративного доступа правильный подход — split tunnel: в туннель уходит только то, что относится к офису.

Принцип формулируется в три пункта:

1. На стороне сотрудника (секция [Peer] его конфига) в AllowedIPs перечисляются только офисные подсети, например 192.168.10.0/24 для серверов и 192.168.20.0/24 для рабочих станций. Всё, что не попадает в эти сети, идёт напрямую через домашний интернет.
2. На стороне шлюза для peer сотрудника AllowedIPs — его личный адрес с маской /32. Это одновременно и маршрут, и фильтр: пакеты с другим адресом источника из этого туннеля роутер отбросит.
3. Между туннельной сетью и офисными подсетями работает обычный firewall. Бухгалтеру открыт сервер 1С по нужным портам, менеджерам — файловый сервер, никому — управляющие интерфейсы роутера и коммутаторов.

Так строится минимальная модель разграничения без дополнительного ПО. Если бизнес растёт и групп доступа становится много, удобно разнести сотрудников по нескольким WireGuard-интерфейсам на шлюзе (бухгалтерия, продажи, подрядчики), каждый со своей подсетью и своим набором правил. Дополнительно укажите в конфигах корпоративный DNS-сервер, чтобы внутренние имена вроде 1c.office.local разрешались через офисный DNS. Как раздельное туннелирование работает в целом, объясняет статья что такое split tunneling.

Шлюз в офисе: MikroTik или Keenetic

Оборудование зависит от масштаба и от того, кто будет его обслуживать.

MikroTik (RouterOS 7). Выбор для тех, у кого есть свой или приходящий сисадмин. WireGuard встроен в систему: в разделе WireGuard создаётся интерфейс, во вкладке Peers — по записи на каждого сотрудника, дальше адрес интерфейса, правило firewall на UDP-порт и маршруты. Гибкость полная: несколько интерфейсов, разные подсети, детальный firewall, скрипты. Пошагово — в инструкции как настроить WireGuard на MikroTik.

Keenetic. Вариант «настроил и забыл» для офиса без администратора: WireGuard есть в веб-интерфейсе (Другие подключения → WireGuard), peers добавляются формой, ключи генерируются на месте. Возможностей меньше, чем у MikroTik, но для road-warrior на десяток человек и одного site-to-site до склада их достаточно. Инструкция — как настроить WireGuard на Keenetic.

Общие требования к любому шлюзу: публичный IP-адрес или хотя бы стабильный проброс UDP-порта от провайдера, актуальная прошивка, отключённое управление роутером из интернета (доступ к нему — тоже только через туннель), резервная копия конфигурации после каждого изменения и журнал: кому, когда и какой peer выдан. Последнее удобно вести в обычной таблице — имя сотрудника, устройство, публичный ключ, дата выдачи, дата отзыва.

Где уместен сервис вроде Muhomor VPN, а где нужен свой шлюз

Персональный VPN-сервис и корпоративный шлюз часто путают, потому что оба называются VPN. Разница принципиальная: сервис вроде Muhomor VPN шифрует интернет-трафик устройства и выводит его через зарубежный сервер, но не даёт доступа ни к какой внутренней сети. Собственный шлюз, наоборот, открывает офисные ресурсы, но не защищает остальной трафик сотрудника, если split tunnel настроен правильно.

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

Когда нужен свой шлюз: есть локальные ресурсы (1С на сервере в офисе, NAS, RDP-станции, камеры), требуется разграничение по подсетям или обязателен контроль трафика внутри компании. Нередко работают оба слоя вместе: сотрудник в отеле поднимает персональный туннель для защиты всего трафика и поверх него — короткий туннель до офиса за счетами в 1С.

Чек-лист для ИП и малого бизнеса

• Инвентаризация: какие ресурсы нужны удалённо (1С, файлы, RDP, принтеры, камеры) и кому именно. Всё остальное в туннель не попадает.
• Архитектура выбрана: road-warrior для людей, site-to-site для филиала, облачный шлюз — если нет публичного IP-адреса.
• На шлюзе — отдельный peer на каждого сотрудника и каждое устройство; общих конфигов нет.
• AllowedIPs у сотрудников ограничены офисными подсетями; на шлюзе — /32 на peer.
• Firewall между туннельной сетью и офисом: только нужные порты к нужным серверам, управление роутером закрыто.
• RDP и 1С не опубликованы в интернет напрямую; вход в них защищён сложными паролями и вторым фактором, где он поддерживается.
• Журнал выданных ключей ведётся; при увольнении peer удаляется в тот же день.
• Резервная копия конфигурации шлюза сделана и хранится вне роутера.
• Для поездок и работы из публичных сетей у сотрудников есть персональный туннель (например, Muhomor VPN — пробный период 3 дня, затем разовая оплата на 30, 60 или 90 дней), и он не конфликтует с офисным.
• Есть регламент: конфиги передаются по защищённому каналу, не пересылаются в общие чаты и не хранятся в открытых папках.

Типичные ошибки

Первая — AllowedIPs = 0.0.0.0/0 «чтобы точно работало»: офисный канал занят чужим трафиком, а сотрудники жалуются на скорость. Вторая — единый конфиг «для отдела»: его невозможно отозвать у одного человека. Третья — управление роутером, открытое из интернета «на всякий случай», хотя шлюз и так даёт защищённый вход. Четвёртая — забытый MTU: если внутри туннеля не открываются некоторые сайты или зависает RDP, уменьшите MTU интерфейса до 1280–1400 и проверьте снова. Пятая — отсутствие резервной копии: замена сгоревшего роутера превращается в день простоя.