Wireguard mesh между общедоступной и локальной сетью

Если каждый из узлов 4,5,6 находится за своим собственным CGNAT, то, как обычно, они не могут обеспечить правильную связь между собой. Им приходится полагаться на узлы 1,2,3 для ретрансляции трафика.Таким образом, этим узлам CGNAT потребуются дополнительные AllowedIPs для некоторых общедоступных узлов в их настройках, чтобы разрешить другим узлам CGNAT через общедоступные узлы, а общедоступные узлы должны быть установлены в качестве маршрутизаторов.

Пример для узла 4, который, как предполагается, имеет IP-адрес 10.1.0.51/32 и использует узел 2 в качестве узла маршрутизации:

[Interface]
Address = 10.1.0.51/32
PrivateKey =

[Peer] # example public node 1
PublicKey =
AllowedIPs = 10.1.0.1/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # example public node 2
PublicKey =
AllowedIPs = 10.1.0.2/32,10.1.0.52/32,10.1.0.53/32
Endpoint = Y.Y.Y.Y:5888
PersistentKeepalive = 25

[Peer] # example public node 3
PublicKey =
AllowedIPs = 10.1.0.3/32
Endpoint = Z.Z.Z.Z:5888
PersistentKeepalive = 25

Ожидается, что IP-адреса других узлов CGNAT будут маршрутизироваться через узел 2 и должны быть добавлены к этому узлу Разрешенные IP-адреса. Это также должно автоматически добавить их в таблицу маршрутизации.

Узел 2 теперь также должен быть маршрутизатором, по крайней мере, на его интерфейсе WireGuard, который будет одновременно входным и выходным. В Linux это можно сделать, например, с помощью (при условии, что интерфейс wg0):

sysctl -w net.ipv4.conf.wg0.forwarding=1

Правила его брандмауэра также должны разрешать переадресацию трафика на wg0.

Обратите внимание, что нет необходимости определять другие одноранговые узлы CGNAT на узлах CGNAT, и если они определены, они не должны иметь IP-адреса других узлов CGNAT в AllowedIPs:

• они не будут доступны напрямую и,
• если тот же адрес будет установлен в последующих AllowedIPs, он будет удален из каждого предыдущего определения, и он будет иметь только последний определенный одноранговый узел. С маршрутизацией криптоключа IP-адрес(а) <=> одноранговый узел.

Узлы 5 и 6 должны иметь совместимую конфигурацию (также использовать узел 2 в качестве маршрутизатора).Вместо этого вы также можете представить:

• разделенные роли, где 4 и 5 маршрутизируются узлом 2, 4 и 6 — узлом 3, а 5 и 6 — узлом 1,
• или иметь несколько IP-адресов в разных IP-блоках, чтобы каждый Блок может быть направлен через другой узел маршрутизации
• , либо с использованием луковой маршрутизации с трафиком WireGuard внутри трафика WireGuard, чтобы узлы маршрутизации не могли декодировать трафик, не предназначенный для них
• , либо с использованием нескольких независимых интерфейсов WireGuard (которые не не подлежат взаимодействию криптоключей между собой, а только с таблицей маршрутизации),
• или некоторой комбинации предыдущих вариантов,

[...]

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

В заключение, вот блог, в котором BGP (этот инструмент был бы отсутствующим) используется вместе с WireGuard, с несколькими адресами, а также с одним интерфейсом на одноранговый узел, и только этот одноранговый узел определен для обхода маршрутизации криптоключа. . Вероятно, из этого можно чему-то научиться, но тема слишком сложна для меня.

VPN на основе маршрутов в Linux с WireGuard