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

Linux + OpenVPN; интерфейс моста не отвечает на ARP

Я пытаюсь установить соединение OpenVPN с Ethernet-мостом Layer2 для соединения двух локальных сетей. Кажется, что ответы ARP генерируются неправильно ...

Обратите внимание: я хочу создать полный Мост уровня 2, позволяющий ретранслировать весь трафик, включая широковещательные пакеты. Я буду использовать ebtables и другие методы для блокировки DHCP и т. Д.

Топология сети

У нас есть две локальные сети (назовем их LAN1 и LAN2) в разных физических местах. Каждая локальная сеть представляет собой стандартную жилую сеть с подключением к Интернету потребительского уровня.

------------     ---------     ----------    ------------------------
* Internet * --> * Modem * --> * Router * -> * Switches and Clients *
------------     ---------     ----------    ------------------------

В каждой сети мы создали сервер Linux, предназначенный для работы в качестве резервного файлового сервера и моста VPN. Серверы, называемые Thing1 (в LAN1) и Thing2 (в LAN2), являются клиентскими устройствами.

LAN1 использует 192.168.110.0/24

LAN2 использует 192.168.111.0/24

Конфигурация

На каждой из машин OpenVPN (Thing1 и Thing2) установлен и запущен OpenVPN. Соединение создано успешно.

На каждом сервере мы создаем ответвления и мосты с помощью сценария запуска моста. Я подстригала здесь ...

мост-старт

echo 1 > /proc/sys/net/ipv4/ip_forward
br="br0"
tap="tap0"
eth="enp2s0"

#obtain the Hardware Mac address of the physical ethernet interface
eth_hw_mac=`ifconfig $eth | grep 'HWaddr' | cut -d' ' -f9`

for t in $tap; do
    ip tuntap add dev $t mode tap
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
    brctl addif $br $t
done

for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up
ifconfig $br hw ether $eth_hw_mac

dhclient $br

# Load ebtables rules to block DHCP traffic across the bridge.
ebtables -A INPUT -i tap0 -p ipv4 --ip-proto udp --ip-dport 67:68 -j DROP
ebtables -A INPUT -i tap0 -p ipv4 --ip-proto udp --ip-sport 67:68 -j DROP
ebtables -A FORWARD -o tap0 -p ipv4 --ip-proto udp --ip-dport 67:68 -j DROP
ebtables -A FORWARD -o tap0 -p ipv4 --ip-proto udp --ip-sport 67:68 -j DROP

Единственное отличие состоит в том, что на Thing2 интерфейс касания называется tap1, а не tap0.

Соответствующий ifconfig на Thing1 (192.168.110.250)

br0       Link encap:Ethernet  HWaddr b8:ae:ed:fc:4a:4f
          inet addr:192.168.110.250  Bcast:192.168.110.255  Mask:255.255.255.0
          inet6 addr: fe80::baae:edff:fefc:4a4f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:560719 errors:0 dropped:0 overruns:0 frame:0
          TX packets:271873 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:120753983 (120.7 MB)  TX bytes:72273308 (72.2 MB)

enp2s0    Link encap:Ethernet  HWaddr b8:ae:ed:fc:4a:4f
          inet6 addr: fe80::baae:edff:fefc:4a4f/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:525244 errors:0 dropped:68 overruns:0 frame:0
          TX packets:548223 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142488031 (142.4 MB)  TX bytes:129824161 (129.8 MB)

tap0      Link encap:Ethernet  HWaddr c6:5d:10:17:5c:b9
          inet6 addr: fe80::c45d:10ff:fe17:5cb9/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:240521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:238686 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:49398722 (49.3 MB)  TX bytes:47097224 (47.0 MB)

Соответствующий ifconfig на Thing2 (192.168.111.250)

br0       Link encap:Ethernet  HWaddr f4:4d:30:08:f1:e5
          inet addr:192.168.111.250  Bcast:192.168.111.255  Mask:255.255.255.0
          inet6 addr: fe80::f64d:30ff:fe08:f1e5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1049729 errors:0 dropped:0 overruns:0 frame:0
          TX packets:757240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5142387727 (5.1 GB)  TX bytes:302576425 (302.5 MB)

enp2s0    Link encap:Ethernet  HWaddr f4:4d:30:08:f1:e5
          inet6 addr: fe80::f64d:30ff:fe08:f1e5/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:7254547 errors:0 dropped:389 overruns:0 frame:0
          TX packets:3661240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6092825279 (6.0 GB)  TX bytes:1214754910 (1.2 GB)

