Добавление второй подсети в VPN между площадками: два пути
Туннели на основе политик требуют согласованных селекторов с обеих сторон; туннели на основе маршрутов требуют маршрута. Выберите верный путь и сначала исправьте обратный маршрут.
Добавление второй подсети в работающий туннель между площадками занимает пять минут в одной схеме и почти весь день в другой. Когда туннель устанавливает маршруты для указанных префиксов, вы добавляете маршрут, и трафик идёт по нему. Когда он согласует одну фиксированную пару селекторов, новый префикс остаётся незащищённым, пока обе стороны не договорятся о подходящей паре. Решают три вещи: что на самом деле описывает конфигурация каждой стороны, сужается ли согласованный трафик до наименьшей подходящей пары и кому принадлежит обратный маршрут для нового диапазона.
Читайте ядро, а не метку состояния
Туннель, сообщающий о соединении, установил хотя бы одну дочернюю ассоциацию, но не обязательно ту, о которой вы думаете. В Linux ядро показывает, что применяется: ip xfrm policy перечисляет пары селекторов, а swanctl --list-sas (или старый ipsec statusall) показывает, о чём договорились стороны, включая селекторы трафика в каждом направлении. Если нового префикса нет ни там, ни там, он не защищён, что бы ни говорил файл конфигурации.
Сравните с таблицей маршрутов. В схеме на основе маршрутов устройство туннеля — следующий переход для защищённых префиксов. В схеме на основе политик часто нет отдельного маршрута к удалённой подсети, только маршрут по умолчанию, потому что трафик выбирает политика, а не таблица.
На основе политик: обе стороны должны указать новый префикс
В терминах strongSwan селектор живёт в local_ts и remote_ts дочерней конфигурации, наследниках leftsubnet и rightsubnet. Новый префикс должен появиться с обеих сторон зеркально: то, что площадка A называет локальным, площадка B называет удалённым. Несовпадение редко даёт чистую ошибку. Стороны сужаются до пересечения, старый префикс продолжает работать, а новый тихо отказывает.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyВ pfSense или OPNsense это вторая запись Phase 2, связывающая новую локальную подсеть с новой удалённой, и затем применение. Сохраните старую запись; замена перемещает исходную подсеть вместо добавления. Если существующая Phase 2 уже покрывает суперсеть вроде 0.0.0.0/0 или сводный диапазон, не добавляйте рядом более узкую запись: перекрывающиеся селекторы устанавливают конкурирующие политики, и порядок оценки решает победителя.
IKEv1 делает каждую пару подсетей отдельной Phase 2, и сторона, принимающая одну пару за обмен, отбрасывает остальные. IKEv2 может нести несколько пар селекторов в одной дочерней ассоциации, но только если обе реализации их принимают. Список из swanctl --list-sas — истина; то, что вы набрали, — запрос.
На основе маршрутов: маршрут и есть политика
Интерфейс XFRM или устройство VTI несёт трафик согласно таблице маршрутов. Вы направляете новый префикс на устройство на обеих площадках, и применяется состояние, привязанное к трансформации интерфейса. Пары селекторов, которую нужно синхронизировать, нет, поэтому эта схема лучше масштабируется с ростом числа подсетей. Руководство strongSwan по пересылке подробно разбирает сторону ядра.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard идёт дальше. AllowedIPs — одновременно криптографический белый список и, через wg-quick, запись в таблице маршрутов. Добавьте префикс только на одной стороне — получите рукопожатие, исходящие пакеты и тишину, потому что дальняя сторона отбрасывает пакеты, чей источник не в её списке. Форма wg set заменяет весь список, поэтому перечислите заново уже работавшие префиксы, иначе отрежете их:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Вторая команда не является необязательной, если вы использовали wg set вместо wg-quick. Ядро сразу принимает новый список, но никто не добавляет для него маршрут, поэтому локально созданный трафик по-прежнему уходит через шлюз по умолчанию. Это самая частая причина, по которой новая подсеть WireGuard работает с хоста туннеля, а не с ноутбука.
Обратный путь отказывает чаще, чем туннель
Хосты в новой удалённой подсети должны отправлять ответы обратно через шлюз VPN. Когда этот шлюз не является их маршрутизатором по умолчанию, ответ уходит на маршрутизатор LAN, который либо отбрасывает его, либо пересылает в интернет с частным адресом источника. Проверяйте с хоста на дальней стороне, а не со шлюза: ip route get 10.30.20.15 в Linux или Find-NetRoute -RemoteIPAddress 10.30.20.15 в PowerShell покажет следующий переход, который хост действительно использует. Если ответ не является конечной точкой туннеля, добавьте там статический маршрут для нового префикса.
Исходный NAT на площадке без обратного маршрута — законная альтернатива и способ, которым многие развёртывания hub-and-spoke избегают трогать каждый сервер. Примените его и к новому префиксу на шлюзе стороны назначения:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEЦена реальна. Удалённые журналы перестают показывать отдельные адреса источников, а правила межсетевого экрана, привязанные к исходной подсети, сливаются в одно правило для шлюза. Выбирайте это осознанно, а не потому, что не хватало маршрута.
Межсетевые экраны — вторая половина обратного пути. Устройства на основе зон не расширяют зону существующего интерфейса туннеля на новую подсеть автоматически, а правило, написанное для старого префикса, не совпадёт. Добавьте новую подсеть в зону или в пару правил в обоих направлениях, прежде чем винить IPsec.
Решите тремя вопросами, затем проверьте трафиком
Короткая версия: конфигурация стороны называет префиксы (на основе политик) или трафик маршрутизируется в интерфейс (на основе маршрутов)? Перечисляют ли оба конца новый префикс? Есть ли путь назад из новой подсети в исходный диапазон источников?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Проверка — место, где большинство изменений закрывают слишком рано. Пинг со шлюза доказывает немногое: шлюз отправляет от себя и часто совпадает с другой политикой, чем хост. Пингуйте с хоста в новой подсети, затем запустите приложение, ради которого делалось изменение, и смотрите на счётчики, а не на значок состояния.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showВ туннеле на основе политик счётчики ip xfrm state должны расти в обоих направлениях; плоские счётчики означают, что пакет маршрутизируется, но не выбирается. В WireGuard wg show показывает передачу по сторонам, а рукопожатие с нулём полученных байт указывает на список дальней стороны или её обратный маршрут.
Завершите, записав префикс, селектор или маршрут стороны, решение об обратном пути и запись межсетевого экрана вместе с остальной описью туннеля. Затем перезагрузите один шлюз и проверьте снова: маршрут, добавленный вручную, исчезает, и следующему человеку не придётся обнаруживать это заново.