Одинаковые подсети в двух офисах: как связать их через VPS

Адрес 192.168.1.10 в московском офисе принадлежит сетевому принтеру. В офисе в Казани тот же адрес принадлежит NAS с архивом договоров. Оба устройства честно настроены, оба доступны в своих сетях, и ни у одного нет причин считать, что адрес занят где-то ещё. Проблема начинается в тот момент, когда между офисами появляется VPN и кто-то пишет в браузере http://192.168.1.10.

Эта статья о том, как выбраться из такой ситуации, не отправляя пакеты не туда. Сразу скажу главное: одним маршрутом через сервер в середине задача не решается. Решаются три разные задачи тремя разными способами, и у каждого своя цена в сопровождении.

Как неоднозначность выглядит в таблице маршрутов

Человек видит два устройства и помнит, какое где стоит. Маршрутизатор ничего не помнит, у него есть только таблица: «для такого префикса отправляй туда-то». Когда пакет адресован на 192.168.1.10, ядро ищет самый специфичный подходящий префикс. Локальная сеть 192.168.1.0/24 на собственном интерфейсе подходит всегда, и пакет уйдёт в неё. До туннеля он просто не дойдёт: удалённая сеть с тем же префиксом проиграла в тот момент, когда на машине появилась локальная.

Теперь представим VPS посередине, к которому подключены оба офисных шлюза. На сервере в таблице оказываются два кандидата на один и тот же префикс, и оба ведут в разные туннели. В WireGuard это упирается в устройство самой модели. По руководству wg(8) параметр AllowedIPs у peer одновременно говорит, с каких адресов принимать входящий трафик от него и куда направлять исходящий. Это таблица соответствия «префикс — peer», и в ней один адрес не может вести к двум владельцам. Если вписать 192.168.1.0/24 двум peer на центральном узле, конфликт не исчезнет, а будет разрешён случайным для вас образом: трафик уйдёт к одному из них. Поэтому такой «обходной» вариант не считается решением.

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

Один небольшой пример, на котором будем сравнивать

Возьмём условную схему. Это учебный пример, а не описание чьей-то сети.

Задача: сотрудник офиса A должен печатать на принтере у себя и при этом открывать архив на NAS в офисе B. Тот самый адрес .10 в обоих случаях. Посмотрим, что можно сделать.

Перенумерация: больно один раз, зато честно

Самый чистый путь выглядит скучно: у одного из офисов меняется адресное пространство. Например, офис B переезжает с 192.168.1.0/24 на 192.168.20.0/24. После этого таблица маршрутов на VPS становится однозначной: 192.168.1.0/24 уходит к шлюзу A, 192.168.20.0/24 уходит к шлюзу B. В AllowedIPs каждого peer лежит свой непересекающийся диапазон, и вся логика WireGuard работает так, как задумана.

Что при этом нужно сделать руками, а не предположить:

• сменить подсеть на маршрутизаторе, пул DHCP и адрес самого шлюза;
• найти всё, что держит адреса статически: принтеры, камеры, СКУД, телефоны, точки доступа, сетевое хранилище;
• исправить статические записи DNS, правила файрвола, списки разрешённых адресов в приложениях и подключённых сервисах;
• пройтись по скриптам и заданиям, где IP вписан в текст: резервное копирование, монтирование шар, отчёты.

Последний пункт самый коварный. Устройства, которые вы знаете, переименовываются за вечер. Вещи, о которых забыли, всплывают через месяц: кто-то обратился по IP из ярлыка на рабочем столе, и ярлык молча перестал работать.

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

Выбор сети на клиенте: без переименования, но без одновременности

Некоторые решения, построенные поверх WireGuard, умеют работать с пересекающимися диапазонами. Например, в документации NetBird про пересекающиеся маршруты описан выбор маршрута на клиенте. Он помогает выбирать между сетями с одинаковыми диапазонами. При этом это функция выбора, а не автоматическое переименование всех адресов.

Практический смысл такой. Сотрудник включает «маршрут до офиса B», и в этот период адреса 192.168.1.x для его компьютера означают сеть B. Переключил на A, и тот же адрес ведёт в A. Это удобно, когда нужен аккуратный доступ администратора: пришёл разобраться с NAS в Казани, переключился, сделал работу, вернулся.