tap1      Link encap:Ethernet  HWaddr 46:6f:ee:61:de:b2
          inet addr:192.168.110.1  Bcast:192.168.110.255  Mask:255.255.255.0
          inet6 addr: fe80::446f:eeff:fe61:deb2/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:233278 errors:0 dropped:0 overruns:0 frame:0
          TX packets:294344 errors:0 dropped:46711 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:46740438 (46.7 MB)  TX bytes:129353655 (129.3 MB)

Соответствующие строки из OpenVPN server.conf на Thing1 (192.168.110.250)

port 1194
proto udp
dev tap0
topology subnet
ifconfig-pool-persist ipp.txt
server-bridge 192.168.110.250 255.255.255.0 192.168.110.1 192.168.110.10
client-to-client
keepalive 10 120
persist-key
persist-tun

Таблица маршрутов на Thing1

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router.asus.com 0.0.0.0         UG    0      0        0 br0
192.168.110.0   *               255.255.255.0   U     0      0        0 br0
192.168.111.0   192.168.111.250 255.255.255.0   UG    0      0        0 tap0
192.168.111.250 *               255.255.255.255 UH    0      0        0 tap0

Таблица маршрутов на Thing2

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router.asus.com 0.0.0.0         UG    0      0        0 br0
192.168.110.0   192.168.110.250 255.255.255.0   UG    0      0        0 tap1
192.168.110.250 *               255.255.255.255 UH    0      0        0 tap1
192.168.111.0   *               255.255.255.0   U     0      0        0 br0

Проблема

Я пытаюсь пинговать .111.250 из .110.250, но разрешение ARP никогда не происходит ...

ping 192.168.111.250

PING 192.168.111.250 (192.168.111.250) 56(84) bytes of data.
From 192.168.110.250 icmp_seq=1 Destination Host Unreachable
From 192.168.110.250 icmp_seq=2 Destination Host Unreachable
From 192.168.110.250 icmp_seq=3 Destination Host Unreachable

Выполнение tcpdump на кране .110.250 во время пинга ...

tcpdump -i tap0 -en | grep "ARP"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:43:08.283935 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:43:08.300129 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:43:08.300181 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:43:09.300441 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:43:09.300493 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:43:10.302120 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:43:10.302170 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:43:11.300760 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:43:11.300810 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:43:12.300762 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:43:12.300815 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28

Эта последовательность повторяется для каждой попытки проверки связи.

Между тем, на tap1 .111.250 (у которого IP 192.168.110.1) ...

tcpdump -i tap1 -en | grep "ARP"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:49:47.315913 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:49:47.813360 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:49:47.830572 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:49:48.314726 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:49:48.812622 46:6f:ee:61:de:b2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.110.250 tell 192.168.110.1, length 28
15:49:48.832273 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28

Если мы посмотрим на br0 .111.250 (у которого на самом деле 192.168.111.250) ...

tcpdump -i br0 -en | grep "ARP"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:53:49.969025 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:53:50.341753 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28
15:53:50.968877 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:53:51.341336 b8:ae:ed:fc:4a:4f > 46:6f:ee:61:de:b2, ethertype ARP (0x0806), length 42: Reply 192.168.110.250 is-at b8:ae:ed:fc:4a:4f, length 28

Но на физическом адаптере Ethernet ...

tcpdump -i enp2s0 -en | grep "ARP"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:56:13.344685 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28
15:56:14.344167 c6:5d:10:17:5c:b9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.250 tell 192.168.110.250, length 28

Насколько я понимаю, br0 Thing2, имеющий адрес 192.168.111.250, должен отправлять ответ вроде ...

f4:4d:30:08:f1:e5 > c6:5d:10:17:5c:b9, ethertype ARP (0x0806), length 42: Reply 192.168.111.250 is-at f4:4d:30:08:f1:e5, length 28

Я не уверен, что это исправит все, что сломано, или если я упустил что-то очень очевидное. Не стесняйтесь вносить любые предложения, которые, по вашему мнению, двинут меня в правильном направлении.

Проблема в том, что вы пытаетесь соединить две разные IP-подсети, но это не работает. Одна IP-подсеть состоит из одного широковещательного домена, и теперь вы пытаетесь настроить две разные IP-подсети в одном широковещательном домене (мост через VPN).

Во время пинга происходит то, что ваш 192.168.111.250 отправляет ARP-запрос на 192.168.110.250, который не ответит на него, потому что запрос исходит с IP-адреса за пределами его подсети. 192.168.110.0/24.

Другая проблема в вашей конфигурации заключается в том, что вы определили IP-адрес как для своего br0 устройство, которое является мостовым устройством, и tapX устройство, входящее в состав моста.

Вы должны назначить IP-адрес только устройству моста.

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