LINUX.ORG.RU
решено Форум — Admin  

OSPF Hello не проходят через GRE/IPSec VPN туннель в одну сторону

 , , ,


1

2

Приветствую.
Имеется следующий конфиг: несколько серверов, объединенных в «локальную сеть» путем соединения каждого с каждым используя GRE туннели (vpntapX), зашифрованные с помощью IPSec, на каждом сервере туннели объединены в мост (vpnbr0), таким образом все сервера как будто включены в один коммутатор. Если у кого-то есть лучший вариант реализации full-mesh сети поверх интернет - с радостью выслушаю, но текущее решение работало прилично до настоящего момент когда понадобилось добавить 4-й сервер.
Каждый сервер отвечает за свою подсеть в которой «живут» виртуалки, для маршрутизации используется Quagga (OSPF, Zebra) 3 старых сервера на Debian 7 работают нормально, OSPF корректно ходит по туннелям, а вот с новым на Debian 8 проблема, мультикаст нормально проходит через туннели, а OSPF Hello - нет.

Версии ОС и ПО
Старые сервера

  • Debian 7 (Proxmox 3) Linux pve01 2.6.32-30-pve #1 SMP Wed Jun 25 05:54:15 CEST 2014 x86_64 GNU/Linux
  • quagga 0.99.22.4-1+wheezy1

Новый сервер

  • Debian 8 (Proxmox 4) Linux pve03 4.4.35-2-pve #1 SMP Mon Jan 9 10:21:44 CET 2017 x86_64 GNU/Linux
  • quagga 0.99.23.1-1+deb8u3

Настройка сети
Хорошие IP - где все работает

  • 172.20.128.1
  • 172.20.128.2
  • 172.20.128.254

Проблемный IP - где не работает OSPF

  • 172.20.128.3

VPN туннель: 

ip address show vpntap1
8: vpntap1@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast master vpnbr0 state UNKNOWN group default qlen 1000
    link/ether 4a:6c:b9:b6:47:06 brd ff:ff:ff:ff:ff:ff
Мост объединяющий туннели: 
brctl show vpnbr0
bridge name     bridge id               STP enabled     interfaces
vpnbr0          8000.fa8d12bcc999       no              vpntap1
                                                        vpntap2
                                                        vpntap3
ip address show vpnbr0
131: vpnbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN
    link/ether fa:8d:12:bc:c9:99 brd ff:ff:ff:ff:ff:ff
    inet 172.20.128.1/24 brd 172.20.128.255 scope global vpnbr0
    inet6 fe80::f88d:12ff:febc:c999/64 scope link
       valid_lft forever preferred_lft forever
Пример конфига: 
auto vpntap1
iface vpntap1 inet manual
        pre-up ip link add $IFACE type gretap local A.B.C.D  remote X.Z.Y.F key 123456
        post-up ip link set $IFACE mtu 1400 || true
        post-down ip link delete $IFACE
auto vpntap2
iface vpntap2 inet manual
        pre-up ip link add $IFACE type gretap local A.B.C.D remote Q.W.E.R key 123456
        post-up ip link set $IFACE mtu 1400 || true
        post-down ip link delete $IFACE
auto vpntap3
iface vpntap3 inet manual
        pre-up ip link add $IFACE type gretap local A.B.C.D remote A.B.Z.Y key 123456
        post-up ip link set $IFACE mtu 1400 || true
        post-down ip link delete $IFACE

auto vpnbr0
iface vpnbr0 inet static
        address  172.20.128.1
        netmask  255.255.255.0
        bridge_ports regex vpntap[1-9].*
# We don't want disabled links so STP off
        bridge_stp off
        bridge_fd 2
        bridge_maxwait 5
# Do not forward packets over "ports" we don't want broascast storms
        pre-up ebtables -A FORWARD --logical-in $IFACE --j DROP
        post-down ebtables -D FORWARD --logical-in $IFACE --j DROP
# Route all multicast to this interface
        post-up  ip route add 224.0.0.0/4 dev $IFACE
        pre-down ip route del 224.0.0.0/4 dev $IFACE
# Clamp MSS to PMTU
        post-up  iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu -m comment --comment "$IFACE"
        pre-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu -m comment --comment "$IFACE"
