Почему не пробрасывается трафик в туннель (tun-интерфейс)?

Question

[Дмитрий Скогорев]

Есть туннель континента - по сути openvpn, со своим шифрованием, но это неважно.
Есть старый профиль и новый, конфигурации идентичны, отличаются только маршруты до машин за туннелем.
Старый работает, новый нет в плане NAT машин за моим сервером, на котором клиент.

LAN                      мой сервер  ip tun-интерфейса                      хост в туннеле
     [192.168.0.99] → [192.168.0.193:172.30.10.6] → [172.30.10.1] → [172.31.1.11]

мои интерфейсы:

# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether bc:24:11:d0:5d:a3 brd ff:ff:ff:ff:ff:ff
        inet 192.168.0.193/24 brd 192.168.0.255 scope global noprefixroute enp6s18
           valid_lft forever preferred_lft forever
        inet6 fe80::b2f2:6041:3a83:bc49/64 scope link noprefixroute
           valid_lft forever preferred_lft forever
    3: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
        link/none
        inet 172.30.10.6 peer 172.30.10.1/32 scope global tun0
           valid_lft forever preferred_lft forever
        inet6 fe80::3116:d2ba:41e:863a/64 scope link stable-privacy
           valid_lft forever preferred_lft forever

маршруты:

default via 192.168.0.1 dev enp6s18 proto dhcp src 192.168.0.193 metric 100
    172.30.10.1 dev tun0 proto kernel scope link src 172.30.10.6
    172.31.1.10 via 172.30.10.6 dev tun0 scope link
    172.31.1.11 via 172.30.10.6 dev tun0 scope link
    172.31.1.12 via 172.30.10.6 dev tun0 scope link
    172.31.1.13 via 172.30.10.6 dev tun0 scope link
    172.31.1.14 via 172.30.10.6 dev tun0 scope link
    172.31.1.15 via 172.30.10.6 dev tun0 scope link
    172.31.1.16 via 172.30.10.6 dev tun0 scope link
    172.31.1.17 via 172.30.10.6 dev tun0 scope link
    172.31.2.10 via 172.30.10.6 dev tun0 scope link
    172.31.2.11 via 172.30.10.6 dev tun0 scope link
    172.31.4.10 via 172.30.10.6 dev tun0 scope link
    172.31.4.11 via 172.30.10.6 dev tun0 scope link
    192.168.0.0/24 dev enp6s18 proto kernel scope link src 192.168.0.193 metric 100

Форвардинг в ядре включен, iptables переключены на legacy, firewalld отключен

# Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
    *mangle
    :PREROUTING ACCEPT [91310:206476897]
    :INPUT ACCEPT [91256:206474083]
    :FORWARD ACCEPT [29:1508]
    :OUTPUT ACCEPT [35421:4562085]
    :POSTROUTING ACCEPT [35517:4565397]
    COMMIT
    # Completed on Tue Jun 10 21:47:19 2025
    # Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
    *raw
    :PREROUTING ACCEPT [91310:206476897]
    :OUTPUT ACCEPT [35422:4562477]
    COMMIT
    # Completed on Tue Jun 10 21:47:19 2025
    # Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
    *security
    :INPUT ACCEPT [90569:206326151]
    :FORWARD ACCEPT [12:624]
    :OUTPUT ACCEPT [35422:4562477]
    COMMIT
    # Completed on Tue Jun 10 21:47:19 2025
    # Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
    *nat
    :PREROUTING ACCEPT [1793:374817]
    :INPUT ACCEPT [1028:222616]
    :OUTPUT ACCEPT [176:12558]
    :POSTROUTING ACCEPT [176:12558]
    -A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
    COMMIT
    # Completed on Tue Jun 10 21:47:19 2025
    # Generated by iptables-save v1.8.10 on Tue Jun 10 21:47:19 2025
    *filter
    :INPUT ACCEPT [960:222411]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [204:14942]
    -A FORWARD -i enp6s18 -o tun0 -j ACCEPT
    -A FORWARD -i tun0 -o enp6s18 -m state --state RELATED,ESTABLISHED -j ACCEPT
    COMMIT
    # Completed on Tue Jun 10 21:47:19 2025

