Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Как устранить пересечение подсетей WireGuard безопасно
Ryan Foster
11 октября 2026 г.· 10 мин чтения
Пересечение подсетей WireGuard возникает, когда один диапазон назначения обозначает разные машины по обе стороны туннеля. Устраните неоднозначность перенумерацией одной контролируемой LAN, затем обновите маршруты, префиксы peer и зависимые службы: успешное рукопожатие или расширение AllowedIPs не различают два узла с одинаковым адресом.
Ключевые выводы
- До изменения маршрута установите идентичность локальной и удаленной машин.
- Сохраните управление независимо от перенумеровываемой LAN.
- Меняйте адреса одного объекта, а не все маршруты по умолчанию одновременно.
- Проверяйте цель, обратный путь, DNS, права и сохранение настроек.
Зачем пересечение подсетей WireGuard требует плана адресации?
Инструкция рассчитана на Ubuntu 24.04 LTS с инструментами WireGuard из дистрибутива, действующий маршрутизируемый туннель между объектами и административный контроль удаленной LAN. Она составлена по официальной документации для указанной среды; полное сквозное испытание автором не выполнялось. Интерфейсы под NetworkManager, контейнерные сети, перенумерация IPv6 и корпоративные шлюзы требуют собственных утвержденных процедур.
Используйте проверочный список самостоятельной эксплуатации для определения ответственности и восстановления. Маршруты Linux выбирают интерфейс; префиксы WireGuard выбирают peer для исходящих пакетов и ограничивают входящие адреса источника. Они не присваивают идентичность неоднозначному адресу назначения.［1］［2］
Задача касается частного ресурса. Сохраняйте собственный или организационный способ доступа, когда нужен именно он. Лишь при изменении задачи на интернет-выход сравните домашний шлюз и обслуживаемый VPN-сервис; такой выбор сам по себе не исправляет коллизию адресов.
Шаг 1: Зафиксируйте обе LAN и управление
Убедитесь, что новый диапазон не занят в организации, у peer, в контейнерах и достижимых сетях. В иллюстративной топологии ниже замените имена интерфейсов и адреса своей инвентаризацией: частный префикс не является глобально уникальным.
| Роль | До изменения | После изменения удаленного объекта |
|---|---|---|
| Локальная LAN A | 192.168.50.0/24 | Без изменений |
| Удаленная LAN B | 192.168.50.0/24 | 192.168.77.0/24 |
LAN-шлюз B на ens19 | 192.168.50.1 | 192.168.77.1 |
| Разрешенная цель на B | 192.168.50.10 | 192.168.77.10 |
| WireGuard A / B | 172.31.253.1/32 / 172.31.253.2/32 | Без изменений |
| Независимое управление B | Консоль или отдельный управляющий интерфейс | Без изменений |
Внешний endpoint WireGuard должен оставаться доступным по исходному пути управления/WAN. Туннельный диапазон отличается от обеих LAN. Если пересекается именно туннельный диапазон или изменить B невозможно, остановите эту процедуру перенумерации и согласуйте другой дизайн с владельцем.
Запишите статические аренды, пул DHCP, шлюзы, DNS, привязки служб, ACL, мониторинг и всех затрагиваемых peer. Выделите окно обслуживания и подтвердите консоль новым сеансом. Непублично скопируйте конкретные файлы Netplan, WireGuard и менеджера межсетевого экрана с исходными правами; не вставляйте wg showconf или wg show ... dump в обращение поддержки, поскольку они могут раскрывать ключи.［1］
Шаг 2: Подтвердите конфликт маршрутов VPN
Выполните проверки только для чтения на затронутом клиенте или шлюзе Ubuntu, указав реальный интерфейс и адреса:
ip -brief address
ip -4 rule show
ip -4 route show table all
ip -4 route get 192.168.50.10
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer
Сохраняйте только обезличенные наблюдения. Маршрут в локальную LAN объясняет, почему предполагаемая удаленная цель отвечает без прохождения WireGuard. Рукопожатие подтверждает недавний обмен peer, но не идентичность LAN-узла и не разрешение на сервис. Проверяйте policy rules наряду с основной таблицей.［2］［3］
Подтвердите машину по инвентарному идентификатору, проверенному сертификату TLS или ключу SSH, сверяемому установленным процессом доверия. Одного ping недостаточно. Не принимайте изменившийся SSH-ключ или сертификат только из-за совпавшего адреса; свяжитесь с владельцем через независимое управление.
Если выбран правильный непересекающийся удаленный диапазон, используйте проверки туннеля без полезного трафика. Не перенумеровывайте рабочую LAN ради компенсации запрета сервиса или отсутствующего разрешения на пересылку пакетов.
Шаг 3: Устраните конфликт подсетей WireGuard
Перенумерация B дает машинам различные сквозные адреса; это основной путь далее. Host route, направляющий 192.168.50.10 в туннель, может выбрать B, но скроет локальный адрес в том же контексте маршрутизации. Одновременный доступ к обеим идентичностям так не появляется.
| Подход | Условие применения | Цена или ограничение |
|---|---|---|
| Перенумерация одной LAN | Контролируете адреса и зависимости | Согласованно меняете DHCP, статические узлы, DNS и политики |
| Управляемая трансляция адресов | Владелец не может перенумеровать LAN, но управляет шлюзом | Резервируете alias-префикс и определяете оба направления |
| Отдельный контекст маршрутизации | Приложения работают в изолированных namespace | Требуется явное владение интерфейсами, DNS и управлением |
WireGuard описывает изоляцию namespace, но перенос интерфейса меняет видимую приложениям сетевую среду; это не случайное исправление в удаленном сеансе.［2］ Рецепт Netgate для совпадающих подсетей использует OpenVPN, не WireGuard. Он подтверждает принцип отображения и ограничения, но не дает команды WireGuard.［4］
Для трансляции определите реальные и alias-префиксы, преобразование назначения входящего трафика, необходимые преобразования источника, обратный маршрут, DNS и журналы. Приложения со встроенными IP и обратными инициируемыми соединениями могут по-прежнему не работать. NAT не дает права доступа и не заменяет межсетевой экран. Если эти поля не определены, остановитесь вместо применения широкого masquerade.
Шаг 4: Перенумеруйте только контролируемый удаленный объект
Начните через консоль B. В существующей конфигурации Netplan у ens19 измените только адрес LAN с 192.168.50.1/24 на 192.168.77.1/24, сохранив renderer и все поля управляющего интерфейса. Ниже фрагмент поля, а не замена всех файлов Netplan:
ens19:
addresses:
- 192.168.77.1/24
Если B раздает DHCP, обновите пул и параметр шлюза. На разрешенной тестовой цели через ее существующий сетевой менеджер и консоль установите 192.168.77.10/24, шлюз 192.168.77.1. Последовательно перенесите резервации и прочие статические узлы без дублирующихся аренд. Обновите адреса прослушивания служб и узкие правила для нового префикса, сохранив прежнюю политику forwarding и endpoint.［5］
Проверьте и попробуйте конфигурацию B с независимой консоли:
sudo netplan generate
sudo netplan try --timeout 120
Подтвердите изменение только после проверки консоли, управляющего пути, нового LAN-шлюза и цели. Документация Netplan предупреждает об ограничениях отката: после отказа или тайм-аута самостоятельно проверьте реальную сеть и файлы на диске, не предполагая полного восстановления.［6］ Если интерфейсом управляет другой менеджер, остановитесь и используйте его документированную процедуру отката.
На A измените только запись peer B в закрытой конфигурации wg-quick. Сохраните его реальный публичный ключ, endpoint и учетные данные. Полный набор префиксов для данной топологии становится таким:
AllowedIPs = 172.31.253.2/32, 192.168.77.0/24
Это присваивание заменяет прежний набор peer, а не добавляет элемент. Если peer обслуживает другие разрешенные сети, явно сохраните их. Peer A на B по-прежнему должен разрешать реальные источники A: здесь 172.31.253.1/32 и 192.168.50.0/24, с соответствующим обратным маршрутом. Обязанности префиксов peer и маршрутов объясняют, почему одного поля недостаточно.［1］
Для этого уже инвентаризированного выделенного туннеля wg-quick примените сохраненный файл с независимой консоли A: sudo wg-quick down wg0, затем sudo wg-quick up wg0. Краткий перерыв предусмотрен. Сначала проверьте hooks и SaveConfig: при SaveConfig = true выключение может перезаписать ваши изменения файла; остановитесь и согласуйте текущее и постоянное состояние. Один wg set не обновляет системные маршруты.［7］
Не очищайте таблицы маршрутов, весь межсетевой экран, не расширяйте префикс до 0.0.0.0/0 и не меняйте оба маршрута по умолчанию ради ответа. Общий туннель требует процедуры владельца, а не перезапуска доступа других пользователей.
Шаг 5: Проверьте идентичность, обратный путь и DNS
Повторите на A поиск маршрутов к 192.168.50.10 и 192.168.77.10: первый должен оставаться локальным, новый удаленный — выбирать wg0. На B проверьте путь возврата к реальному источнику A. Выполните разрешенный запрос приложения с проверенной идентичностью сервера, не ограничиваясь ICMP.［3］
| Метод проверки | Ожидаемое наблюдение | При расхождении |
|---|---|---|
| Сравнить старую локальную и новую удаленную цели | Разные локальный и туннельный пути | Проверьте policy tables и старые маршруты |
| Проверить сертификат или утвержденный ключ узла | Отвечает нужная машина B | Остановитесь при несовпадении идентичности |
| Проверить на B маршрут к источнику A и префиксы peer | Возврат идет разрешенным путем | Исправьте узкий обратный маршрут или запись peer |
| Запросить соответствующий частный DNS | Имя сервиса возвращает новый адрес | Обновите authoritative-записи и ограниченные кэши |
| Запросить разрешенный и запрещенный сервисы | Прежние права продолжают действовать | Исправьте префиксные правила, не отключайте политику |
| Переподключиться и перезагрузиться в согласованное окно | Адреса, маршруты и сервис восстанавливаются одинаково | Исправьте постоянную конфигурацию владельца |
Не меняйте публичный DNS для частного имени, известного только организационному резолверу. Учитывайте TTL записей и кэши приложений до вывода старого адреса. Проверки относятся к частным ресурсам и не требуют сайта публичного IP.
Если другой путь приложения проходит прокси, отдельно примените проверки цепочки по узлам. Успех прокси-запроса не доказывает этот маршрут WireGuard или его обратный путь.
Шаг 6: Восстановите точные изменения или сохраните новый план
При провале приемки прекратите изменения. Через независимые консоли восстановите исходные LAN, DHCP, адрес цели B и только измененные в этом окне политики/DNS. Верните сохраненную конфигурацию peer A и перезапустите лишь выделенный туннель через его установленный менеджер. Не возвращайте отозванный peer и не перезаписывайте посторонние параллельные изменения политик.
Проверьте исходное управление, слушатели, назначения адресов, маршруты и известный прежний сервис. Возврат старого пересечения восстанавливает исходную неисправность, а не доказывает ее устранение. Запишите оставшееся ограничение и отложите эксперименты, если восстановление не подтверждается.
При успешной приемке сохраните новый инвентарь и закрытую копию по правилам владельца. Отзовите временные учетные данные, удалите временные разрешения и закрепите ответственность DHCP/DNS. Постоянство подтверждается переподключением и перезагрузкой, а не одним сохраненным файлом.
Итоги
- Докажите неоднозначность адресов до изменения топологии.
- Перенумеруйте одну контролируемую LAN с независимым управлением.
- Согласованно обновите маршруты, префиксы peer, DNS и политики.
- Проверьте разные цели и обратный путь.
Часто задаваемые вопросы (FAQ)
Исправит ли расширение AllowedIPs пересечение подсетей WireGuard?
Нет. Более широкие префиксы захватывают больше трафика, но не различают две машины с одинаковым адресом назначения в одном контексте маршрутизации.
Почему рукопожатие есть, а отвечает другая машина?
Рукопожатие подтверждает связь peer, но маршрут приложения может выбирать локальную машину с тем же адресом, что у удаленной цели.
Можно заменить перенумерацию host route?
Узкий маршрут к узлу позволяет намеренно выбрать одну сторону, но другая машина с этим адресом станет недоступна в том же контексте.
Всегда ли трансляция проще изменения LAN?
Нет. Нужны осмысленные прямые и обратные отображения, совместимые приложения, правильный DNS и поддерживаемая политика; журналы и обратные соединения могут усложниться.
Нужно одновременно менять адрес endpoint WireGuard?
Не при изменении только внутренней LAN B. Сохраните рабочий WAN endpoint и независимое управление, если их собственное утвержденное изменение не требует другого.
Можно перезапустить туннель через единственное SSH-соединение?
Не выполняйте процедуру через единственный путь управления. Сначала установите и проверьте независимую консоль, затем меняйте адреса или перезапускайте туннель.
Достаточно вернуть старые файлы для восстановления?
Нет. Самостоятельно проверьте текущие адреса, маршруты, DNS, права и управление: сохраненный файл или таймер отката не подтверждает реальное восстановление.
Источники:
- Ubuntu 24.04 — wg(8)
- WireGuard — Routing & Network Namespaces
- Ubuntu 24.04 — ip-route(8)
- Netgate — Connecting OpenVPN Sites with Conflicting IP Subnets
- Netplan — Configuration examples
- Netplan — netplan try
- Ubuntu 24.04 — wg-quick(8)
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