# Disable multicast snooping
        post-up echo 0 > /sys/devices/virtual/net/vpnbr0/bridge/multicast_snooping

Маршруты
На 172.20.128.1 видим сети добавленные Quagga. 

ip ro
172.20.252.2 via 172.20.128.2 dev vpnbr0  proto zebra  metric 20
172.20.252.254 via 172.20.128.254 dev vpnbr0  proto zebra  metric 20
A.B.C.F/27 dev vmbr0  proto kernel  scope link  src A.B.C.D
172.20.128.0/24 dev vpnbr0  proto kernel  scope link  src 172.20.128.1
172.21.254.0/24 via 172.20.128.254 dev vpnbr0  proto zebra  metric 20
10.17.1.0/24 dev tun0  proto kernel  scope link  src 10.17.1.1
172.21.2.0/24 via 172.20.128.2 dev vpnbr0  proto zebra  metric 20
172.21.1.0/24 dev vmbr1  proto kernel  scope link  src 172.21.1.1
224.0.0.0/4 dev vpnbr0  scope link
default via A.B.C.Z dev vmbr0

На 172.20.128.3 только локальные маршруты. 

ip ro
default via Q.W.E.F dev vmbr0
Q.W.E.Z/26 dev vmbr0  proto kernel  scope link  src Q.W.E.D
172.20.128.0/24 dev vpnbr0  proto kernel  scope link  src 172.20.128.3
172.21.3.0/24 dev vmbr1  proto kernel  scope link  src 172.21.3.1
224.0.0.0/4 dev vpnbr0  scope link

Диагностическая информация, ospf, tcpdump
Как видно рабочие сервера вообще не видят новый сервер, потому что OSPF Hello не доходит до них. 

show ip ospf neighbor
    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.20.252.2      1 Full/DR           36.509s 172.20.128.2    vpnbr0:172.20.128.1      0     0     0
172.20.252.254    1 Full/Backup       35.370s 172.20.128.254  vpnbr0:172.20.128.1      0     0     0

На 172.20.128.1 видны OSPF Hello всех серверов кроме нового. 

tcpdump -ni vpnbr0 proto ospf                    
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpnbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:45:42.335682 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:43.468166 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:43.469742 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:52.336008 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:53.468557 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:53.470197 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52

Новый сервер видит всех соседей, но висит в Init, видимо потому, что его никто не видит. 

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.20.252.1      1 Init/DROther      31.781s 172.20.128.1    vpnbr0:172.20.128.3      0     0     0
172.20.252.2      1 Init/DROther      31.782s 172.20.128.2    vpnbr0:172.20.128.3      0     0     0
172.20.252.254    1 Init/DROther      30.647s 172.20.128.254  vpnbr0:172.20.128.3      0     0     0

На проблемный 172.20.128.3 доходят все OSPF Hello 

tcpdump  -ni vpnbr0 proto ospf                                           
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on vpnbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:48:02.342019 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:03.473027 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:03.473527 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:05.589296 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
18:48:12.342449 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:13.473298 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:13.473852 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:15.589541 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56

Погрузимся глубже, изучим туннель между 172.20.128.3 и 172.20.128.1
Смотрим на 172.20.128.1, наблюдаем отсутствие OSPF Hello от 172.20.128.3 

tcpdump -ni vpntap3 proto ospf                    
tcpdump: WARNING: vpntap3: no IPv4 address assigned                        
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpntap3, link-type EN10MB (Ethernet), capture size 65535 bytes
19:09:23.511620 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:33.512082 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:43.512206 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:53.512758 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52

Смотрим на 172.20.128.3, наблюдаем OSPF Hello от 172.20.128.1 и 172.20.128.3 

tcpdump -ni vpntap3 proto ospf                                           
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode  
listening on vpntap3, link-type EN10MB (Ethernet), capture size 262144 bytes
19:09:33.512349 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:35.675136 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:09:43.512495 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:45.675931 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:09:53.513071 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:55.676709 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:10:03.513473 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:10:05.677474 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56

Таким образом, OSPF Hello проходит через туннель только в одну сторону о.О и понять почему это происходит я никак не могу.