когда я подключаюсь с 192.168.0.99 к 172.31.1.11 и собираю дамп на сервере, где установлен клиент вижу такую картину:

21:48:27.340616 enp6s18 In  IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    21:48:27.340663 tun0  Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    21:48:27.375856 tun0  In  IP 172.31.1.11.22 > 172.30.10.6.44205: Flags [S.], seq 447303237, ack 4168098297, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    21:48:27.375884 tun0  Out IP 172.30.10.6 > 172.31.1.11: ICMP time exceeded in-transit, length 60
    21:48:28.353241 enp6s18 In  IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    21:48:28.353267 tun0  Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    21:48:30.367068 enp6s18 In  IP 192.168.0.99.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    21:48:30.367113 tun0  Out IP 172.30.10.6.44205 > 172.31.1.11.22: Flags [S], seq 4168098296, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Похоже, что пакет не возвращается обратно на исходную запрашивающую машину, и я не понимаю, почему. Хотя аналогичный профиль работает (соседняя железка, и я все равно не могу узнать конфигурацию обоих, хотя администратор говорит, что они идентичны).

Что я делаю не так?

Comments

[Maxim_Q]

проверь значение что стоит 0 или 1? Форвардинг точно включен?
cat /proc/sys/net/ipv4/ip_forward

[Дмитрий Скогорев]

Maxim_Q, первым же делом

если посмотреть на четвертую строку в tcpdump, там по идее должен syn-ack улетать в сторону enp6s18 192.168.0.99, однако оно отбривается

[Maxim_Q]

Дмитрий Скогорев, сервер отвечает ICMP “Time exceeded in-transit” как будто при переправке пакета назад исходный TTL дошёл до нуля. Но у вас там буквально пару серверов и такого быть не должно.
Может отключить строгую валидацию обратного пути (rp_filter)?
Иногда ядро отбрасывает пакеты из-за обратного пути. Убедитесь, что на всех интерфейсах нули:

sysctl -w net.ipv4.conf.all.rp_filter=0

sysctl -w net.ipv4.conf.default.rp_filter=0

sysctl -w net.ipv4.conf.tun0.rp_filter=0

sysctl -w net.ipv4.conf.enp6s18.rp_filter=0

[Дмитрий Скогорев]

Maxim_Q, также отключена, хотя о том что ttl оттуда минимальный - мысль

[Ziptar]

Ошибок не вижу, так что не понятно
Однако, хочу отметить, что правила фильтра на форварде ничего не делают, ибо политика ACCEPT. КПП посреди чистого поля. Считаю важным это отметить for the great justice, несмотря на то, что напрямую к теме это не относится.

[Дмитрий Скогорев]

Maxim_Q, действительно, третий пакет (syn-ack от шлюза в туннеле на клиент) прилетает с TTL=1, что в принципе объясняет всё

[agpecam]

отличаются только маршруты до машин за туннелем

- ну и сравнивайте маршруты с работающим профилем

172.31.1.11 via 172.30.10.6 dev tun0 scope link - это, например, как так? Локальный адрес туннеля в качестве гейтвэя?

[Дмитрий Скогорев]

agpecam, в случае с peer-to-peer и /32 именно так и работает

[Ziptar]

agpecam, это on-link маршрут к 172.31.1.11 через туннель. Они ж там /32 все.

[agpecam]

Дмитрий Скогорев, понял, я по памяти думал, p2p depricated давно в openvpn

Answer 1

[Дмитрий Скогорев]

Собственно удаленный шлюз подменял TTL на единицу, соответственно пакеты доходили до клиента, а дальше не могли гулять
Решение - настучать администраторам железки за такие радости, или править ttl у себя на входе, что и было сделано

iptables -t mangle -D PREROUTING -i tun0 -p tcp -j TTL --ttl-set 64

Спасибо Maxim_Q за наводку

Answer 2

[SunTechnik]

В маршрутизации должен стоять не Ваш ip, а следующий в тунеле (172.30.10.1)
А сейчас пакеты и ходят по кругу : приходят на 172.30.10.6, а куда их дальше (на какой ip) кидать - система не знает...

Comments

[Дмитрий Скогорев]

это p-t-p и именно так оно и работает