☰

Как настроить Wireguard для многосайтовой сети K8s?

tag-icon • tag-icon vpn kubernetes wireguard k3s
Как настроить Wireguard для многосайтовой сети K8s?

Я пытался настроить Wireguard для многосайтового кластера K3s, проблема с маршрутизацией. Есть как минимум 4 узла, 2 в одном месте + 1 в другом месте и + 1 в другом месте.

Предположения:

  • Сеть 10.50.0.0/16 предназначена для физических узлов.
  • Сеть 10.42.0.0/16 предназначена для модулей
  • Сеть 10.43.0.0/16 предназначена для служб
  • Каждый физический узел может создать Pod, которому назначен уникальный IP-адрес в диапазоне 10.42.0.0/16.
  • Каждый модуль на каждом физическом узле должен иметь возможность отправлять друг другу пинги.

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

Примеры конфигураций из двух узлов:

10.50.54.100:

[Interface]
# primary-1
Address = 10.50.54.100/24
PrivateKey = pr111111111111111111111111111111111111111111
ListenPort = 443
MTU = 1500
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = echo 1 > /proc/sys/net/ipv4/ip_forward
PostUp = ufw allow 443/udp || true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = sysctl -w -q net.ipv4.ip_forward=0
PostDown = echo 0 > /proc/sys/net/ipv4/ip_forward

[Peer]
# infra-1
PublicKey = pub11111111111111111111111111111111111111111
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = xxxxxxxxxx:443

[Peer]
# compute-2
PublicKey = pub2222222222222222222222222222222222222222
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = yyyyyyyyyy:443

[Peer]
# storage-1
PublicKey = pub3333333333333333333333333333333333333333
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = zzzzzzzzzzz:443

10.50.54.2:

[Interface]
# infra-1
Address = 10.50.54.2/24
PrivateKey = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
ListenPort = 443
MTU = 1500
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = echo 1 > /proc/sys/net/ipv4/ip_forward
PostUp = ufw allow 51820/udp || true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = sysctl -w -q net.ipv4.ip_forward=0
PostDown = echo 0 > /proc/sys/net/ipv4/ip_forward

[Peer]
# primary-1
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = xxxxxxxxxxxx:443

[Peer]
# compute-2
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = yyyyyyyyyyy:443

[Peer]
# storage-1
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.50.54.0/16, 10.42.0.0/16, 10.43.0.0/16
PersistentKeepalive = 15
Endpoint = zzzzzzzzzzzz:443

Есть ли у вас какие-либо соображения? Как это должно быть спроектировано с Wireguard? Почему эта конфигурация не работает?

Спасибо!

решение1

(Извините, это, вероятно, должен быть комментарий, поскольку я не уверен на 100%, что это правильно, но у меня пока недостаточно репутации на этом сайте, чтобы использовать комментарии.)

Я считаю, что AllowedIPsfor each [Peer]должны быть уникальными (т. е. неперекрывающимися диапазонами), потому что именно так WireGuard узнает, какому пиру направить данный исходящий пакет. Если это так, вам нужно будет настроить отдельные диапазоны IP-адресов (для pod'ов и сервисов — узлы не должны иметь значения) для каждого сайта.

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

Я не слишком хорошо знаком с k3s, поэтому не уверен, как работает его многосайтовый кластер — это по сути просто несколько отдельных кластеров Kubernetes, которые управляются централизованно?

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