Просто мультикаст ходит через туннель нормально
На 172.20.128.1 

ssmpingd
received request from 172.20.128.3
received request from 172.20.128.3
...
На 172.20.128.3 
# ssmping 172.20.128.1
ssmping joined (S,G) = (172.20.128.1,232.43.211.234)
pinging S from 172.20.128.3
multicast from 172.20.128.1, seq=1 dist=0 time=1.049 ms
  unicast from 172.20.128.1, seq=1 dist=0 time=2.733 ms
  unicast from 172.20.128.1, seq=2 dist=0 time=1.208 ms
multicast from 172.20.128.1, seq=2 dist=0 time=1.217 ms
...

На 172.20.128.1 

omping 172.20.128.1 172.20.128.3
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : joined (S,G) = (*, 232.43.211.234), pinging
172.20.128.3 :   unicast, seq=1, size=69 bytes, dist=0, time=0.744ms
172.20.128.3 : multicast, seq=1, size=69 bytes, dist=0, time=0.749ms
172.20.128.3 :   unicast, seq=2, size=69 bytes, dist=0, time=0.586ms
172.20.128.3 : multicast, seq=2, size=69 bytes, dist=0, time=0.593ms
172.20.128.3 :   unicast, seq=3, size=69 bytes, dist=0, time=0.564ms
172.20.128.3 : multicast, seq=3, size=69 bytes, dist=0, time=0.570ms
172.20.128.3 :   unicast, seq=4, size=69 bytes, dist=0, time=1.097ms
172.20.128.3 : multicast, seq=4, size=69 bytes, dist=0, time=1.115ms
172.20.128.3 :   unicast, seq=5, size=69 bytes, dist=0, time=0.980ms
172.20.128.3 : multicast, seq=5, size=69 bytes, dist=0, time=0.984ms
172.20.128.3 : waiting for response msg
172.20.128.3 : server told us to stop

172.20.128.3 :   unicast, xmt/rcv/%loss = 5/5/0%, min/avg/max/std-dev = 0.564/0.794/1.097/0.237
172.20.128.3 : multicast, xmt/rcv/%loss = 5/5/0%, min/avg/max/std-dev = 0.570/0.802/1.115/0.241

На 172.20.128.3 

omping 172.20.128.1 172.20.128.3
172.20.128.1 : waiting for response msg
172.20.128.1 : joined (S,G) = (*, 232.43.211.234), pinging
172.20.128.1 :   unicast, seq=1, size=69 bytes, dist=0, time=0.656ms
172.20.128.1 : multicast, seq=1, size=69 bytes, dist=0, time=0.658ms
172.20.128.1 :   unicast, seq=2, size=69 bytes, dist=0, time=0.695ms
172.20.128.1 : multicast, seq=2, size=69 bytes, dist=0, time=0.704ms
172.20.128.1 :   unicast, seq=3, size=69 bytes, dist=0, time=0.817ms
172.20.128.1 : multicast, seq=3, size=69 bytes, dist=0, time=0.827ms
172.20.128.1 :   unicast, seq=4, size=69 bytes, dist=0, time=1.127ms
172.20.128.1 : multicast, seq=4, size=69 bytes, dist=0, time=1.136ms
172.20.128.1 :   unicast, seq=5, size=69 bytes, dist=0, time=0.962ms
172.20.128.1 : multicast, seq=5, size=69 bytes, dist=0, time=0.968ms
172.20.128.1 :   unicast, seq=6, size=69 bytes, dist=0, time=1.074ms
172.20.128.1 : multicast, seq=6, size=69 bytes, dist=0, time=1.083ms
^C
172.20.128.1 :   unicast, xmt/rcv/%loss = 6/6/0%, min/avg/max/std-dev = 0.656/0.888/1.127/0.197
172.20.128.1 : multicast, xmt/rcv/%loss = 6/6/0%, min/avg/max/std-dev = 0.658/0.896/1.136/0.198
Если поменять местами клиент/сервер для ssmping или omping то ничего не меняется, все пингуется успешно.

Это из-за ttl. Квагга формирует пакеты с ttl=1, что, в принципе, было бы правильно, если бы не gre. В случае gre в Linux происходит лишнее вычитание, и пакет пропадает. Надо в тунеле ttl переопределить, чтобы дефолт Квагги не использовался.

