Задать вопрос
Hatifnatt
@Hatifnatt
сети

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

Приветствую.
Имеется следующий конфиг: несколько серверов, объединенных в «локальную сеть» путем соединения каждого с каждым используя GRE туннели, вернее GRETAP туннели, т.е. L2 (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


Продолжение в комментарии, лимит в 10 тыс символов :(
  • Вопрос задан
  • 2207 просмотров
3 комментария
Подписаться 3 Оценить 3 комментария
Решения вопроса 1
Hatifnatt
@Hatifnatt Автор вопроса
Добрые люди подсказали правильную команду. Проблема решилась ручным указанием ttl для туннеля:
ip link set dev vpntap1 type gretap ttl 30
Или можно указать при создании туннеля
auto vpntap1
iface vpntap1 inet manual
        pre-up ip link add $IFACE type gretap local A.B.C.D  remote X.Y.Z.F  key 111.111.111.101 ttl 30
        post-up ip link set $IFACE mtu 1400 || true
        post-down ip link delete $IFACE


Суть проблемы в ttl. GRE пакеты наследуют ttl инкапсулированного пакета, даже если это gretap туннель, т.е. L2 и инкапсулируются Ethernet фреймы, а не IP пакеты как в случае с обычным GRE. Далее ttl наследуется зашифрованными IPSec ESP пакетами. В результате в интернет уходит ESP пакет с ttl=1 и естественно он пропадает. На старом ядре 2.6.32-30-pve для gretap такого наследования ttl очевидно нет, поэтому все работало "из коробки".

Я изначально пробовал сменить ttl у туннелья с помощью ip tunnel change vpntap3 ttl 10 но для gretap эта команда не работает, ошибка:
get tunnel "vpntap3" failed: Operation not supported


Встроенная в ip справка мне не очень помогла
ip link help - нет ни слова про ttl, но оказывается если уточнить рамки помощи вот таким образом
ip link help gretap, можно получить ценную информацию:
# ip link help gretap
Usage: ip link { add | set | change | replace | del } NAME
          type { gre | gretap } [ remote ADDR ] [ local ADDR ]
          [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]
          [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]
          [ noencap ] [ encap { fou | gue | none } ]
          [ encap-sport PORT ] [ encap-dport PORT ]
          [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]

Where: NAME := STRING
       ADDR := { IP_ADDRESS | any }
       TOS  := { NUMBER | inherit }
       TTL  := { 1..255 | inherit }
       KEY  := { DOTTED_QUAD | NUMBER }

В Debian 7 кстати последний вариант не работает, выводит ровно то же что просто ip link help.
Ответ написан
Комментировать
Комментировать
Пригласить эксперта
Ответы на вопрос 1
athacker
@athacker
Респект за подробно описанную ситуацию :-) Всё ниасилил, но имею предложить следующее :-) У некоторых провайдеров (замечены Ростелеком, Онлайм) некорректно отрабатывает то ли cgnat, то ли какой-то ALG по дороге. Что приводит к блокированию НЕКОТОРЫХ типов пакетов в туннелях, либо при согласовании туннелей. У меня по этой схеме не устанавливаются L2TP сессии -- просто блочится определённый пакет в ответе клиента серверу, и всё.

Так я это всё к чему. Попробуйте поменять тип туннеля с проблемным IP. Либо попробуйте включить шифрование в этом туннеле, чтобы скрыть трафик. Возможно, тогда всё заработает.
Ответ написан
1 комментарий
1 комментарий
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
Вакансии с Хабр Карьеры
Контент-маркетолог
Хекслет
от 60 000 до 100 000 ₽
Преподаватель по нейросетям
CODDY
от 40 000 ₽
Младший аналитик
Сбер • Москва
от 130 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Написать код на языке Python
23 нояб. 2024, в 12:16
60000 руб./за проект
SSL/TLS Certificate pinning / Reverse engineer Android
23 нояб. 2024, в 09:59
2000 руб./в час
Перерисовать логотип в вектор
23 нояб. 2024, в 08:36
2000 руб./за проект
Ещё заказы