Практическая архитектура для объединения LAN нескольких офисов в единую маршрутизируемую сеть (site-to-site), с сохранением обхода блокировок через VLESS-подписку на роутерах OpenWrt (podkop / sing-box).
Заменяет схему "PPTP на каждый ПК" на прозрачный туннель уровня сети: пользователь просто обращается к внутреннему адресу удалённого офиса (RDP, 1С, внутренние сервисы) без ручной настройки VPN-клиента.
- Идея в двух словах
- 1. Топология
- 2. Логика маршрутизации трафика
- Требование к адресации
- 3. Переномерование подсетей
- Конфигурация WireGuard (пример)
- Firewall-зоны OpenWrt
- 4. WireGuard vs podkop: разделение ответственности
- podkop: разделение трафика по доменам
- 5. Диагностика
- 6. Масштабирование на 3+ офиса
- Чек-лист миграции адресации
- 7. Требования к железу
- Дисклеймер
| Было (PPTP) | Стало (WireGuard site-to-site) | |
|---|---|---|
| Уровень | per-PC (клиент на каждой машине) | site-to-site (туннель между роутерами) |
| Настройка у пользователя | VPN-профиль на каждом ПК | не требуется |
| Доступ | вручную выбранные хосты | вся подсеть удалённого офиса (или её часть по ACL) |
| Криптография | MS-CHAPv2 (небезопасно) | WireGuard (Curve25519 / ChaCha20) |
| Обход блокировок | отдельно, не связано | podkop/VLESS — независимый слой поверх |
Оба офиса имеют статический белый IP и одинаковую платформу — Cudy WR3000S на OpenWrt. Единый VPS с VLESS/Reality используется обоими офисами независимо друг от друга (это два параллельных подключения к одному серверу, а не общий туннель).
Каждый пакет на роутере проходит по одной из трёх веток: локальная доставка внутри своей подсети, WireGuard в сторону другого офиса, либо выход в интернет — напрямую через NAT или через VLESS-туннель podkop, в зависимости от того, попал ли домен/адрес назначения в проксируемые списки.
Site-to-site объединяет сети целиком на уровне маршрутизации — в отличие от PPTP, где каждый клиент ходил точечно к конкретным хостам. Из этого следует жёсткое требование:
Подсети офисов не должны пересекаться. Если в двух офисах есть одинаковый диапазон (например,
192.168.0.0/24в обоих), роутер не сможет решить, локальный это адрес или адрес за туннелем — локальный маршрут всегда побеждает, и трафик в WireGuard просто не уйдёт.
Правило выбора, какой офис переносить: меньше устройств — меньше работы. Переносим тот офис, где меньше статических привязок (обычно это офис с меньшим количеством камер/принтеров/NVR).
Рекомендуемая схема адресации — номер офиса во втором/третьем октете, чтобы адрес сразу читался:
Офис А: 192.168.0.0/24 (компьютеры) 192.168.1.0/24 (устройства/камеры)
Офис Б: 192.168.10.0/24 (компьютеры) 192.168.11.0/24 (устройства/камеры)
Офис В: 192.168.20.0/24 (компьютеры) 192.168.21.0/24 (устройства/камеры)
Оба офиса со статическими белыми IP — туннель симметричный, без нюансов NAT-traversal.
Офис А (/etc/config/network на OpenWrt, интерфейс wg0):
config interface 'wg0'
option proto 'wireguard'
option private_key '<ПРИВАТНЫЙ_КЛЮЧ_А>'
list addresses '10.99.0.1/30'
config wireguard_wg0
option public_key '<ПУБЛИЧНЫЙ_КЛЮЧ_Б>'
option endpoint_host '<БЕЛЫЙ_IP_ОФИСА_Б>'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.10.0/24'
list allowed_ips '192.168.11.0/24'
Офис Б — зеркально, allowed_ips указывает на подсети офиса А:
config interface 'wg0'
option proto 'wireguard'
option private_key '<ПРИВАТНЫЙ_КЛЮЧ_Б>'
list addresses '10.99.0.2/30'
config wireguard_wg0
option public_key '<ПУБЛИЧНЫЙ_КЛЮЧ_А>'
option endpoint_host '<БЕЛЫЙ_IP_ОФИСА_А>'
option endpoint_port '51820'
option persistent_keepalive '25'
list allowed_ips '192.168.0.0/24'
list allowed_ips '192.168.1.0/24'
persistent_keepaliveполезен даже при обоих статических IP — помогает быстрее восстанавливать сессию после провайдерских переключений/сбоев.
Создать отдельную зону под wg0 и разрешить forward в обе стороны с LAN,
без masquerade (NAT для трафика в туннель не нужен — адреса должны
доходить оригинальными):
config zone
option name 'wg'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '0'
list network 'wg0'
config forwarding
option src 'lan'
option dest 'wg'
config forwarding
option src 'wg'
option dest 'lan'
Для ограничения доступа (рекомендуется вместо полного открытия подсетей)
— добавить config rule с конкретными портами (например, только
3389/tcp до подсети терминальных серверов) вместо блока forwarding
на всю сеть.
Ключевой момент архитектуры — эти два туннеля решают разные задачи и не должны пересекаться по маршрутам:
- WireGuard — межофисный трафик (RDP, 1С, MyChat, доступ к внутренним
ресурсам). Маршрутизирует только пакеты, адресованные в подсеть другого
офиса (
AllowedIPs). - podkop (sing-box/VLESS) — интернет-трафик конкретного офиса, требующий обхода блокировок. Работает по спискам доменов, определяемым через DNS.
Трафик к внутренним (RFC1918) адресам другого офиса не должен попадать в domain-списки podkop — на практике конфликта не возникает, но после настройки стоит явно проверить (см. раздел 5. Диагностика).
- Работает независимо от WireGuard, поднимает свой sing-box/VLESS клиент до общего VPS.
- Матчинг — по спискам доменов (geosite/кастомные списки), определение происходит через DNS-запросы клиента.
- DNS клиентов должен указывать на сам роутер (раздаётся через DHCP), и WAN-сторона не должна иметь transparent DNS redirect выше по цепочке — иначе podkop не увидит нужные запросы.
- NAT (masquerade) на WAN-зоне для VLESS-трафика — стандартный, тут ничего не меняется относительно дефолтной конфигурации.
# какой интерфейс реально будет использован для адреса
ip route get 192.168.10.15
# статус WireGuard-пиров, последний handshake, трафик
wg show
# проверить, что трафик к другому офису НЕ улетает в VLESS
tcpdump -ni wg0 host 192.168.10.15
# проверить, что домены из proxy-листов действительно матчатся
logread | grep podkopПризнак корректной настройки: wg show показывает свежий latest handshake и растущий transfer, а ip route get <IP-другого-офиса>
указывает интерфейс wg0, а не wan/VLESS-интерфейс.
| Критерий | Hub-and-spoke | Full mesh |
|---|---|---|
| Количество туннелей | N−1 | N×(N−1)/2 |
| Трафик между "листьями" | транзитом через hub | напрямую |
| Точка отказа | hub — критичен | нет единой точки |
| Когда оправдано | офисы общаются в основном с центральным (А) | 4-5+ офисов с активным обменом друг с другом |
Для старта с 2 офисами выбор неактуален — эта развилка становится значимой при добавлении третьего и последующих офисов.
Перед переносом офиса на новую подсеть — пройтись по списку и зафиксировать всё, что сидит на статике:
| Устройство | Старый IP | Новый IP | Где ещё встречается адрес (ссылки/конфиги) | Готово |
|---|---|---|---|---|
| Камера 1 | NVR, ярлыки | ☐ | ||
| Камера 2 | NVR | ☐ | ||
| NVR/видеорегистратор | — | ☐ | ||
| Принтер | драйверы на ПК | ☐ | ||
| NAS | ярлыки, бэкап-скрипты | ☐ | ||
| Сервер 1С (если по IP) | клиентские базы 1С | ☐ | ||
| RDP-ярлыки на рабочих столах | — | — | заменить IP на DNS-имя, если возможно | ☐ |
Рекомендация: там, где это возможно, переходить со статических IP на DNS-имена (локальный DNS/hosts) — это делает будущие миграции адресации безболезненными.
Текущая нагрузка (RDP, 1С, MyChat, сёрфинг из-под удалёнки) — лёгкая по трафику, типовой Cudy WR3000S (2×A53 ~1.3 ГГц, 1 ГБ RAM) справляется с NAT + podkop + WireGuard одновременно без просадок.
При росте нагрузки (добавление видеосвязи, рост числа офисов/сессий) — апгрейд до более мощного SoC (4 ядра, 1 ГБ RAM, 512 МБ flash) переносится без изменения архитектуры — конфиг с текущего роутера копируется практически один в один, меняются только физические адреса интерфейсов.
Примеры конфигов — отправная точка, а не готовое решение "из коробки". Перед продакшеном:
- сгенерировать реальные ключи WireGuard (
wg genkey/wg pubkey); - сузить
AllowedIPs/firewall-правила до необходимых портов и хостов; - протестировать отказоустойчивость (обрыв канала, перезагрузка роутера).