А вот почему на старых работает... Может, там кто-то это уже корректировал ?

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)

ip tunnel change vpntap3 ttl 2
Или больше, чем 2...

AS ★★★★★
()
Ответ на: комментарий от AS

Вариант с ttl надо проработать, но проблема в том что это не просто GRE туннель, это GRETAP туннель http://baturin.org/docs/iproute2/#Create a gretap (ethernet over GRE) device Он инкапсулирует Ethernet фреймы, а не IP пакеты. Соответственно вариант ip tunnel change vpntap3 ttl 2 не работает, ошибка: get tunnel "vpntap3" failed: Operation not supported

Hatifnatt
() автор топика
Ответ на: комментарий от AS

На старых никто не корректировал там TTL 1 и все работает 

20:49:07.646502 IP (tos 0xc0, ttl 1, id 34282, offset 0, flags [none], proto OSPF (89), length 92)
    172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 56
        Router-ID 172.20.252.1, Backbone Area, Authentication Type: MD5 (2)
        Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x588b8813
        Options [External]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 1
          Designated Router 172.20.128.254, Backup Designated Router 172.20.128.2
          Neighbor List:
            172.20.252.2
            172.20.252.3
            172.20.252.254
20:49:08.916070 IP (tos 0xc0, ttl 5, id 34509, offset 0, flags [none], proto OSPF (89), length 92)
    172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
        Router-ID 172.20.252.3, Backbone Area, Authentication Type: MD5 (2)
        Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x588b8814
        Options [External]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 1
          Designated Router 172.20.128.254, Backup Designated Router 172.20.128.2
          Neighbor List:
            172.20.252.1
            172.20.252.2
            172.20.252.254
На новом добавил iptables -t mangle -A OUTPUT -d 224.0.0.5 -j TTL --ttl-set 5 это помогло, варианты с увеличением до 2-4 не помогали, трафик так и не появлялся на другом конце.

Правда до конца пока что не работает OSPF, теперь лог заполнен такими сообщениями 

2017/01/27 20:58:43 OSPF: Packet[DD] [Slave]: Neighbor 172.20.252.254 packet duplicated.
2017/01/27 20:58:43 OSPF: Packet[DD]: Neighbor 172.20.252.2: Initial DBD from Slave, ignoring.
2017/01/27 20:58:48 OSPF: Packet[DD] [Slave]: Neighbor 172.20.252.254 packet duplicated.
2017/01/27 20:58:48 OSPF: Packet[DD]: Neighbor 172.20.252.2: Initial DBD from Slave, ignoring.
2017/01/27 20:58:53 OSPF: Packet[DD] [Slave]: Neighbor 172.20.252.254 packet duplicated.
2017/01/27 20:58:53 OSPF: Packet[DD]: Neighbor 172.20.252.2: Initial DBD from Slave, ignoring.

Костыль с iptables отчасти можно считать рабочим, но вообще хотелось бы разобраться лучше, что за фигня такая.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

между ядрами 2.6 и 4.4 было огромное изменение сетевого стека. sysctl значения по-умолчанию менялись. Мост несколько раз ломали и чинили.

ttl для ospf должен быть 1.

Как я понимаю, tcpdump-ом исходящие пакеты в туннель видны? А в мосте и его слейвах ?

multicast_snooping на .3 отключен ? Там еще кто-то вспоминал про echo 1 >multicast_querier

А мост на чем ? openvswitch или обычный ?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Tcpdump показывает исходящий пакет OSPF как на самом мосте, как и на слейвах (туннелях). На .3 как и на остальных машинах значения такие. 

сat /sys/devices/virtual/net/vpnbr0/bridge/multicast_querier
1 
cat /sys/devices/virtual/net/vpnbr0/bridge/multicast_snooping
0
Включено и выключено соответственно, собственно snooping отключается при поднятии моста, прописано в interfaces.

Мост совершенно обычный linux-bridge - настройку опять же можно увидеть в конфиге, он есть в теме.

Hatifnatt
() автор топика
Ответ на: комментарий от vel

ttl для ospf должен быть 1.