У способа есть жёсткое ограничение, которое надо понимать до начала внедрения: в каждый момент времени адрес имеет одно значение. Одновременно открыть принтер в A и NAS в B по одинаковым адресам нельзя. Для автоматических процессов, которым нужны обе сети сразу, например сервер резервного копирования, который забирает данные из двух офисов, такой подход не подходит. Нужно иметь в виду и локальную сеть самого клиента: если компьютер физически стоит в офисе с подсетью 192.168.1.0/24, локальные адреса для него всегда на первом месте.

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

Трансляция адресов: у каждого офиса появляется второе имя

Третий путь: оставить сети как есть и ввести для каждого офиса уникальный «внешний» диапазон-псевдоним. Для туннеля офис B живёт как 10.20.2.0/24, офис A как 10.20.1.0/24. Пакет к принтеру из B уходит на 10.20.1.10, на шлюзе A адрес подменяется на 192.168.1.10, и пакет попадает на принтер. Ответ идёт обратно по таблице трансляции.

Для нашего примера это можно описать так:

Таким образом, каждый офис видит удалённого соседа через неповторяющиеся адреса, а свои локальные адреса не меняет. На VPS остаётся простая картина: 10.20.1.0/24 ведёт к шлюзу A, 10.20.2.0/24 к шлюзу B. Пересечение пропало, но не потому что исчезло, а потому что его вынесли на края. Каждый офисный шлюз теперь держит у себя правила соответствия «псевдоним — реальный адрес».

Важная честная оговорка: это NAT, и он не бесплатен. Он не «волшебный туннель», который превращает конфликт в прозрачную связь. Он добавляет новую сущность, которую кто-то должен документировать, поддерживать и объяснять новому администратору. Если это забыть, через год никто не вспомнит, почему принтер в A на самом деле называется 10.20.1.10 в сети B, и первая же диагностика станет расследованием.

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

Что увидят DNS и журналы

Самое неприятное в трансляции проявляется не в момент запуска, а при первой же жалобе «что-то не открывается».

Начнём с DNS. У имени printer.office.local в офисе A запись указывает на 192.168.1.10. Если сотрудник из B спросит то же имя у DNS своего офиса, он получит либо ничего, либо свой собственный локальный адрес. Здесь нужна явная политика: для удалённых ресурсов заводятся отдельные имена, которые указывают на адреса-псевдонимы. Например, printer.a.corp ведёт на 10.20.1.10, а nas.b.corp на 10.20.2.10. Тогда имя всегда несёт контекст, а адрес в туннеле остаётся однозначным. Пытаться заставить одно и то же имя отвечать по-разному в зависимости от того, кто спрашивает, можно, но это ещё один слой поведения, который придётся поддерживать и отлаживать, и ради двух офисов он редко оправдан.

Теперь журналы. Устройство в A, получив запрос из B, увидит источником не реальный адрес клиента, а то, что подставил шлюз. Зависит от того, как настроена трансляция: меняется только адрес назначения или ещё и источник. Если источник тоже подменён на адрес шлюза, журнал принтера, NAS или файрвола покажет, что всё обращается «от шлюза». Это ломает расследования («кто удалил файл?») и любые правила, где доступ выдаётся по адресу клиента. Если же сохранять источник в виде псевдонима, например клиент из B виден в A как 10.20.2.57, диагностика станет понятнее, но придётся настроить обратный маршрут в A так, чтобы ответы на 10.20.2.0/24 шли обратно через шлюз.

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

Мелкая, но реальная ловушка с ресурсами за routing peer

Если вы строите сеть на платформе вроде NetBird, в документации по Networks ресурсом назван один IP, CIDR или домен, а доступ к ресурсу за routing peer требует разрешающей политики. Там же отмечено, что ресурс можно ограничить одним хостом вместо всей подсети. Для нашей задачи это полезно по двум причинам. Во-первых, не нужно открывать целиком /24 второго офиса ради одного принтера: достаточно описать один адрес. Во-вторых, чем уже ресурс, тем меньше шансов, что пересекающийся диапазон заденет что-то лишнее. Это не отменяет конфликта адресов, но уменьшает площадь, на которой он может сработать.

Сервисы, которые носят адрес внутри протокола

Трансляция подменяет адрес в заголовке пакета. Но некоторые протоколы кладут адрес ещё и в полезную нагрузку. Шлюз, который не знает об этом протоколе, подменит заголовок, а внутри пакета останется старый адрес, и удалённая сторона попытается вернуться по нему.

