Обычно это выглядит так. Была фирма в одном помещении: сервер в углу, база 1С, сетевой диск, всё работает. Потом открыли склад на другом конце города, потом точку в соседней области — и теперь кладовщик звонит бухгалтеру за остатками, потому что до базы со склада не достучаться. Дальше начинается творчество, и я за годы насмотрелся на него достаточно: кто-то пробрасывает RDP наружу, кто-то синхронизирует папку в облаке руками, кто-то ставит вторую базу и сводит их по ночам скриптом трёхлетней давности. Работает это до первого расхождения данных или до первого визита посторонних, нашедших открытый порт. Нормальное решение называется Site-to-Site VPN. Это объединение офисов в одну сеть, при котором склад видит сервер в главном офисе так же, как если бы стоял с ним в одной комнате.
Разберу топологии, требования, протоколы, адресацию и то, обо что проекты спотыкаются чаще всего. Оговорюсь: я работаю в сервисе, который такие сети и строит, заинтересованность у меня есть. Но всё, что ниже, я видел руками, включая места, где мы сами сделали не лучшим образом.
Чем это отличается от обычного VPN
Разница принципиальная, и от её понимания зависит выбор всей архитектуры.
Клиентский VPN — это когда сотрудник ставит приложение на ноутбук и подключается к корпоративной сети: туннель поднят для одного устройства, выключил ноутбук — туннеля нет. Сценарий удалённой работы, ему посвящена страница про удалённый доступ. Site-to-Site — это когда соединяются не устройства, а сети целиком: туннель поднимают два маршрутизатора, и живёт он постоянно, сидит кто-то за компьютером или нет. Принтер на складе, касса в магазине, камера в цеху, сервер в офисе — все в одном адресном пространстве. Клиента ни на одном из них не стоит. И стоять не может: в кассу приложение не поставишь.
| Параметр | Клиентский VPN | Site-to-Site |
|---|---|---|
| Что соединяем | Устройство и сеть | Сеть и сеть |
| Где настраивается | На каждом устройстве | На двух маршрутизаторах |
| Когда работает | Пока пользователь подключён | Постоянно |
| Нужен ли софт на технике | Да | Нет |
| Типичный сценарий | Сотрудник из дома | Филиал, склад, магазин |
Одно другому, кстати, не мешает. По моему опыту, в нормальной инфраструктуре есть и то и другое: филиалы связаны постоянными туннелями, а сотрудники на выезде подключаются клиентом.
Зачем это нужно на практике
Ладно, абстракции в сторону. Вот реальные задачи, ради которых связь офисов через vpn затевают.
Общая база 1С. Самый частый повод, у меня почти каждый разговор начинается с неё. Без объединения сетей вариантов два, и оба плохие: выставлять сервер наружу или разводить копии. Стоит ли добавлять терминальный режим — разобрано в материале про VPN и RDP для 1С.
Файловый сервер. Договоры, макеты, проектная документация: сотрудник филиала открывает сетевую папку и работает с ней как со своей.
IP-телефония. Короткие внутренние номера, переадресация, общая очередь звонков. Телефония, я считаю, самая капризная тут: ей важна не ширина канала, а его ровность.
Видеонаблюдение. Камеры на складе пишутся на регистратор в офисе, а выставлять их в интернет — идея настолько плохая, что обсуждать не хочется: типовые пароли живут годами, я находил такие там, где сменилось два подрядчика.
Внутренние сервисы. CRM, почта, система учёта — всё, что не должно светиться наружу. Плюс централизованное управление: администратор видит технику всех площадок сразу. Общий знаменатель: сервисы остаются внутри периметра.
Три топологии: выбираем по числу точек
Схема связей определяет всё дальнейшее: стоимость, сложность, поведение при авариях. Впрочем, вариантов всего три.
Звезда. Есть центр — главный офис или сервер в дата-центре, филиалы подключаются к нему, между собой напрямую не общаются, и трафик со склада в магазин идёт через центр. Плюсы: просто настраивать и контролировать, политика доступа в одной точке. Минус очевиден — центр становится единственной точкой отказа. Лёг центр — встали все. Я однажды видел, как главный офис обесточили на четыре часа плановыми работами — и вместе с ним встали три филиала.
Полносвязная схема. Каждая площадка связана с каждой напрямую, трафик идёт кратчайшим путём, отказ одной точки не рушит остальные. Цена — сложность: три площадки дают три туннеля, пять — уже десять, восемь — двадцать восемь, и каждый надо настроить, задокументировать и поддерживать. Полный mesh, по моему опыту, имеет смысл для трёх-четырёх точек, дальше это кошмар администратора, который вдобавок уволится.
Облачный концентратор. Промежуточный вариант, и на мой взгляд лучший для большинства компаний: центром становится не офис, а выделенный узел в дата-центре. Топологически та же звезда, но центр стоит на хорошем канале, ему не нужен белый IP филиала, он не зависит от света в офисе и резервируется силами площадки. Подробности — на странице про выделенный VPN-сервер.
[Изображение: три схемы топологий — звезда с центром в офисе, полносвязная сеть, облачный концентратор в дата-центре]
| Топология | Когда подходит | Главный риск |
|---|---|---|
| Звезда | Сильный центральный офис, филиалы почти не общаются между собой | Отказ центра останавливает всё |
| Полносвязная | Три-четыре равнозначные площадки с интенсивным обменом | Сложность растёт нелинейно |
| Облачный концентратор | Филиалы без белых IP, рост числа точек, нужна независимость от офиса | Зависимость от площадки провайдера |
Что нужно иметь до начала работ
Список короткий, но каждый пункт, я знаю, умеет сорвать сроки.
Адресация. Самое важное, ему посвящён раздел ниже. Не пропускайте.
Белые IP или облачный узел. Чтобы два роутера подняли туннель, кто-то должен быть доступен снаружи: либо у одной стороны есть публичный адрес, либо обе идут к общему узлу.
Оборудование. Роутер должен уметь VPN и тянуть шифрование на нужной скорости, и ловушка тут вот какая: заявленная производительность маршрутизации и производительность с шифрованием — разные цифры, отличающиеся иногда в разы. Устройство, честно маршрутизирующее гигабит, на IPsec может выдавать пятьдесят, так что смотрите, к слову, характеристики именно по VPN. Помню проект, где неделю грешили на провайдера, пока не выяснилось, что процессор роутера сидит на сотне процентов.
Каналы. Ширина считается по задачам: файлы терпят, телефония и видео — нет. Для голоса важна стабильность задержки: сто мегабит с рваным джиттером хуже честных десяти, но ровных.
Статика в филиале. Сервер, сетевой диск и принтеры должны иметь постоянные адреса. Кажется мелочью, но именно на этом ломаются маршруты, и я на этом ловился.
Какой протокол брать
Религиозных войн не будет, скажу честно и практически.
| Протокол | Сильные стороны | Слабые | Где уместен |
|---|---|---|---|
| IPsec | Поддерживается всем железом, стандарт де-факто | Громоздкая настройка, много совместимых параметров с обеих сторон | Разнородное оборудование, готовые корпоративные железки |
| WireGuard | Быстрый, простой конфиг, мгновенно поднимается | Узнаваемый профиль трафика, есть не на всех устройствах | Современные роутеры, каналы без фильтрации |
| OpenVPN | Гибкость, работает поверх TCP, ходит через жёсткие файрволы | Тяжелее по ресурсам, медленнее | Старое железо, сложные сетевые условия |
| VLESS с маскировкой | Не опознаётся фильтрующим оборудованием | Требует поддержки на обеих сторонах | Каналы, где туннели режут |
Мой практический выбор такой. Железо одинаковое и современное — WireGuard: быстрее, проще, настройка занимает минуты вместо часов. Разношёрстный парк — IPsec, с ним договорятся все, хотя согласование параметров между железками разных поколений я, честно говоря, не люблю: одна молчит, вторая пишет невнятную ошибку. Канал, где туннели душат, — маскирующиеся решения, про них написано на странице VLESS для бизнеса. Сравнение первых двух — в материале WireGuard против OpenVPN, практика настройки туннелей между роутерами — в статье про WireGuard на MikroTik.
Адресация: то, на чём валятся проекты
Дошли до главного — того, из-за чего я и сел это писать. Если вы читаете по диагонали — остановитесь здесь.
Совпадающие подсети — самая частая причина, по которой объединение сетей не работает. Не протоколы и не кривое железо. Именно адресация. Механика банальна до обидного: почти все роутеры из коробки поднимают 192.168.1.0/24 или 192.168.0.0/24, офис настраивали в одном году, склад в другом, магазин ставил сторонний подрядчик — и у всех троих одна подсеть. Дальше поднимаем туннель, компьютер в офисе хочет достучаться до сервера на складе по адресу 192.168.1.10, но у него самого есть машина с таким же адресом. Куда пойдёт пакет? Никуда. Аналогия простая: две улицы с одинаковым названием в одном городе, и на обеих дом номер семь.
Лечится это, если честно, только планированием, причём заранее.
- Каждой площадке — свой диапазон. Никаких пересечений и никаких исключений.
- Выделите один блок под компанию — скажем, 10.0.0.0/8 — и режьте по площадкам: 10.10.0.0/24 офис, 10.20.0.0/24 склад, 10.30.0.0/24 магазин.
- Оставляйте запас. Новые точки появляются всегда и всегда внезапно.
- Избегайте 192.168.0.0/24 и 192.168.1.0/24. Минное поле: они стоят по умолчанию у половины домашних роутеров, и сотрудник из дома рано или поздно словит конфликт.
- Держите таблицу адресов. Обычный документ: какой диапазон за какой площадкой. Через год без него не вспомните ничего.
[Изображение: схема планирования адресного пространства — единый блок, нарезанный на подсети по площадкам, с резервом под будущие точки]
Если сети уже развёрнуты и пересекаются — придётся либо переадресовать одну из площадок, либо городить трансляцию адресов на границе туннеля. Второе работает, но превращает схему в конструкцию, которую через полгода не починит никто. Я почти всегда советую первое: болезненно один вечер, зато потом чисто. Один раз мы пошли лёгким путём и оставили трансляцию, потому что склад работал в три смены; через год схему разбирал другой человек, и он, подозреваю, до сих пор вспоминает нас недобрым словом.
Отказоустойчивость: что будет, когда канал упадёт
Не «если». Когда. Провайдер в филиале порвёт кабель экскаватором, у оператора случится авария, в офисе выключат свет. Это происходит со всеми, вопрос в частоте. Спросите себя честно: что остановится, если туннель ляжет на четыре часа? Ответ «люди не смогут открыть документы» — переживём. Ответ «встанет касса» или «перестанут проходить звонки клиентов» — резерв обязателен, и считать его стоимость нужно по цене простоя, а не по цене железа. Мне однажды посчитали это наглядно: магазин, суббота, очередь, касса не пробивает — и вопрос «зачем нам второй канал за тысячу рублей» больше не поднимался.
Что обычно делают:
- Второй провайдер плюс автопереключение. Ключевая деталь — проверять не линк в порту, а реальную доступность узла на той стороне: кабель воткнут, а интернета нет — ситуация штатная.
- Мобильный интернет как резерв. Дёшево и на удивление эффективно для небольшой точки: хватит на кассу, терминал и телефонию.
- Резервный туннель через другой узел концентратора.
- Локальная живучесть. Касса должна уметь работать автономно и синхронизироваться потом. Не всё чинится сетью.
И отдельно, раз уж зашла речь: переключение надо проверять. Выдерните основной канал в спокойное время и посмотрите, сколько уходит на переход и что при этом отваливается — сюрпризы будут: телефония рвёт сессии, часть сервисов не переживает смену адреса. Резерв, который не тестировали, — не резерв, а надежда. Понять, что и когда падало, помогает мониторинг подключений, подробнее — в материале о мониторинге VPN.
Безопасность: туннель — это не защита сам по себе
Заблуждение, которое я слышу чаще прочих: объединили сети — стало безопасно. Не стало. Вы соединили периметры, и теперь заражённая машина в филиале имеет прямой путь к серверу в офисе.
Что делать:
Сегментация. Не открывайте всё всем: складу нужен доступ к базе и файловому серверу — вот их и открывайте, а камеры не должны ходить никуда, кроме регистратора. По умолчанию запрещено, разрешается точечно.
Правила доступа на границе. Списки на маршрутизаторе, ограничения по портам и адресам: туннель даёт связность, разграничение делаете вы.
Журналирование. Кто, куда, когда. Без логов разбор инцидента превращается в гадание, а инциденты, скажем так, случаются — и ровно тогда, когда логи никто не включил.
И люди. Сотрудники подключаются клиентом извне, и там нужны роли, регламент и двухфакторная аутентификация, а как выстроить политику доступа — отдельный разговор. И не берите для этого потребительский сервис: разница между личным и корпоративным решением не в маркетинге, а в модели ответственности, о чём есть отдельный разбор.
Если у филиалов нет белых IP
Ситуация, которую я вижу через раз: в офисе публичный адрес есть, а склад сидит за провайдерским NAT, и статика там либо дорога, либо невозможна, а на мобильном интернете белого адреса нет почти никогда. Классический туннель между такими точками не поднимется: ни одна сторона не достучится до другой. Решение — облачный концентратор: узел с публичным адресом в дата-центре, к которому филиалы подключаются сами, изнутри наружу. Исходящие соединения проходят через NAT свободно, встречной доступности не требуется. Обе площадки приходят на общую точку, и маршрутизация между ними идёт через неё. Site to site vpn настройка без белого ip выглядит именно так, и побочные плюсы тут часто перевешивают основной:
- Не нужно платить провайдеру за статические адреса на каждой точке.
- Новая точка добавляется настройкой на ней самой, без перенастройки остальных.
- Схема не зависит от аварий в офисе, а канал дата-центра обычно лучше и резервируется не вами.
Минус, впрочем, назову честно: появляется зависимость от провайдера узла, так что смотрите на его резервирование и на то, кто отвечает за доступность. Как это устроено у нас — на странице объединения офисов и в разделе корпоративных решений.
Чек-лист внедрения и типичные грабли
Порядок действий, проверенный на моих проектах.
- Опишите задачи: какие сервисы, кому, с какой площадки.
- Соберите инвентарь: адресация, оборудование, провайдеры, наличие публичных адресов.
- Спроектируйте адресное пространство, устраните пересечения до начала работ.
- Выберите топологию исходя из числа точек и наличия белых IP.
- Выберите протокол под имеющееся железо.
- Поднимите туннель на двух площадках и проверьте.
- Пропишите маршруты и правила доступа. Проверяйте связность нужных сервисов, а не просто пинг.
- Настройте резервный канал и протестируйте переключение.
- Подключите мониторинг и оповещения.
- Задокументируйте схему. Через полгода скажете себе спасибо.
- Подключайте остальные площадки по готовому шаблону.
Грабли, на которые наступают чаще всего:
- Пересекающиеся подсети. Номер один с большим отрывом.
- Роутер, который не тянет шифрование на нужной скорости.
- Нет резерва там, где простой стоит денег. Или резерв есть, но его ни разу не проверяли.
- Доступ открыт целиком, без сегментации: «потом закроем». Не закроют.
- Никакой документации. Администратор уволился — схему разбирают заново.
- Забыли про DNS: сети соединили, а по именам ничего не резолвится.
[Изображение: чек-лист внедрения Site-to-Site VPN в виде таблицы с этапами и ответственными]
Что стоит унести с собой
Адресация решается на бумаге до того, как куплено оборудование: экономия на этом пункте гарантированно обойдётся дороже. Топология выбирается по числу точек и наличию белых IP — нет белых, значит концентратор, и это не компромисс, а нормальное решение. Резерв нужен там, где простой стоит денег, и его надо проверять, а не верить в него. Туннель даёт связность, но не безопасность: сегментация и правила доступа — ваша работа.
Если проект уже на столе и собирать его методом проб не хочется — спроектируем объединение сетей под вашу инфраструктуру: предложим топологию и адресацию, соберём схему с резервом. Начать можно с бесплатного теста на 14 дней: поднять один туннель между двумя площадками и посмотреть, как он ведёт себя на ваших каналах. Это, я считаю, честнее любых обещаний в презентации.
Частые вопросы
Что такое Site-to-Site VPN?
Постоянный шифрованный туннель между сетями двух площадок, поднятый на маршрутизаторах, а не на компьютерах пользователей. Вся техника обеих сторон — серверы, принтеры, камеры, кассы — работает так, будто стоит в одной локальной сети. Никакого клиентского софта на устройствах при этом не требуется.
Как объединить два офиса в одну сеть?
Сначала развести адресацию так, чтобы подсети не пересекались, затем поднять туннель между маршрутизаторами и прописать маршруты. Есть публичный адрес хотя бы у одной стороны — туннель строится напрямую, нет — обе площадки идут к облачному концентратору. Дальше правила доступа, резервный канал и мониторинг.
Нужен ли белый IP каждому офису?
Нет. Достаточно публичного адреса у одной стороны, а при схеме с облачным концентратором он не нужен ни одной площадке: все подключаются к узлу в дата-центре исходящими соединениями, которые свободно проходят через провайдерский NAT. Это же решение подходит для точек на мобильном интернете.
Какой протокол выбрать для связи офисов?
Однотипное современное оборудование — WireGuard: быстро, просто, нетребовательно к ресурсам. Разнородный парк — IPsec, его понимают практически все корпоративные устройства. Канал фильтруют и обычные туннели на нём не живут — нужны маскирующиеся решения вроде VLESS.