Так беда в том, что ttl в linux уменьшается для пакета несколько раз в пределах одного хоста, если уходит не в физический интерфейс, а в виртуальный. Почему так сделано, во всех ли случаях и во всех ли ядрах - это не знаю. Сам наступал около десятка лет назад.

AS ★★★★★
()
Ответ на: комментарий от Hatifnatt

Хм, а во что включен этот .3 ? Что за оборудование ? Может там что-то блокирует? Хорошо бы убедиться, что пакет выходит с .3 ( через порт-мирроринг )

А ipsec не может быть одной из причин? Может там что поменялось?

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

PS Есть еще очень интересный проект - openvswitch. Для распределенной виртульной сети он подходит значительно лучше. В ядре он давно. Правда я с шифрованными вариантами не сталкивался, но есть рецепты «vxlan network using IPsec».

vel ★★★★★
()
Ответ на: комментарий от Hatifnatt

iptables -t mangle -A OUTPUT -d 224.0.0.5 -j TTL --ttl-set 5

Я бы ещё к интерфейсу привязал, так как, в обычной жизни, ttl у OSPF-пакетов таки должен быть 1.

AS ★★★★★
()
Ответ на: комментарий от vel

Порт .3 никуда не включен, это же бридж поверх туннелей. Сам сервер включен в оборудование хостера, поэтому мирроринг не могу использовать никак. Но все что можно увидеть на внешнем интерфейсе это шифрованные ESP пакеты, и они совершенно одинаковые что для пинга что для OSPF Hello. Весь трафик между хостами выглядит так: 

# tcpdump -ni vmbr0 host A.B.C.D
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:36:57.445742 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f29), length 212
15:36:59.388530 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2a), length 212
15:37:00.550645 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2b), length 164
15:37:01.293589 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2c), length 212
15:37:02.132090 IP X.Y.Z.F > A.B.C.D: ESP(spi=0x09963902,seq=0xd48), length 164
15:37:03.198663 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2d), length 212
15:37:05.104285 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2e), length 212
15:37:05.784448 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f2f), length 212
15:37:07.239277 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f30), length 164
15:37:07.240408 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f31), length 1460
15:37:07.240445 IP A.B.C.D > X.Y.Z.F: ESP(spi=0x0bda8da3,seq=0x12f32), length 196

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

Про openvswitch слышал конечно, но не хотелось все переделывать на данном этапе, хотелось быстренько ввести новый гипервизор в строй и приступить к задачам для которых он предназначен. Кроме того openvswitch придется сначала изучить / протестировать в «лабораторных условиях» - тоже время, а его как обычно не хватает.

Hatifnatt
() автор топика
Ответ на: комментарий от AS

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

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

Лишний форвардинг чего и где?

Пакета, попадающего в тонель. Из-за чего ttl уменьшается лишний раз и ttl=1 для OSPF не работает, хотя должен в теории.

Идея выкинуть мост - хорошая, попробую.

У меня это было без мостов, просто с GRE.

AS ★★★★★
()
Ответ на: комментарий от Hatifnatt

для проверки можно попробовать отключить ipsec ( но оставить бридж ).

tshark вроде умеет декодировать ipsec в режиме тунеля, при наличии ключей.

vel ★★★★★
()

quagga 0.99.22.4-1+wheezy1

quagga 0.99.23.1-1+deb8u3

нужно смотреть в сторону версий программного обеспечения версия quagga у тебя разные были примеры на практике что не заводилось на разных версиях зебры

rootmaster ★
()

Вспомнилась забавная история с хабра про изменения в ip_grep между 3.8 и 3.13, но у них использовался openvswitch. А между 2.6 и 4.4 просто пропасть!

Я наступал на грабли в quagga/ospfd из-за разных MTU

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от rootmaster

Данный вариант я рассматриваю во вторую очередь, т.к. сейчас главная проблема в том, что трафик не проходит через туннель. Выше писал, с помощью iptables можно добиться прохождения трафика, если поставить ttl=5, но начинаются проблемы уже с Quagga.

Hatifnatt
() автор топика
Ответ на: комментарий от vel

