Регистрация Войти
Рейтинг:2
avatar Server

site2site wireguard с докером: проблемы с маршрутизацией

флаг fr
nick2k3

Отказ от ответственности: репост из stackoverflow: https://stackoverflow.com/questions/67917278/site2site-wireguard-with-docker-routing-problems

Я пытаюсь, чтобы два контейнера, работающие на двух RPI, действовали как межсайтовая VPN между сетью 1 и сетью 2.

С приведенной ниже настройкой я могу пинговать изнутри контейнера сеть друг друга:

  • из док-контейнера 1 я могу пропинговать адрес 192.168.1.1
  • из контейнера докеров 2 я могу пропинговать адрес 192.168.10.1

Но если я попытаюсь пропинговать 192.168.1.1 с хоста System1 (192.168.10.100), у меня возникнут ошибки (см. изображение ниже, чтобы визуализировать то, что я пытаюсь сделать).

Я понимаю, что мне нужно добавить статический маршрут на хост system1 (192.168.10.100), чтобы направить трафик для 192.168.1.0/24 через контейнер wireguard (172.17.0.5), поэтому я запускаю:

$i p добавить маршрут 192.168.1.0/24 через 172.17.0.5
$ IP-маршрут
по умолчанию через 192.168.10.1 dev eth0 proto dhcp src 192.168.10.100 метрика 100 
172.17.0.0/16 dev docker0 ссылка на область ядра proto src 172.17.0.1 
172.18.0.0/16 dev br-e19a4f1b7646 ссылка на область действия ядра src 172.18.0.1 linkdown 
172.19.0.0/16 dev br-19684dacea29 ссылка на область действия ядра src 172.19.0.1 
172.20.0.0/16 dev br-446863cf7cef ссылка на область ядра прото src 172.20.0.1 
172.21.0.0/16 dev br-6800ed9b4dd6 ссылка на область ядра прото src 172.21.0.1 linkdown 
172.22.0.0/16 dev br-8f8f439a7a28 ссылка на область действия ядра src 172.22.0.1 linkdown 
192.168.1.0/24 через 172.17.0.5 dev docker0 
192.168.10.0/24 dev eth0 ссылка на область действия ядра proto src 192.168.10.100 
192.168.10.1 dev eth0 proto dhcp scope link src 192.168.10.100 метрика 100

но пинг до 192.168.1.1 все равно не проходит.

запустив tcpdump на контейнере 2, я вижу, что некоторые пакеты действительно достигают контейнера:

root@936de7c0d7eb:/# tcpdump -n -i любой
tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
прослушивание на любом, ссылка типа LINUX_SLL (линукс сваренный), размер захвата 262144 байт
10:11:19.885845 IP [publicIPsystem1].56200 > 172.17.0.6.56100: UDP, длина 128
10:11:30.440764 IP 172.17.0.6.56100 > [publicIPsystem1].56200: UDP, длина 32
10:11:35.480625 ARP, Запросите кто имеет 172.17.0.1 сообщите 172.17.0.6, длина 28
10:11:35.480755 ARP, ответ 172.17.0.1 is-at 02:42:24:e5:ac:38, длина 28

поэтому я думаю, что это не проблема маршрутизации в системе 1.

Может кто подскажет как дальше диагностировать?

РЕДАКТИРОВАТЬ 1:
Я сделал следующий тест:

  1. запустите «tcpdump -ni any» на контейнере 2
  2. отправил пинг из системы 1 (из хост-системы) 'ping -c 1 192.168.1.1 .
    В контейнере 2 tcpdump записывает следующее:
    tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
    прослушивание на любом, ссылка типа LINUX_SLL (линукс сваренный), размер захвата 262144 байт
    15:04:47.495066 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, длина 128
    15:04:58.120761 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP, длина 32
  1. отправил пинг из контейнера (внутри контейнера) 'ping -c 1 192.168.1.1 .
    В контейнере 2 tcpdump записывает следующее:
# tcpdump -ni любой
tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
прослушивание на любом, ссылка типа LINUX_SLL (линукс сваренный), размер захвата 262144 байт
15:05:48.120717 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, длина 128
15:05:48.120871 IP 10.13.18.2 > 192.168.1.1: эхо-запрос ICMP, идентификатор 747, последовательность 1, длина 64
15:05:48.120963 IP 172.17.0.3 > 192.168.1.1: эхо-запрос ICMP, идентификатор 747, последовательность 1, длина 64
15:05:48.121955 IP 192.168.1.1 > 172.17.0.3: эхо-ответ ICMP, идентификатор 747, последовательность 1, длина 64
15:05:48.122054 IP 192.168.1.1 > 10.13.18.2: эхо-ответ ICMP, идентификатор 747, последовательность 1, длина 64
15:05:48.122246 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP, длина 128
15:05:53.160617 ARP, Запросите, у кого есть 172.17.0.1, сообщите 172.17.0.3, длина 28
15:05:53.160636 ARP, Запросите, у кого есть 172.17.0.3, сообщите 172.17.0.1, длина 28
15:05:53.160745 ARP, ответ 172.17.0.3 is-at 02:42:ac:11:00:03, длина 28
15:05:53.160738 ARP, ответ 172.17.0.1 is-at 02:42:24:e5:ac:38, длина 28
15:05:58.672032 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP, длина 32

