Назад | Перейти на главную страницу

openvpn (tun0 + bridged): мостовая связь -> tun0 работает, но не в обратном направлении

Моя сеть состоит из следующего:

Я хочу добраться до C от A. Вот что происходит:

Возникает вопрос, почему? Таблица маршрутов:

192.15.206.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
9.168.58.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.15.206.0    192.15.206.2    255.255.255.0   UG    0      0        0 tun0
192.168.206.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 br0
0.0.0.0         9.168.58.254    0.0.0.0         UG    0      0        0 eth0

конфигурация моста:

bridge name     bridge id               STP enabled     interfaces
br0             8000.005056a67d62       no              eth1
                                                        vnet0

Команда:

cat /proc/sys/net/ipv4/ip_forward

возвращает 1

С tcpdump -i tun0, если я запускаю ping 192.168.206.1 на хосте A:

14:33:23.927126 IP 192.15.206.6 > 192.168.206.1: ICMP echo request, id 768, seq 513, length 40
14:33:23.927191 IP 192.168.206.1 > 192.15.206.6: ICMP echo reply, id 768, seq 513, length 40

повтор был отправлен обратно. Но если я запускаю ping 192.168.206.2 на хосте A, воспроизведение не отправляется обратно.

14:36:33.262959 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1281, length 40
14:36:38.749631 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1537, length 40

Похоже, что пакеты приходят от A к B с устройством tun0, но они не пересылаются на br0, который должен затем отправить пакет на vnet0, который соединяет хост C.

Проблема связана с iptables, действительно, остановив службу iptables, я могу пропинговать C от A. Я безуспешно пробовал эти правила:

-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

Любые идеи ?

Это может быть

  1. проблема брандмауэра на B (счетчик интуитивно понятный Netfilter также блокирует пакеты через мост)
  2. проблема брандмауэра на C (маловероятно)
  3. проблема маршрутизации на C

Так что проверьте iptables -L -nv на B для пересылки и ip route на С.

Редактировать 1

Брандмауэр на B можно настроить так, чтобы пропускать эти пакеты, например,

iptables -I FORWARD 2 -m physdev --physdev-in vnet0 -j ACCEPT
iptables -I FORWARD 2 -m physdev --physdev-out vnet0 -j ACCEPT

Конечно, вы можете использовать вместо (или в дополнение) адреса источника и назначения.

Редактировать 2

Подобно:

iptables -I FORWARD 2 -s 192.15.206.2 -d 192.168.206.2 -j ACCEPT
iptables -I FORWARD 2 -d 192.15.206.2 -s 192.168.206.2 -j ACCEPT

Проблема, вероятно, больше не актуальна для вас, но я все же хотел оставить ее здесь, так как у меня была такая же проблема.

Выполните следующую команду:

#brctl showstp br0
.... other interfaces ....
tun0 (8)
 port id                8008                    state                disabled
 designated root        8000.0cc47a95b66f       path cost                100
 designated bridge      8000.0cc47a95b66f       message age timer          0.00
 designated port        8008                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

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

ip link set dev tun0 up