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

маршрутизация трафика моста в VPN-туннель (AWS Client VPN Endpoint)

Я создал мост между eth0 & wlan0. Ниже приводится ifconfig

root@ubuntu:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.15  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::1fd4:f47a:59d2:1de8  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 2571  bytes 308138 (300.9 KiB)
        RX errors 0  dropped 230  overruns 0  frame 0
        TX packets 2511  bytes 289807 (283.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:db:6d:bb  txqueuelen 1000  (Ethernet)
        RX packets 6268  bytes 1641477 (1.5 MiB)
        RX errors 0  dropped 39  overruns 0  frame 0
        TX packets 7141  bytes 1630895 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 454  bytes 30843 (30.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 454  bytes 30843 (30.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.20.1.226  netmask 255.255.255.224  destination 10.20.1.226
        inet6 fe80::ea4d:bb87:d649:5308  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1407  bytes 94382 (92.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 5095  bytes 1401614 (1.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5124  bytes 1660553 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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

root@ubuntu:~ $ sudo ip route
0.0.0.0/1 via 10.20.1.225 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.1.224/27 dev tun0 proto kernel scope link src 10.20.1.226
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.36.18.24 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.1.225 dev tun0

И 

root@ubuntu:~ $ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.20.1.225     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.24.11.1      0.0.0.0         UG    204    0        0 br0
10.20.1.224     0.0.0.0         255.255.255.224 U     0      0        0 tun0
10.24.11.0      0.0.0.0         255.255.255.0   U     204    0        0 br0
52.36.18.24     10.24.11.1      255.255.255.255 UGH   0      0        0 br0
128.0.0.0       10.20.1.225     128.0.0.0       UG    0      0        0 tun0

Подсеть 10.2.0.0/16 доступен через туннель tun0 может пинговать IP 10.2.1.145 из этой коробки. Но не могу пинговать 10.2.1.145 с устройств, подключенных к этому ящику на wlan0. Также можно пинговать 10.24.11.15 с устройств, подключенных к этому ящику на wlan0

Если я выполню traceroute 10.2.1.145 устройства, подключенные к этому ящику на wlan0, соединение выходит через eth0 через публичный ip.

eth0 имеет 10.24.11.15, но после создания моста он перешел на br0

Какой маршрут мне здесь не хватает, чтобы подтолкнуть 10.2.0.0/16 трафик через tun0 ?

Вот еще один результат:

root@ubuntu:~ $ ip route get 10.2.1.145 from 10.24.11.23 iif br0
10.2.1.145 from 10.24.11.23 via 10.20.0.225 dev tun0
    cache  iif br0

root@ubuntu:~ $ sudo ip netconf show dev tun0
ipv4 dev tun0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
root@ubuntu:~ $

root@ubuntu:~ $ sudo ip netconf show dev br0
ipv4 dev br0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off

Пинг от клиента WiFi и tcpdump из убунту:

root@client:~# ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp and ip host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:30:56.903893 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 8, length 64
15:30:57.904278 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 9, length 64
15:30:58.904826 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 10, length 64


root@client:~# ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -nei eth0 'icmp and ip host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:26:55.356091 ac:bc:32:bf:ad:57 > 18:b1:69:75:7a:f4, ethertype IPv4 (0x0800), length 98: 10.24.11.147 > 10.2.1.145: ICMP echo request, id 5646, seq 169, length 64

iptables-save:

root@ubuntu:~ $ sudo iptables-save
# Generated by iptables-save v1.6.0 on Mon May  6 15:37:25 2019
*nat
:PREROUTING ACCEPT [1299:221082]
:INPUT ACCEPT [290:32450]
:OUTPUT ACCEPT [4762:319088]
:POSTROUTING ACCEPT [680:45560]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May  6 15:37:25 2019
root@ubuntu:~ $ uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux

root@ubuntu:~ $ sudo ip rule ls
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

root@ubuntu:~ $ sudo ip route ls table all
0.0.0.0/1 via 10.20.2.129 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.2.128/27 dev tun0 proto kernel scope link src 10.20.2.130
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.37.118.218 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.2.129 dev tun0
broadcast 10.20.2.128 dev tun0 table local proto kernel scope link src 10.20.2.130
local 10.20.2.130 dev tun0 table local proto kernel scope host src 10.20.2.130
broadcast 10.20.2.159 dev tun0 table local proto kernel scope link src 10.20.2.130
broadcast 10.24.11.0 dev br0 table local proto kernel scope link src 10.24.11.15
local 10.24.11.15 dev br0 table local proto kernel scope host src 10.24.11.15
broadcast 10.24.11.255 dev br0 table local proto kernel scope link src 10.24.11.15
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
fe80::/64 dev br0 proto kernel metric 256  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium
local ::1 dev lo table local proto kernel metric 0  pref medium
local fe80::1fd4:f47a:59d2:1de8 dev br0 table local proto kernel metric 0  pref medium
local fe80::54bf:cf69:4385:4b1c dev tun0 table local proto kernel metric 0  pref medium
ff00::/8 dev br0 table local metric 256  pref medium
ff00::/8 dev tun0 table local metric 256  pref medium

root@ubuntu:~ $ sudo ip -4 a ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.24.11.15/24 brd 10.24.11.255 scope global br0
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet 10.20.2.130/27 brd 10.20.2.159 scope global tun0
       valid_lft forever preferred_lft forever
root@ubuntu:~ $

Другой стороны VPN нет openvpn server, потому что я пытаюсь это сделать с Клиентская конечная точка AWS VPN Вот. Я бежал sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE на хосте Ubuntu. Нет доступа к VPN-серверу.

Обновить :

На клиенте Wi-Fi 

    root@client:~ $ ifconfig
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:d2:02:8c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.201  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::f9e2:e7af:ab5f:7865  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:87:57:d9  txqueuelen 1000  (Ethernet)
        RX packets 86  bytes 7978 (7.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 97  bytes 16637 (16.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@client:~ $ ip -4 route list
default via 10.24.11.1 dev wlan0 src 10.24.11.201 metric 303
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

я удалил sudo route del default gw 10.24.11.1 wlan0 и добавил sudo route add default gw 10.24.11.15 wlan0 на клиенте Wi-Fi

root@client:~ $ ip -4 route list
default via 10.24.11.15 dev wlan0
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

Потом попробовал 

root@client:~# ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145): 56 data bytes

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:40:03.832209 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 121, length 64
13:40:04.879329 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 122, length 64
13:40:05.911833 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 123, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:40:49.539044 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 1, length 64
13:40:50.553286 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 2, length 64
13:40:51.597073 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 3, length 64

Запуск на Ubuntu

1 iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

2 sudo iptables -A FORWARD -i br0 -o tun0 -j ACCEPT

3 sudo iptables -A FORWARD -i tun0 -o br0 -j ACCEPT 

root@ubuntu:~ $ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*filter
:INPUT ACCEPT [32:2202]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [49:4174]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:30:31 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*nat
:PREROUTING ACCEPT [7:1109]
:INPUT ACCEPT [2:144]
:OUTPUT ACCEPT [20:1340]
:POSTROUTING ACCEPT [4:268]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[16:1072] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:30:31 2019

root@client:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.

root@ubuntu:~ $ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*filter
:INPUT ACCEPT [119:7998]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [218:19046]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:31:24 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*nat
:PREROUTING ACCEPT [10:1331]
:INPUT ACCEPT [5:366]
:OUTPUT ACCEPT [45:3015]
:POSTROUTING ACCEPT [9:603]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[36:2412] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:31:24 2019

Затем : 

root@client:~ $ ping 10.20.1.225

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:42:07.498023 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 208, length 64
09:42:08.537648 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 209, length 64
09:42:09.577700 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 210, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

и 

root@client:~ $ ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:43:32.055291 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 12, length 64
09:43:33.099422 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 13, length 64
09:43:34.135264 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 14, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Выглядит как ICMP echo request пакеты не пересылаются tun0.

Итак, попробуем решить вашу проблему. Для лучшего понимания я нарисовал диаграмму топологии сети. Чтобы прояснить, что происходит, я графически разделил обработку l2 и l3 внутри вашего хоста ubuntu - это поможет в дальнейших рассуждениях.

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

  • Проверьте маршрутизацию на wifi клиенте (здесь и далее - 10.24.11.X - замените на свой реальный IP-адрес этого устройства). Ваша схема требует одного из двух возможных вариантов: default route via 10.24.11.15 или лучше (я думаю) 10.2.0.0/16 via 10.24.11.15.

  • Проверьте пересылку на хосте ubuntu с помощью ip route get 10.2.1.145 from 10.24.11.X iif br0 и ip route get 10.24.11.X from 10.2.1.145 iif tun0 команды. Он должен вернуть что-то вроде 10.2.1.145 from 10.24.11.X via 10.20.1.225 dev tun0 (действующий маршрут). Если он вернет что-то вроде RTNETLINK answers: No route to host, это означает, что вы не включили переадресацию IP (глобально или для каждого интерфейса). Включите это с помощью sysctl команда. Также проверьте переадресацию на tun0 и br0 интерфейсы с командой ip netconf show dev ... (там должен быть forwarding on строка).

  • Запустить ping 10.2.1.145 на клиенте Wi-Fi и запустите tcpdump -ni br0 'icmp and ip host 10.24.11.X' и tcpdump -ni tun0 'icmp' на хосте Ubuntu. Вы должны увидеть несколько пакетов с icmp echo request от клиента Wi-Fi к 10.2.1.145 хост. Если вы его не видите, проверьте брандмауэр с помощью iptables-save (и вставьте результат в вопрос, чтобы получить справку для вашего случая). Если вы видите icmp echo request, но не вижу icmp echo reply в tcpdump, тогда вам нужно проверить удаленный сайт.

  • Ваша схема также требует некоторой настройки маршрутизации на удаленной стороне (на openvpn server). Должен быть маршрут 10.24.11.0/24 via 10.20.1.226 на самом сервере openvpn и маршрут к той же подсети на some remote host через openvpn server. Другой способ сделать соединение - использование NAT на хосте ubuntu (но он будет описан позже).

  • На сервере openvpn запустите ip route get 10.2.1.145 from 10.24.11.X iif tunX и ip route get 10.24.11.X from 10.2.1.145 iif ethZ команда (где tunX и ethZ соответствующие интерфейсы открытый vpn сервер). Обе команды должны отображать действительные маршруты, в противном случае проверьте включение пересылки с помощью ip netconf show команду (и включите ее с помощью sysctl).

  • Запустить tcpdump -ni tunX 'icmp and ip host 10.2.1.145' команда на сервере openvpn. Вы должны увидеть входящие icmp echo requests с удаленного клиента Wi-Fi и исходящего icmp echo reply из 10.2.1.145 хост. Если вы не видите icmp echo replyзапустите tcpdump (или wirehark) на some remote host и проверьте настройки брандмауэра на нем.

  • Если у вас нет административного доступа к другой стороне и вы не можете настроить на нем маршрутизацию, вам следует использовать NAT на хосте ubuntu. Вам следует добавить следующее правило в набор правил брандмауэра (лучше использовать iptables-save и iptables-apply команду для безопасности):

iptables -t nat -A POSTROUTING \
         -o tun0 \
    -j MASQUERADE
  • Последний шаг - проверка брандмауэра. Ваша установка требует разрешения пересылки пакетов через хост ubuntu. Упрощенные правила:
iptables -A FORWARD -i br0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o br0 -j ACCEPT

  • Затем проверьте счетчики правил брандмауэра в выводе iptables-save -c команда. Цифры в квадратных скобках соответствуют счетчикам правил в формате [packets:bytes]. Перезапустите ping и проверьте это. По крайней мере, должно быть выполнено правило NAT. Порядок правил очень важен!

  • Если описанные выше действия не помогли решить вашу проблему, добавьте дополнительную информацию в вопрос, и я предоставлю несколько дополнительных шагов для устранения проблемы.