Маршрутизация с одного сервера на другой с разными интерфейсами

У меня такая топология

Сервер A:

eth0 IP: 10.10.20.11/24 и 10.10.20.13/24
eth3: 88.x.x.x (vlan с идентификатором 10)
основной шлюз: GW2 (10.10.20.3)

Сервер B:

eth0 IP: 10.10.20.23/24
шлюз по умолчанию: server A (10.10.20.11)

Снаружи я могу пинговать 88.x.x.x IP. Server A можно пинговать Server B. На Server B Я отключил брандмауэр.

Теперь я пытаюсь перенаправить трафик из 88.x.x.x Server A к Server B со следующими правилами:

<?xml version="1.0" encoding="utf-8"?>
<direct>
    <passthrough ipv="ipv4">-A PREROUTING  -t nat -p tcp -d 88.x.x.x   --dport X -j DNAT  --to-destination 10.10.10.23:Y</passthrough>
</direct>

Переменные Sysctl на server A: Во время устранения неполадок получил некоторые результаты:

tcpdump port X на Server A показывает пакеты
не были показаны пакеты для tcpdump dst 10.10.10.23 на Server A.
tcpdump port Y на Server B ничего не показывает.
На сервере a работает следующее: telnet 10.10.10.23 Y

После отключения rp_filter У меня полуработающая топология - по крайней мере, я видел перенаправленные и DNAT-пакеты в tcpdump.

После этого у меня получилась следующая картина:

Сервер A: tcpdump -i any port X -n

IP 85.x.x.x > 88.x.x.x.X

Сервер A: tcpdump -i any port Y -n

IP 85.x.x.x > 10.10.10.23.Y:

Сервер B: tcpdump -i any port Y -n

IP 85.x.x.x > 10.10.10.23.Y

Я расширил фильтр tcpdump до port Y and icmp и я начал видеть icmp admin prohibited сообщения в ответах от 10.10.10.23 хост. Затем я настроил правила брандмауэра на server B - icmp сообщения остановлены.

В настоящее время у меня есть следующие конфигурации маршрутизации: - Server A

ip -4 ru ls:
0: from all lookup local
32764: from 88.XX/27 lookup 2014
32765: from 10.10.20.11 lookup 1000
32766: from all lookup main
32767: from all lookup default

ip -4 r ls table all:
default via GW1 dev eth3 table 2014
88.x.x.x/27 dev eth3 table 2014
default via 10.10.20.3 dev eth0 table 1000
default via 10.10.20.3 dev eth0
10.10.20.0/24 dev eth0 proto kernel scope link src 10.10.20.11
88.x.x.x/27 dev eth3 proto kernel scope link src 88.x.x.x
broadcast 10.10.20.0 dev eth0 table local proto kernel scope link src 10.10.20.11
local 10.10.20.11 dev eth0 table local proto kernel scope host src 10.10.20.11
local 10.10.20.13 dev eth0 table local proto kernel scope host src 10.10.20.11
broadcast 10.10.20.255 dev eth0 table local proto kernel scope link src 10.10.20.11
broadcast 88.x.x.x dev eth3 table local proto kernel scope link src 88.x.x.x
local 88.x.x.x dev eth3 table local proto kernel scope host src 88.x.x.x
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

Server B

ip -4 r ls:
default via 10.10.20.11 dev eth0
10.10.20.0/24 dev eth0 proto kernel scope link src 10.10.20.23

Мне нужен доступ к Server B через реальный IP (88.x.x.x) снаружи. Что я делаю не так или не хватает?

Шаг по устранению неполадок:

Проверьте фактическую маршрутизацию. На сервере A запустить ip route get 10.10.10.23 from 8.8.8.8 iif eth1. В выходных данных этой команды вы должны увидеть действительный маршрут. Если вы что-то видите RTNETLINK answers: No route to host, вы отключили пересылку. См. Следующий шаг. Выход как RTNETLINK answers: Invalid cross-device средства rp_filter фильтрует похожие пакеты. Вы также можете полностью отключить его или установить в loose Режим.
На сервере A проверьте пересылку (ip netconf show dev <iface>). Он должен быть включен (forwarding on на выходе). You can turn on it withsysctl` команда.
В правиле SNAT следует использовать --to-source 10.10.10.Z, где 10.10.10.Z это адрес eth0 интерфейс сервера A. В противном случае возникают побочные эффекты при трансляции ответных пакетов с сервера B. Если шлюз по умолчанию для serverB - serverA, то правило SNAT не требуется.
Проверьте полный набор правил на сервере A. Используйте iptables-save -c команда для вывода списка всех правил со счетчиками. Вы должны увидеть ненулевые счетчики в правилах FORWARD цепь.
Выполните аналогичные шаги для serverB: проверьте маршрутизацию, проверьте набор правил брандмауэра, проверьте вывод tcpdump.
Бегать tcpdump на обоих хостах и проверьте трафик. В tcpdump перехватывает входящие пакеты до брандмауэра, а исходящие - после. Лучше включить icmp в фильтрах tcpdump, иначе вы не увидите отказов icmp, например port unreachable и тому подобное.
Когда все вышеперечисленные шаги будут выполнены, вы должны добавить эти правила брандмауэра в конфигурацию server A сделать ответные пакеты из server B пройти через GW1:

iptables -t mangle -A FORWARD\
         -p tcp --dst 10.10.20.23 \
         -m conntrack --ctstate DNAT --ctorigdst 88.x.x.x --ctdir ORIGINAL \
    -j CONNMARK --set-mark 2014

iptables -t mangle -A PREROUTING \
         -i eth0 -p tcp \
         -m conntrack --ctstate DNAT --ctdir REPLY \
    -j CONNMARK --restore-mark

И добавляем в PBR дополнительное правило маршрутизации:

ip rule add fwmark 2014 lookup 2014