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

Question

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

Я создал мост между 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 из ubuntu:

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 , потому что я пробую это с конечной точкой VPN клиента AWS Вот. Я запустил 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 24.10.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 ВПЕРЕД -i br0 -o tun0 -j ПРИНЯТЬ

3 sudo iptables -A ВПЕРЕД -i tun0 -o br0 -j ПРИНЯТЬ

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 эхо-запроса не пересылаются на tun0 .

1

networking vpn routing openvpn linux-networking

задан Anton Danilov 15 May 2019 в 16:50

Ссылка

1 ответ


         
              



      
        Теги
        
         networking vpn routing openvpn linux-networking       

        Похожие вопросы
        
          
                          441 
 Как Разделение на подсети IPv4 Работает? - 22 December 2018 20:30 
                            266 
 Я наследовал вложенное множество крысы кабельных соединений. Что теперь? - 28 August 2012 07:33 
                            184 
  Почему нельзя использовать MAC-адреса вместо IPv4 | 6 для работы в сети? [закрыто]  - 24 July 2012 17:22 
                            183 
 Установка имени хоста: FQDN или краткое название? - 27 May 2016 19:13 
                            174 
 Я должен выйти из использования Ifconfig? - 1 May 2013 15:46 
                            134 
 Разрешите имя хоста от IP-адреса - 13 October 2009 17:27 
                            122 
 VirtualBox: Как настроить сети, таким образом, и хост и гость могут получить доступ к Интернету и говорить друг с другом - 21 January 2011 15:56 
                            116 
 Как разделение на подсети IPv6 работает и как оно отличается от разделения на подсети IPv4? - 13 April 2017 15:14 
                            113 
 Как насильственно закрыть сокет в TIME_WAIT? - 27 November 2012 13:13 
                            111 
 Каково различие между одноадресной передачей, передачей любому из узлов, широковещательным трафиком и многоадресным трафиком? - 11 June 2011 22:17 
                            109 
 Переключение на IPv6 подразумевает отбрасывающий NAT. Это - хорошая вещь? - 13 April 2017 15:14 
                            108 
 Как проверить, заблокирован ли порт на машине Windows? - 19 February 2015 15:04 
                            107 
 Сколько сетевой задержки “типично” для востока - западное побережье США? - 13 April 2017 15:14 
                            92 
 Как я нахожу, существует ли жулик сервер DHCP в моей Сети? - 23 June 2015 03:41 
                            90 
 Почему консоли иногда зависают навсегда, когда соединение SSH повреждается? - 22 June 2011 21:12

score 4 · Answer 1 · 3 December 2019 в 17:32

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

Проверьте следующие шаги:

Проверьте маршрутизацию на wifi клиенте (здесь и далее - 10.24.11.X - замените на ваш фактический ip-адрес этого устройства). Для Вашей схемы требуется один из двух положительных адресов: маршрут по умолчанию через 10.24.11.15 или лучше (я думаю) 10.2.0.0/16 через 10.24.11.15.
Проверьте переадресацию на узле ubuntu с помощью ip маршрут получит 10. 2.1.145 из 10.24.11.X iif br0 и ip маршрут получает 10.24.11.X из 10.2.1.145 iif tun0 команд. Он должен вернуть что-то вроде 10.2.1.145 из 10.24.11.X по 10.20.1.225 dev tun0 (действительный маршрут). Если он возвращает что-то вроде RTNETLINK, то отвечает: Нет маршрута к хосту, это означает, что вы не включили переадресацию ip (глобально или по интерфейсу). Включите его командой sysctl. Проверьте также переадресацию на интерфейсах tun0 и br0 командой ip netconf show dev ... (на строке должна быть переадресация).


 Выполните команду ping 10.2.1.145 на беспроводном клиенте и запустите tcpdump -ni br0 'icmp и ip host 10.24.11.X' и tcpdump -ni tun0 'icmp' на ubuntu host. Вы должны увидеть несколько пакетов с эхо-запросом icmp от wifi клиента на хост 10.2.1.145. Если вы не видите его, проверьте брандмауэр командой iptables-save (и вставьте вывод в вопрос, чтобы получить справку по нему для вашего случая). Если вы видите icmp echo request, но не видите icmp echo response в tcpdump, то вам нужно проверить удаленный сайт.
Ваша схема также требует некоторой настройки маршрутизации на удаленной стороне (на сервере openvpn). Маршрут 10.24.11.0/24 по 10.20.1.226 должен быть на самом сервере openvpn и маршрут к той же подсети на  каком-нибудь удаленном хосте  через сервер openvpn. Другой способ соединения - использование NAT на ubuntu хосте (но это будет описано позже).
На сервере openvpn запустите ip маршрут ip получите 10.2.1.145 из 10.24.11. X iif tunX и ip маршрут получит 10.24.11.X из команды 10.2.1.145 iif ethZ (где tunX и ethZ являются соответствующими интерфейсами open vpn сервера). Обе команды должны отображать действительные маршруты, в противном случае проверьте включение переадресации командой ip netconf show (и включите ее с помощью sysctl).
 Запустите команду tcpdump -ni tunX 'icmp и ip host 10.2.1.145' на сервере openvpn. Вы должны видеть входящие icmp эхо-запросы  с удалённого WiFi клиента и исходящий icmp эхо-ответ  с хоста 10.2.1.145 . Если вы не видите icmp echo reply, запустите tcpdump (или wireshark) на каком-нибудь удаленном узле  и проверьте настройки брандмауэра на нем.
Если у вас нет административного доступа на другую сторону и вы не можете настроить маршрутизацию на нем, то вы должны использовать 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. Порядок правил очень важен!
Если вышеприведенные шаги не помогли решить вашу проблему, пожалуйста, добавьте в вопрос дополнительную информацию, и я предоставлю некоторые дополнительные шаги по устранению проблемы.