Вопрос или проблема
Я пытаюсь разработать сеть, чтобы обеспечить доступ к нескольким IoT-устройствам.
Схема сети выглядит так (упрощенная версия для удобства понимания).
- Входящее правило fw на IoT-устройствах — запретить все, поэтому для доступа к ним используется VPN-соединение (wg0), которое они создают с VPN-узлом X.
- Пользователь подключается к любому из VPN-узлов в отдельной сети (wg2).
- Это магистральная сеть между VPN-серверами (wg1), где происходит сквозной трафик.
Работает так, что UserA может общаться с любым IoT-устройством на любом узле (IOT102, 103, 203), кроме того же узла (IOT305). Причина этого в том, что маршрутизация сети оказывается в неправильном порядке!
# ip route show
default via 172.229.0.1 dev enX0 proto dhcp src 172.229.0.103 metric 100
10.105.0.0/19 dev wg1 scope link
10.105.2.0/21 dev wg0 proto kernel scope link src 10.105.2.1
172.119.0.0/24 dev wg1 proto kernel scope link src 172.119.0.3
172.119.0.0/23 dev wg1 scope link
172.227.1.0/25 dev wg2 proto kernel scope link src 172.227.1.1
172.229.0.0/24 dev enX0 proto kernel scope link src 172.229.0.103 metric 100
172.229.0.1 dev enX0 proto dhcp scope link src 172.229.0.103 metric 100
172.229.0.2 dev enX0 proto dhcp scope link src 172.229.0.103 metric 100
После некоторого исследования я понял, что, похоже, это связано с тем, как wg-quick (или что-то еще) настраивает маршруты в разных таблицах маршрутизации, локальная по сравнению с основной таблицей.
Я пытался просто использовать ip r del/ip r add metric, но так как они находятся в разных таблицах (я предполагаю), метрики ничего не меняют.
Конфигурационные файлы:
wg0
################
################
#VPN Node 1:wg0
[Interface]
Address = 10.205.0.1/24
ListenPort = 37820
PrivateKey = ...
SaveConfig = false
################
#IOT102
[Peer]
PublicKey =
Endpoint = <pubip>:port
AllowedIPs = 10.205.0.2/32
PersistentKeepalive = 42
#IOT103
[Peer]
PublicKey =
Endpoint = <pubip>:port
AllowedIPs = 10.205.0.3/32
PersistentKeepalive = 42
################
################
#VPN Node 2:wg0
[Interface]
Address = 10.205.1.1/24
ListenPort = 37820
PrivateKey = ...
SaveConfig = false
################
#IOT203
[Peer]
PublicKey = ...
Endpoint = <pubip>:port
AllowedIPs = 10.205.1.3/32
PersistentKeepalive = 42
...
wg1
#VPN Node 1:wg1
[Interface]
Address = 172.119.0.1/24
ListenPort = 37821
PrivateKey = ...
SaveConfig = false
[Peer]
PublicKey = ...
Endpoint = <server2_pubip>:37821
AllowedIPs = 172.119.0.2/32,10.205.0.0/19,172.227.0.0/23
PersistentKeepalive = 42
...
################
#VPN node 2:wg1
[Interface]
Address = 172.119.0.2/24
ListenPort = 37821
PrivateKey = ...
SaveConfig = false
[Peer]
PublicKey = ...
Endpoint = <server1_pubip>:37821
AllowedIPs = 172.119.0.1/32,10.205.0.0/19,172.227.0.0/23
PersistentKeepalive = 42
...
wg2
#VPN Node 3:wg2
[Interface]
Address = 172.227.1.1/25
ListenPort = 37822
PrivateKey = ...
SaveConfig = false
#UserA
[Peer]
PublicKey = ...
Endpoint = <public_ip>
AllowedIPs = 172.227.1.9/32
PersistentKeepalive = 42
Я думаю, что мог бы перечислить каждую сеть wg0 как AllowedIPs на wg1, но так как мы говорим более чем о 2 серверах, это быстро станет запутанным, так что я могу сделать, чтобы исправить порядок маршрутизации?
Ответ или решение
Для решения возникшей проблемы с маршрутизацией в сети WireGuard с несколькими VPN-подключениями, важно сначала понять, как взаимодействуют различные элементы вашей инфраструктуры. Данная ситуация довольно типична для сложных сетевых конфигураций, где маршрутизация может привести к неожиданным результатам из-за некорректного порядка маршрутов.
Анализ проблемы
Вы описали ситуацию, где определенные устройства IoT могут быть доступны через VPN-соединение (wg0) с помощью узла VPN X, в то время как другие пользователи подключаются к другим VPN-узлам через другую сеть (wg2). Основная проблема заключается в том, что маршруты для узлов на одной и той же VPN-ноде конфликтуют, что мешает пользователям получить доступ к устройствам IoT на этой ноде.
Возможные причины неправильно работающей маршрутизации
-
Порядок маршрутизации и таблиц маршрутизации: WireGuard создает свои маршруты в таблице маршрутизации main по умолчанию. Возможно, некоторые маршруты создаются с неправильными метриками или в неправильных таблицах.
-
Маршруты, связанные с AllowedIPs: Ваши конфигурации Peer специфичны, но, вероятно, перекрытия могут вызывать проблемы. Например, один и тот же подсеть или адрес может быть указан в AllowedIPs для нескольких конфигураций.
-
Проблемы с конфигурацией между сегментами сети: Похоже, сеть wg1 используется как backbone для передачи трафика между VPN-серверами. Возможно, при маршрутизации трафик неправильно передаётся между нодами.
Рекомендации для устранения проблемы
-
Сегментация AllowedIPs: Расширьте или скорректируйте пул адресов AllowedIPs для различных VPN-сетей, чтобы избежать конфликтов. Вы можете добавить подсети явно, но следует предусмотреть иерархическую структуру, чтобы уменьшить переадресации и упрощать управление маршрутами.
-
Используйте отдельные таблицы маршрутизации: Например, можно указать WireGuard использовать конкретные таблицы маршрутизации для разных интерфейсов, что уменьшит вероятность конфликтов.
# Для создания индивидуальной таблицы echo "200 wgtable" >> /etc/iproute2/rt_tables # Пример команды, чтобы настроить правило ip rule add from 172.227.1.0/25 table wgtable ip route add default via 172.227.1.1 dev wg2 table wgtable -
Уточнение маршрутов вручную: Некоторые из маршрутов могут быть добавлены вручную для обеспечения их коректной работы. Используйте
ip route addиip route delдля изменения маршрутов, если автоматическая конфигурация не работает. -
Проверка конфигурации VPN-нод: Убедитесь, что конфигурации всех участков сети корректны и не дублируют адресные пространства.
-
Журналирование и отладка: Используйте команды
ip route show,ip rule showиwg showдля проверки установленных маршрутов и их диагностики.
Заключение
Для решения возникших проблем необходимо тщательное планирование и настройка маршрутизации внутри всех участвующих сегментов сети. Используйте сегментацию и нестандартные таблицы маршрутизации для улучшения управляемости и предсказуемости маршрутов. Эти шаги помогут улучшить маршрутизацию и обеспечить доступность всех нужных устройств IoT пользователям в вашей сети.