Итак, кажется, что пакеты обрабатываются иначе, чем контейнер 2, в зависимости от чего-то, что мне сейчас не хватает. может проблема в iptables?

введите описание изображения здесь

Сайт 1 Сайт 2
Диапазон IP-адресов сети 1 192.168.10.0/24 192.168.1.0/24
адрес хост-системы 192.168.10.100 192.168.1.100
мост докер0 диапазон 172.17.0.0/16 172.17.0.0/16
адрес контейнера 172.17.0.5 172.17.0.6

Система 1 — WG0.conf

[Интерфейс]
Адрес = 10.13.18.2
Приватный ключ = *приватный ключ*
ListenPort = 56200
PostUp = iptables -A FORWARD -i %i -j ПРИНЯТЬ; iptables -A FORWARD -o %i -j ПРИНЯТЬ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ПРИНЯТЬ; iptables -D FORWARD -o %i -j ПРИНЯТЬ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Вглядеться]
ПубличныйКлюч = *общедоступный*
Конечная точка = *системный2адрес*:56100
Разрешенные IP-адреса = 10.13.18.1/32, 192.168.1.0/24

Система 2 — WG0.conf

[Интерфейс]
Адрес = 10.13.18.1
ListenPort = 56100
Приватный ключ = *приватный ключ*
PostUp = iptables -A FORWARD -i %i -j ПРИНЯТЬ; iptables -A FORWARD -o %i -j ПРИНЯТЬ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ПРИНЯТЬ; iptables -D FORWARD -o %i -j ПРИНЯТЬ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Вглядеться]
# peer_casaleuven
ПубличныйКлюч = *общедоступный*
Разрешенные IP-адреса = 10.13.18.2/32, 192.168.10.0/24
Конечная точка = *системный1адрес*:56200
1722
1 + 7
jabbson avatar
флаг sb
jabbson
Когда вы пингуете 192.168.1.1 из системы 1 — видите ли вы пакеты, прибывающие в контейнер 1 и покидающие его, которые вы можете соотнести с входящими пакетами, которые вы видите в контейнере 2 (потому что то, что вы видите, может быть просто поддержкой активности или чем-то еще)? Есть ли в WireGuard журналы, которые вы можете посмотреть? Как выглядит таблица маршрутизации в контейнере 1?
0
Ответить
флаг fr
nick2k3
да, я попытался запустить «tcpdump -ni any» на обоих контейнерах одновременно, подождал пару секунд, чтобы убедиться, что другие пакеты не были записаны. Затем я запускаю «ping -c 1 192.168.1.1», чтобы отправить только один ping из системы 1, и я вижу, что пакеты проходят через оба tcpdumps.
0
Ответить
флаг fr
nick2k3
добавлен еще один тест в разделе Edit 1
0
Ответить
A.B avatar
флаг cl
A.B
примечание: я надеюсь, что eth0 контейнера не имеет отношения, потому что нигде не должно быть NAT. Поэтому я не понимаю, почему существует это правило: `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` внутри `PostUp`
0
Ответить
флаг fr
nick2k3
правило iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE было поставлено по умолчанию linuxserver/wireguard в начальной конфигурации. Если я удалю их как из PostUp, так и из PostDown в обоих контейнерах, я больше не смогу ничего пинговать.
0
Ответить
A.B avatar
флаг cl
A.B
Хорошо. В любом случае это ничего не меняет в ответе, который я написал ниже. Вы пробовали?
0
Ответить
флаг fr
nick2k3
Да, пробовал, работает!!! Спасибо огромное! Мне интересно, почему этот принцип настолько фундаментален, чтобы заставить его работать. Если я запускаю iptables --list, я не вижу ни одной таблицы NAT.
0
Ответить
Рейтинг:1
A.B avatar Server
флаг cl
A.B

Это похоже на проблему маршрутизации.

192.168.1.0/24 через 172.17.0.5 dev docker0

Для этого маршрута не указан предпочтительный исходный адрес. Таким образом, естественно, хост выберет ближайший совпадающий адрес: 172.17.0.1, так как это основной адрес на докер0. 172.17.0.1 отсутствует в списке разрешенных IP-адресов WireGuard (да и не должно быть), поэтому будет отклонен WireGuard. Если бы он не был отклонен, в любом случае возникла бы проблема с маршрутизацией на одноранговом узле из-за того, что две отдельные локальные сети используют один и тот же блок IP-адресов.

Попробуй это

  • Система 1

    IP-маршрут заменить 192.168.1.0/24 через 172.17.0.5 dev docker0 src 192.168.10.100

  • Система 2

    IP-маршрут заменить 192.168.10.0/24 через 172.17.0.6 dev docker0 src 192.168.1.100

Обратите внимание, что до этой настройки это не должно было влиять на остальные локальные сети, а только на две хост-системы Docker.

0 + 1
A.B avatar
флаг cl
A.B
Объясняя, что я написал в ответе: выбран неверный исходный адрес. Этот маршрут имеет подсказку src для использования правильного исходного адреса из локальной сети.
1
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.