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

Связывание сетевого адаптера через GRE-TAP с мостом: нет ответов… если я не запустил «tcpdump»?

Я пытаюсь заставить Linux работать через VPN (GRE-TAP). Самое смешное, что это работает, только когда у меня tcpdump работает на обоих хостах, но об этом позже ...

Есть две машины, называемые pxn1 и pxn2. Они соединяются вместе с помощью простого переключателя через eth1.

pxn1 has IP address 10.1.1.197
pxn2 has IP address 10.1.1.199

IPsec

Чтобы получить безопасное соединение, весь IP-трафик шифруется с помощью IPsec. Это работает, Я могу без проблем пинговать между двумя машинами и tcpdump показывает только зашифрованные пакеты.

GRE-TAP

GRE-TAP (туннелирует кадры Ethernet через IP) Затем интерфейс настраивается в обоих направлениях, потому что позже мне понадобится виртуальный сетевой интерфейс:

ip link add vpn_gre_pxn2 type gretap local 10.1.1.197 remote 10.1.1.199 dev eth1

ifconfig показывает:

vpn_gre_pxn2 Link encap:Ethernet  HWaddr 1a:73:32:7f:36:5f
          inet6 addr: fe80::1873:32ff:fe7f:365f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1462  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1294 (1.2 KiB)  TX bytes:1916 (1.8 KiB)

Это на pxn1. На другом хосте тот же интерфейс настроен в другом направлении.

Мост

Настроен мост, который в настоящее время использует только устройство GRE-TAP.

Мне нужен мост, потому что позже я хочу добавить больше машин (мой план - соединить все туннели GRE вместе). Конечным результатом должна стать ячеистая сеть VPN (с выделенным интерфейсом GRE-TAP для каждой комбинации хост-хост). Но поскольку сейчас я просто провожу первый тест с двумя машинами, мост, конечно, несколько бесполезен, но, тем не менее, важен для самого теста.

brctl addbr vpn_br
brctl addif vpn_br vpn_gre_pxn2

Мост работает потому что когда я активирую vpn_br интерфейс и настроить несколько IP-адресов (только для тестирования моста), ICMP PING работают отлично.

vpn_br    Link encap:Ethernet  HWaddr 02:00:0a:01:01:c5
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1462  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:448 (448.0 B)  TX bytes:468 (468.0 B)

Склеивание

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

Позже также будет реальная отдельная сетевая карта Gbit с выделенным коммутатором, который будет действовать как основное ведомое устройство (при этом VPN будет только резервным), но пока интерфейс связывания будет использовать только VPN.

modprobe bonding mode=1 miimon=1000
ifconfig bond0 hw ether 02:00:0a:01:01:c5  # some dummy MAC
ifconfig bond0 up
ifconfig bond0 mtu 1462
ifenslave bond0 vpn_br   # as said, only a single slive at the moment
ifconfig bond0 172.16.1.2/24 up

Другой хост настроен как 172.16.1.1/24 с HWaddr 02: 00: 0a: 01: 01: c7.

Это приводит к теоретически работающему интерфейсу связывания:

bond0     Link encap:Ethernet  HWaddr 02:00:0a:01:01:c5
          inet addr:172.16.1.2  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::aff:fe01:1c5/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1462  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:448 (448.0 B)  TX bytes:468 (468.0 B)

Статус тоже мне нравится:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: vpn_br
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: vpn_br
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 1a:73:32:7f:36:5f
Slave queue ID: 0

... как и таблица маршрутизации:

# ip route show
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2
172.16.1.0/24 dev bond0  proto kernel  scope link  src 172.16.1.2
10.1.1.0/24 dev eth1  proto kernel  scope link  src 10.1.1.197
default via 10.1.1.11 dev eth1

NB: eht0 это отдельный активный сетевой адаптер (кросс-кабель Ethernet), но это не имеет значения, ИМХО.

Эта проблема

Настройка мне кажется хорошей, однако PING не работает (это было запущено на pxn1):

# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
From 172.16.1.2 icmp_seq=2 Destination Host Unreachable
From 172.16.1.2 icmp_seq=3 Destination Host Unreachable
From 172.16.1.2 icmp_seq=4 Destination Host Unreachable

Во время пинга, tcpdump на другой машине (pxn2) говорит:

# tcpdump -n -i bond0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:45:13.013791 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:13.013835 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28
17:45:14.013858 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:14.013875 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28
17:45:15.013870 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
17:45:15.013888 ARP, Reply 172.16.1.1 is-at 02:00:0a:01:01:c7, length 28

Однако, когда я также бегу tcpdump на pxn1 в отдельном терминале я внезапно получаю свои ICMP-ответы! 

...
From 172.16.1.2 icmp_seq=19 Destination Host Unreachable
From 172.16.1.2 icmp_seq=20 Destination Host Unreachable
64 bytes from 172.16.1.1: icmp_req=32 ttl=64 time=0.965 ms
64 bytes from 172.16.1.1: icmp_req=33 ttl=64 time=0.731 ms
64 bytes from 172.16.1.1: icmp_req=34 ttl=64 time=1.00 ms
64 bytes from 172.16.1.1: icmp_req=35 ttl=64 time=0.776 ms
64 bytes from 172.16.1.1: icmp_req=36 ttl=64 time=1.00 ms

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

Это ошибка ядра или (что более вероятно) проблема с моей конфигурацией?

Это нормально, что мост и интерфейс соединения показывают один и тот же MAC-адрес? Я только вручную настраиваю его для интерфейса связывания, который, по-видимому, также меняет мост ..

FYI, обзор конфигурации:

Обновить

Я получаю рабочую настройку, когда устанавливаю интерфейс моста в неразборчивый режим (ifconfig vpn_br promisc ). Я не совсем уверен, что это обычно необходимо. OTOH я не считать у него есть минусы ...

Кстати, есть аналогичный Отчет об ошибке RedHat существует, но установка bond0 вниз / вверх не помогает в моем случае ..

Работает ли он без склеивающего элемента? Я подозреваю, что проблема в том, что сообщения LACP не проходят через мост, пока вы не переведете его в беспорядочный режим.

Если вы используете ядро ​​3.5 или выше, это также может помочь включить передачу IGMP-запросов для интерфейса моста. Это может помочь мосту подписаться на группу многоадресной рассылки LACP. 

echo -n 1 > /sys/devices/virtual/net/vpn_br/bridge/multicast_querier