Когда делал этот велосипед - учитывал оверхед от Gre, но высчитывать до байта не стал, поэтому внутри туннеля у меня MTU 1400 - это отражено в конфиге.

Попробовал избавится от бриджа на .3: 

# ip a s vpntap3
13: vpntap3@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 72:d1:12:39:b1:ca brd ff:ff:ff:ff:ff:ff
    inet 172.20.128.3/24 scope global vpntap3
       valid_lft forever preferred_lft forever
    inet6 fe80::70d1:12ff:fe39:b1ca/64 scope link
       valid_lft forever preferred_lft forever

# ip ro
...
224.0.0.0/4 dev vpntap3  scope link
Но результат ровно тот же что и с бриджем, на .3 пакеты на интерфейсе есть, а на .1 их уже нет.
На .3 
# tcpdump -v -ni vpntap3 not port 5405 and not host 239.192.184.95
tcpdump: listening on vpntap3, link-type EN10MB (Ethernet), capture size 262144 bytes
17:45:32.975716 IP (tos 0xc0, ttl 1, id 51706, offset 0, flags [none], proto OSPF (89), length 64)
    172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 44
        Router-ID 172.20.252.3, Backbone Area, Authentication Type: none (0)
        Options [External]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 1
          Designated Router 172.20.128.3
17:45:35.090283 IP (tos 0xc0, ttl 1, id 50816, offset 0, flags [none], proto OSPF (89), length 88)
    172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
        Router-ID 172.20.252.1, Backbone Area, Authentication Type: MD5 (2)
        Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x588e000f
        Options [External]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 1
          Designated Router 172.20.128.254, Backup Designated Router 172.20.128.2
          Neighbor List:
            172.20.252.2
            172.20.252.254
На .1 
17:45:25.089728 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:45:35.089967 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:45:45.090351 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:45:55.091152 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:46:05.091995 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:46:15.092786 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
17:46:25.093558 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

если поставить ttl=5, но начинаются проблемы уже с Quagga.

Кстати, кроме мультикастных helo есть ещё уникастный обмен маршрутной информацией. Так что надо добавить ещё правило про ttl для пакетов, предназначенных нейбору.

AS ★★★★★
()
Ответ на: комментарий от vel

Нет, не должно, это я накосячил когда «на лету» поправил конфиг через vtysh, но на суть дела это особо не влияет, на данном шаге я проверял не исчезнет ли проблема, если избавиться от бриджа - она не исчезла, с «голым» туннелем все так же - надо подымать ttl иначе трафик не проходит.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

можешь сделать «tcpdump -nevvvXi ethX -s0 ip and proto 47» для этого исходящего hello-ospf?

ethX - тот физический интерфейс, через который ходит туннель

vel ★★★★★
()
Ответ на: комментарий от AS

Я не видел юникастных пакетов OSPF у себя в tcpdump-е, согласно вики https://ru.wikipedia.org/wiki/OSPF#.D0.A4.D0.BE.D1.80.D0.BC.D0.B0.D1.82_OSPF-... все пакеты OSPF - IP (т.е. не udp/tcp) я смотрю трафик либо без фильтра tcpdump -v -ni vpntap3, либо фильтрую OSPF tcpdump -v -ni vpntap3 proto ospf.
В RFC тоже написано что в обычной физической сети, которую я пытаюсь эмулировать пакеты отправляются на адрес AllSPFRouters

The IP destination address for the packet is selected as
follows. On physical point-to-point networks, the IP
destination is always set to the address AllSPFRouters.

https://tools.ietf.org/html/rfc2328#page-58
Если подскажете какой конкретно трафик искать - проверю конечно его прохождение.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

Если подскажете какой конкретно трафик искать

Чуть-чуть не прав оказался. Не маршрутной информации касается, а старта. «OSPFv2, Database Description» летает уникастом и LS-Request. Вот фрагмент трафика:

18:43:27.943381 IP x.x.x.191 > x.x.x.190: OSPFv2, Database Description, length 32
18:43:27.945219 IP x.x.x.190 > x.x.x.191: OSPFv2, Database Description, length 32
18:43:27.945380 IP x.x.x.191 > x.x.x.190: OSPFv2, LS-Request, length 1452
18:43:27.953184 IP x.x.x.190 > 224.0.0.5: OSPFv2, LS-Update, length 180
18:43:27.953696 IP x.x.x.190 > 224.0.0.5: OSPFv2, LS-Update, length 1420

