☰

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

tag-icon • tag-icon networking vpn wireguard
Сетка Wireguard между публичной и локальной сетью

В настоящее время у меня такая конфигурация сетки: введите описание изображения здесь

С аналогичной конфигурацией Wireguard на каждом узле:

[Interface]
Address = 10.1.0.1/32
PrivateKey =
ListenPort = 5888

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

[Peer] # example node behind cgnat [4-6]
PublicKey = 
AllowedIPs = 10.1.0.51/32
PersistentKeepalive = 25

Это позволяет мне пинговать все зеленые линии на графике выше. Но я не могу пинговать ни одну из красных между узлами в CGNAT. Как мне это сделать?

ПОПЫТКА 1 (без Node3)

пример CGNAT ( Node4)

[Interface] # NODE 4
Address = 10.3.0.3/32
PrivateKey = 

[Peer] # NODE 1, 5 & 6
PublicKey = 
AllowedIPs = 10.3.0.1/32,10.3.0.51/32,10.3.0.52/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # NODE 2
PublicKey = 
AllowedIPs = 10.3.0.2/32
Endpoint = X.X.X.Y:5888
PersistentKeepalive = 25

пример публичной конечной точки ( Node1)

[Interface] # NODE 1
Address = 10.3.0.1/32
PrivateKey = 
ListenPort = 5888

[Peer] # NODE 5
PublicKey = 
AllowedIPs = 10.3.0.51/32
PersistentKeepalive = 25

[Peer] # NODE 6
PublicKey = 
AllowedIPs = 10.3.0.52/32
PersistentKeepalive = 25

[Peer] # NODE 2
PublicKey = 
AllowedIPs = 10.3.0.2/32
Endpoint = X.X.X.Y:5888
PersistentKeepalive = 25

[Peer] # NODE 4
PublicKey = 
AllowedIPs = 10.3.0.3/32
PersistentKeepalive = 25

Я также участвовал в Node1:

$ sysctl -w net.ipv4.ip_forward=1
$ sysctl -w net.ipv4.conf.maxnet.forwarding=1

где maxnetмое имя в рабочей группе.

решение1

Если узлы 4,5,6 находятся каждый за своимCGNAT, то как обычно, они не могут сделать надлежащую коммуникацию между собой. Они должны полагаться на узлы 1,2,3 для ретрансляции трафика. Поэтому эти узлы CGNAT потребуют дополнительныхРазрешенные IP-адресадля некоторых публичных одноранговых узлов в их настройках необходимо разрешить другим узлам 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-адресам этого однорангового узла.Разрешенные IP-адреса. Это также должно автоматически добавить их в таблицу маршрутизации.

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

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

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

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

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

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

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

[...]

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

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

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

Связанный контент