Site-to-site или remote-access VPN: в чём разница и когда что нужно

MAATRIX

Когда в компании говорят «нам нужен VPN», часто имеют в виду совершенно разные вещи. Одному нужно связать офис в Москве со складом в Питере так, чтобы бухгалтерия видела 1С на сервере филиала как локальную папку. Другому — дать десяти удалённым сотрудникам доступ к внутренней сети без разброда самопальных решений. Это две разные архитектуры с разной настройкой, разным трафиком и разными граблями. Разберём, чем они отличаются технически и как выбрать правильную под задачу.

Что такое site-to-site VPN и как он работает

Site-to-site VPN — это постоянный туннель между двумя (или больше) сетевыми шлюзами, а не между пользователем и сервером. Устройства внутри каждой сети вообще не знают, что трафик идёт через VPN: маршрутизация настроена на уровне шлюза, и пакет из офисной подсети 192.168.10.0/24 в подсеть филиала 192.168.20.0/24 просто заворачивается в туннель автоматически.

Ключевая особенность — туннель не «поднимается по требованию» пользователем, он живёт постоянно (или переподнимается автоматически при обрыве) и обслуживает весь трафик между сетями, а не сессию одного человека. Аутентификация обычно построена на общих ключах или сертификатах шлюзов, а не на логинах сотрудников — потому что человека, который «логинится», тут просто нет.

Пример на WireGuard: на шлюзе офиса А в конфиг добавляется подсеть офиса Б целиком:

# /etc/wireguard/wg0.conf на шлюзе офиса А
[Interface]
PrivateKey = <ключ_А>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <публичный_ключ_Б>
Endpoint = 203.0.113.20:51820
AllowedIPs = 10.10.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25

Обратите внимание на AllowedIPs — там не адрес одного клиента, а целая подсеть филиала. Это и есть суть site-to-site: маршрут ведёт не к устройству, а к сети за устройством. На каждом шлюзе дополнительно включается IP forwarding и NAT/маршрутизация для транзитного трафика:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Подробная пошаговая установка WireGuard на сервере — в статье WireGuard на Ubuntu 24.04: пошаговая установка.

Что такое remote-access VPN и как он работает

Remote-access VPN — противоположная модель: центральный VPN-сервер и множество индивидуальных клиентов, каждый со своим ключом или логином. Каждый пользователь сам инициирует подключение со своего ноутбука или телефона, туннель существует, пока активен клиент, и после подключения пользователь получает виртуальный IP из отдельного пула — он «как будто» физически находится в офисной сети.

Здесь аутентификация персональная: сертификат на пользователя, логин/пароль, ключ WireGuard, привязанный к конкретному человеку, часто с MFA поверх. Это принципиально — в site-to-site шлюзы доверяют друг другу как единицам инфраструктуры, а в remote-access сервер должен различать конкретных людей и по необходимости отзывать доступ у одного, не трогая остальных.

Конфиг клиента WireGuard для remote-access выглядит иначе — AllowedIPs указывает не на подсеть, а обычно на весь трафик (full tunnel) или только на внутренние ресурсы (split tunnel):

# клиентский конфиг сотрудника
[Interface]
PrivateKey = <ключ_сотрудника>
Address = 10.10.0.50/32
DNS = 10.10.0.1

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = office-vpn.example.com:51820
AllowedIPs = 192.168.10.0/24, 10.10.0.0/24
PersistentKeepalive = 25

Здесь AllowedIPs ограничен внутренними сетями — это split tunnel, интернет-трафик сотрудника идёт напрямую, а не через офис. Для full tunnel (весь трафик через VPN, например ради обхода блокировок или единой точки выхода) там прописывают 0.0.0.0/0, ::/0. Разница между этими двумя вариантами разобрана в статье про автозапуск VPN при старте Windows и в материалах про подключение с конкретных устройств, например подключение к WireGuard с iPhone.

Ключевые технические различия

Разница в масштабировании — не абстракция. В site-to-site добавление новой площадки — это добавление одной пары ключей и одного маршрута на всех существующих шлюзах (или в mesh-топологии — на координаторе). В remote-access рост числа сотрудников означает рост числа сертификатов, записей в ACL, потенциально — нагрузки на сервер аутентификации.

Когда нужен site-to-site: сценарии и примеры

Site-to-site оправдан, когда связываете именно сети, а не людей:

• Филиалы и офисы. Головной офис и склад/филиал должны работать в общей сети — общие принтеры, файловые шары, внутренние сервисы без публикации наружу.
• Гибридное облако. Часть инфраструктуры в собственном ЦОД, часть — на арендованных VPS. Site-to-site туннель между локальным шлюзом и облачным сервером даёт единую внутреннюю сеть без публикации баз данных и внутренних API в интернет.
• Резервный ЦОД (DR). Постоянный канал для репликации данных между основной и резервной площадкой.
• Множество площадок — mesh или hub-and-spoke. Когда точек больше двух-трёх, ручное попарное связывание превращается в комбинаторный кошмар (для N площадок в полносвязной топологии нужно N×(N-1)/2 туннелей). Здесь разумнее mesh-решение поверх WireGuard, которое само управляет ключами и маршрутами — см. Netmaker: mesh VPN на WireGuard, установка.

Важный нюанс: site-to-site требует, чтобы на обоих концах был статический (или через DDNS отслеживаемый) публичный адрес или хотя бы предсказуемый способ установить Endpoint, а также чтобы у вас был административный доступ к обоим шлюзам — договориться о таком с чужим офисом или партнёром не всегда возможно, тогда остаётся только remote-access с точки зрения второй стороны.

Когда нужен remote-access: сценарии и примеры

Remote-access — правильный выбор, когда подключаются люди, а не сети:

• Удалённые сотрудники. Классика: человек дома или в поездке, ему нужен доступ к внутренним ресурсам компании — без выдачи ему статического IP и без прописывания его домашней сети в маршрутах офиса.
• BYOD и мобильные устройства. Телефоны и личные ноутбуки подключаются и отключаются непредсказуемо, у каждого свой профиль, который легко отозвать при увольнении или потере устройства.
• Подрядчики и временный доступ. Выдали сертификат на месяц, ограничили AllowedIPs только нужным сегментом сети, по окончании работ — отозвали. В site-to-site так гранулярно не получится: там либо весь офис в сети, либо ничего.
• Единая точка выхода в интернет. Full-tunnel remote-access, когда весь трафик пользователя идёт через сервер компании — для контроля или чтобы обойти региональные ограничения на конкретных сервисах.

На практике remote-access почти всегда требует продуманного управления доступом: список пользователей растёт, и без системы выдачи/отзыва ключей администратор быстро теряет контроль. Для аутентификации через корпоративный каталог полезно посмотреть аутентификацию VPN через Active Directory NPS — это снимает часть ручной работы по управлению учётками.

Гибридные схемы: когда нужны оба типа сразу

В реальной инфраструктуре редко бывает только один тип. Типичная комбинация: site-to-site туннель связывает офис с облачным сервером (общая внутренняя сеть, доступ к БД, внутренним API), а поверх того же сервера отдельно поднят remote-access для сотрудников, которые не в офисе. Это не конфликтует — на одном сервере WireGuard можно держать два интерфейса (wg0 для site-to-site, wg1 для remote-access) с разными политиками маршрутизации и разными группами ключей, либо развести их портами и отдельными конфигами.

Ещё один частый паттерн — hub-and-spoke: центральный сервер (хаб) держит site-to-site туннели с несколькими офисами-филиалами (спицами) и одновременно обслуживает remote-access для мобильных сотрудников. Хаб в этом случае логично разместить на арендованном VPS с хорошей связностью и статическим IP, а не в одном из офисов — так связь между филиалами не зависит от аптайма конкретной площадки. При росте числа площадок стоит сравнить, во что это выливается технически, с материалом WireGuard или OpenVPN — что выбрать для сервера: для site-to-site с несколькими точками WireGuard обычно проще в обслуживании за счёт компактных конфигов и отсутствия сертификатной инфраструктуры, а OpenVPN исторически удобнее там, где нужна тонкая настройка ACL через client-config-dir для большого числа remote-access пользователей.

Отдельно стоит DNS: в site-to-site DNS-сервер филиала обычно виден напрямую по внутреннему адресу, и настройка на клиентских машинах не нужна вовсе. В remote-access DNS нужно явно прописывать в конфиге клиента (DNS = 10.10.0.1 в WireGuard, push "dhcp-option DNS ..." в OpenVPN) — иначе сотрудник подключится к VPN, но внутренние имена (fileserver.local, 1c.corp) резолвиться не будут, и придётся ходить по IP.

Частые вопросы