AS ★★★★★
()
Ответ на: комментарий от AS

Изначальное предположение было верным, проблема в ttl туннеля. Как мне подсказали добрые люди поднять ttl для gretap можно так: 

ip link set dev vpntap1 type gretap ttl 100
К сожалению в моем выводе ip link help не было ни слова про ttl поэтому я решил что нельзя для gretap менять ttl линка.

Hatifnatt
() автор топика

Я бы еще посоветовал выкинуть квагу как дряхлого монстра (ибо есть bird http://bird.network.cz/), ipsec как лютое пропертарное 4.2 ибо есть wireguard/openvpn. Да и pve бы туда-же, т.к. посмотреть что они там втихаря напатчили в ядре - негде.

PS: Бриджевать кучку OSPF'овых нод.. Непонятная затея. Чё сделать то хотел?

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Я бы еще посоветовал выкинуть квагу как дряхлого монстра

Только это не изменит проблемы с ttl в тонеле: ttl=1 не в Квагге придумали, оно так положено. А Bird... Хм. А развивается. Про IPv6 уже пишут, можно начинать смотреть. pim вот не вижу пока ещё в описаниии. Хотя нагуглилось вот: https://github.com/Aearsis/bird И IS-IS нет, хотя желание посмотреть на него пока откладываю всё равно...

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Только это не изменит проблемы с ttl в тонеле: ttl=1 не в Квагге придумали, оно так положено.

Я в курсе, где это придумали. Просто квагга - жуткий монстр, наш ответ Чембрелену на gated. Ответ вышел страшный и ужасный.

А Bird... Хм. А развивается. Про IPv6 уже пишут, можно начинать смотреть. pim вот не вижу пока ещё в описаниии. Хотя нагуглилось вот: https://github.com/Aearsis/bird

Я чего-то у автора не заметил наличия PIM. Зато вот кривой дизайн сети в стиле «армянского комсомола» - в наличии.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Я чего-то у автора не заметил наличия PIM

Ну там написано «My goal is to teach BIRD PIM protocol». Глубже я не смотрел пока: увидел же только что. :-)

AS ★★★★★
()
Ответ на: комментарий от Hatifnatt

Если оно по-умолчанию inherit, то тогда понятен результат...

vel ★★★★★
()
Ответ на: комментарий от LynxChaus

квагга - не жуткий монстр.

gated - это жуткий монстр.

vel ★★★★★
()
Ответ на: комментарий от LynxChaus

bird посмотрю, но квагга работает, от добра добра не ищут. Чем IPSec плох не понятно. Point-to-multipoint gre туннели позволяют с достаточно малым количеством конфигов сделать full-mesh сеть цисковский DMVPN вообще то что мне надо, но опенсорсный вариант OpenNHRP завести не удалось. Как с помощью openvpn построить full-mesh сеть? Про wireguard не слышал, надо изучить, может быть это как раз то что мне надо, а я и не знаю.

Че хотел сделать - не прописывать маршруты ручками статически. На каждой ноде своя подсеть для виртуалок, благодаря OSPF каждая нода знает подсети других нод.

Hatifnatt
() автор топика
Ответ на: комментарий от vel

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

Я чего-то у автора не заметил наличия PIM. Зато вот кривой дизайн сети в стиле «армянского комсомола» - в наличии.

Расскажи православный дизайн, с радостью выслушаю и даже не поленюсь все переделать если он и правда хорош.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

bird посмотрю, но квагга работает, от добра добра не ищут.

Она делает вид что работает.

Чем IPSec плох не понятно.

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

Point-to-multipoint gre туннели позволяют с достаточно малым количеством конфигов сделать full-mesh сеть цисковский DMVPN вообще то что мне надо, но опенсорсный вариант OpenNHRP завести не удалось.

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

Поставь tinc vpn (причем версию 1.1.x-pre) и соедини все ноды через него. Он сам себе хитрый бридж с вычислением связанности и доступности.