Как это выглядит на практике. Телефония по SIP и RTP сообщает в сообщениях, на какой адрес и порт присылать голос. Если в сообщении указан 192.168.1.10, а звонящий из другого офиса не знает такой сети или знает её как собственную, звук пойдёт не туда или не пойдёт совсем. Классический FTP в активном режиме передаёт адрес в командах канала управления. Некоторые системы мониторинга и управления оборудованием, а также приложения, которые возвращают клиенту «адрес, по которому со мной связаться», ведут себя так же. Это не абстрактная теория: именно такие продукты чаще всего «почти работают» после включения NAT, и страшно это тем, что часть функций работает, а часть нет.

Что с этим делать, в порядке убывания надёжности:

1. Выяснить, какие сервисы реально должны ходить между офисами. Обычно это не «всё», а несколько конкретных портов к нескольким конкретным узлам.
2. Для каждого сервиса прочитать документацию вендора о работе за NAT. Если там есть режим «внешний адрес» или «публичный адрес», настроить его на псевдоним.
3. Если у сервиса нет такой возможности, вынести его из зоны трансляции: перенумеровать только тот сегмент, где он живёт. Часто это одна VLAN с телефонией, а не весь офис.
4. Если ничего не помогает, оставить сервис в пределах офиса, а между офисами обмениваться через что-то, что адрес в полезной нагрузке не передаёт, например через прикладной шлюз или обычный HTTPS.

Проверять сервисы нужно не командой «пинг прошёл», а рабочим сценарием: позвонить, распечатать, смонтировать шару, запустить резервное копирование. Пинг ничего не говорит о том, где живёт адрес внутри протокола.

Какую роль играет VPS

Центральный сервер в такой схеме нужен как точка встречи. Офисные шлюзы обычно стоят за NAT провайдера, у них может не быть постоянного публичного адреса, зато они умеют сами устанавливать исходящее соединение. VPS с постоянным адресом принимает оба туннеля и маршрутизирует между ними. В WireGuard это естественно: peer определяется открытым ключом, а, как сказано в руководстве wg(8), endpoint обновляется по корректно аутентифицированным пакетам, поэтому смена внешнего адреса офиса не требует переписывать конфигурацию сервера.

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

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

Как выбрать подход

Решение зависит от двух вещей: сколько устройств нужно связать и насколько вы контролируете каждую сеть.

Если сомневаетесь, посчитайте не устройства, а зависимости. Двадцать компьютеров с DHCP почти ничего не стоят в перенумерации. Три принтера, два сервера с вшитыми адресами, сигнализация и телефония, о которых знает только подрядчик, заставляют серьёзно задуматься. Часто разумный компромисс такой: перенумеровать то, что перенумеровывается легко, а трансляцию оставить для нескольких адресов, которые менять дороже, чем поддерживать.

Есть и общий принцип: временный NAT почти всегда живёт дольше, чем планировалось. Если вы включаете его как временную меру до переезда, запишите срок и ответственного, иначе через год он станет «архитектурой».

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

Правило, которое стоит ввести сразу после выбора

Какой бы путь вы ни выбрали, одинаковые адреса нельзя оставлять только в головах. Рабочее правило из четырёх пунктов:

• У каждого офиса есть код и свой диапазон в туннеле. Например, A равно 10.20.1.0/24, B равно 10.20.2.0/24. Третий октет отражает номер офиса, а новое подключение берёт следующий свободный.
• Имя несёт контекст. Вместо printer пишем printer.a.corp. Если имя без суффикса офиса встретилось в чужом офисе, это ошибка.
• Единый реестр соответствий. Таблица из колонок: устройство, реальный адрес, адрес-псевдоним, владелец, дата добавления. Любое правило трансляции без строки в реестре считается ошибкой, и наоборот.
• В журналах всегда видно, какой адрес записан. Для каждого сервиса известно, получает ли он реальный адрес клиента или псевдоним, и это записано рядом с описанием сервиса.

Тогда адрес 192.168.1.10 перестаёт быть загадкой: в любом разговоре о нём первым вопросом звучит «в каком офисе?», а в любом туннельном трафике он вообще не встречается. Это и есть цель: не победить совпадение, а сделать так, чтобы оно больше никогда не требовало угадывания.