На каждой ноде подними на bird'e BGP+BFD с приватной AS, включи redistribute connected & route reflector. Да, настраивать придется чуть дольше, чем бридж с OSPF. Но зато сразу будет видно, где и что отпало и не будет мультикаста. BFD поможет понять, что канал сдох раньше, чем это заметит OSPF (если тебе конечно нужна какая-то адекватная доступность).

Нет, можно конечно и OSPF поверх tinc/wireguard запустить, но зачем? Тем более - один bridge domain это никак не «full-mech» сеть. full-mech подразумевает все-со-всеми - т.е. у тебя на 4 ноды должно быть 16 тунелей.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Я заводил это все года полтора назад минимум, tinc смотрел тогда, но он был (а может и есть) однопоточный и упирался в одно ядро, люди делали бонд из нескольких интерфейсов чтоб пропускную способность увеличить https://habrahabr.ru/post/185624/ а IPSec давал приличную скорость без подобных плясок. Чем хороша версия 1.1.x-pre какое-то существенное улучшение в ней произошло?

BGP+BFD это круто наверняка, но пока что всего 4 ноды, и взрывного роста не ожидается, когда все заводил как обычно надо было «быстро быстро», были знания кое какие по OSPF, по BGP не было, этим обоснован выбор. Изучу какие преимущества подобный вариант сулит в моем случае, спасибо.

Wireguard пока что не production-ready

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come.

Честно говоря не понял почему должно быть 16 туннелей, каждая нода связывается с 3-мя другими, получаем такую картину http://scr.hatifnatt.ru/shrx/full-mesh.png 6 туннелей всего по 3 туннеля на каждой ноде.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

tinc смотрел тогда, но он был (а может и есть) однопоточный и упирался в одно ядро

Он и сейчас однопоточный. Только в версии 1.1.x есть chacha-poly+ed25519 которые дают существенный выигрыш по скорости на машиних, где нет поддержки AES. Каюсь, в 1.0 не смотрел именно из-за отсутствия AES, но на дохлом raspbery pi tinc давал мегабит 100 в туннеле со сжатием.

люди делали бонд из нескольких интерфейсов чтоб пропускную способность увеличить https://habrahabr.ru/post/185624/

Я бы рекомендовал пропускать все статьи с упоминанием микротика, если конечно не хочешь почитать про «армянский комсомол и его героическое преодоление трудностей самих себе созданных».

BGP+BFD это круто наверняка, но пока что всего 4 ноды, и взрывного роста не ожидается, когда все заводил как обычно надо было «быстро быстро», были знания кое какие по OSPF

Еще как вариант - набрать б/у цисок с тобой любимым IPSEC'ом и DMVPN настроить и забыть.

Wireguard пока что не production-ready

Ну кому как.

Честно говоря не понял почему должно быть 16 туннелей,

Соврал, 12.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Т.е. в tinc 1.1+ есть поддержка aes-ni? В таком случае и на одном потоке должно неплохо тянуть. Надо дать tinc еще один шанс.

Все это велосипедостроение не от хорошей жизни, крутится все на арендованных серверах, которые еще и в разных ДЦ но линк там неплохой ~950 Мбит дуплекс, в туннеле при этом выдает ~750 Мбит. Таким образом циски отпадают, некуда их ставить просто.

Все же хотелось бы понять откуда 12 туннелей то? 1 туннель в оба направлениях работает зачем 2 туннеля от А до Б и от Б до А?

А по поводу Wireguard - если разработчки говорят что не готово еще, кто я такой чтоб им не доверять :)

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

Т.е. в tinc 1.1+ есть поддержка aes-ni? В таком случае и на одном потоке должно неплохо тянуть. Надо дать tinc еще один шанс.

Там есть то, что умеет openssl|libgcrypt. Умеют в оптимизированную на платформе AES-NI - будет поддержка. У меня была задача быстро шифровать на дохлом ARM'e - он с ней справлялся.

Все это велосипедостроение не от хорошей жизни, крутится все на арендованных серверах, которые еще и в разных ДЦ

Ну да, 3 тыщи рублей за юнит для циски тоже деньги.

Все же хотелось бы понять откуда 12 туннелей то?

Да затупил я по черному. 6 штук надо.

LynxChaus ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin