Почему wlo1 не перенаправляет ответ DNS обратно на enp4s0?

Я делюсь своим wifi-соединением (wlo1) через Ethernet (enp4s0) с другим устройством. Пересылка пакетов работала до перезагрузки хост-устройства.

Все маршруты и IP-адреса являются статическими, настроены с использованием NMCLI.

Конфигурация сети:

wlo1: connected to WLAN_JTC
        "Intel Centrino Advanced-N 6235"
        wifi (iwlwifi), 32:0A:48:9C:36:25, hw, mtu 1500
        ip4 default
        inet4 172.16.7.225/20
        route4 172.16.0.0/20
        route4 0.0.0.0/0

enp4s0: connected to enp4s0
        "Realtek RTL8111/8168/8411"
        ethernet (r8169), 9E:3B:65:41:8D:E9, hw, mtu 1500
        inet4 10.0.0.1/30
        route4 10.0.0.0/30
        route4 169.254.0.0/16

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 1.1.1.1 8.8.8.8 8.8.4.4
        interface: wlo1

        servers: 1.1.1.1 8.8.8.8
        interface: enp4s0

IPTABLES:

# Generated by iptables-save v1.8.4 on Wed Jul 29 15:50:34 2020
*filter 
:INPUT DROP [557:29706] 
:FORWARD DROP [13801:2463326] 
:OUTPUT ACCEPT [447:43334]
-A INPUT -p tcp -m multiport --dports 22,80,443,8096,8920 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m multiport --sports 53,7359 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 10.0.0.0/30 -j ACCEPT
-A FORWARD -s 10.0.0.0/30 -o wlo1 -j ACCEPT
-A OUTPUT -p tcp -m multiport --sports 22,80,443,8096,8920 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m multiport --dports 53,7359 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT COMMIT
# Completed on Wed Jul 29 15:50:34 2020
# Generated by iptables-save v1.8.4 on Wed Jul 29 15:50:34 2020
*nat 
:PREROUTING ACCEPT [5695:386224] 
:INPUT ACCEPT [415:27457] 
:OUTPUT ACCEPT [335:27272] 
:POSTROUTING ACCEPT [104:9627]
-A PREROUTING -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8096
-A PREROUTING -d 172.16.7.225/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8096
-A PREROUTING -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8920
-A PREROUTING -d 172.16.7.225/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8920
-A OUTPUT -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8096
-A OUTPUT -d 172.16.7.225/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8096
-A OUTPUT -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8920
-A OUTPUT -d 172.16.7.225/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8920
-A POSTROUTING -o wlo1 -j MASQUERADE COMMIT
# Completed on Wed Jul 29 15:50:34 2020

Переадресация ipv4 включена:

$ sudo sysctl -a | grep -e "net.ipv4.conf.*\.forwarding"
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.enp4s0.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.wlo1.forwarding = 1

Показ TCPDUMP DNS-запрос пересылается на wlo1, но не обратно на enp4s0:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
15:41:28.475263 IP 10.0.0.2.42949 > 1.1.1.1.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.475337 IP 172.16.7.225.42949 > 1.1.1.1.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.475366 IP 10.0.0.2.42949 > 8.8.4.4.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.475375 IP 172.16.7.225.42949 > 8.8.4.4.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.475382 IP 10.0.0.2.42949 > 8.8.8.8.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.475390 IP 172.16.7.225.42949 > 8.8.8.8.53: 19935+ A? dns.msftncsi.com. (34)
15:41:28.478556 IP 1.1.1.1.53 > 172.16.7.225.42949: 19935 1/0/0 A 131.107.255.255 (66)
15:41:28.526947 IP 8.8.4.4.53 > 172.16.7.225.42949: 19935 1/0/0 A 131.107.255.255 (50)
15:41:28.527450 IP 8.8.8.8.53 > 172.16.7.225.42949: 19935 1/0/0 A 131.107.255.255 (50)
15:41:29.227928 IP 10.0.0.2.43252 > 8.8.8.8.53: 2+ A? www.netgear.com. (33)
15:41:29.228014 IP 172.16.7.225.43252 > 8.8.8.8.53: 2+ A? www.netgear.com. (33)
15:41:29.307591 IP 8.8.8.8.53 > 172.16.7.225.43252: 2 5/0/0 CNAME d3jdtixm7cvu7y.cloudfront.net., A 13.225.78.114, A 13.225.78.98, A 13.225.78.100, A 13.225.78.113 (140)
15:41:33.809276 IP 10.0.0.2.39438 > 8.8.8.8.53: 57002+ A? fus01.ps4.update.playstation.net. (50)
15:41:33.809361 IP 172.16.7.225.39438 > 8.8.8.8.53: 57002+ A? fus01.ps4.update.playstation.net. (50)
15:41:33.889200 IP 8.8.8.8.53 > 172.16.7.225.39438: 57002 3/0/0 CNAME wild.ps4.update.playstation.net.edgekey.net., CNAME e7856.d.akamaiedge.net., A 23.50.185.215 (153)
15:41:34.246328 IP 10.0.0.2.52323 > 8.8.8.8.53: 2+ A? www.netgear.com. (33)
15:41:34.246408 IP 172.16.7.225.52323 > 8.8.8.8.53: 2+ A? www.netgear.com. (33)
15:41:34.309107 IP 8.8.8.8.53 > 172.16.7.225.52323: 2 5/0/0 CNAME d3jdtixm7cvu7y.cloudfront.net., A 13.225.78.113, A 13.225.78.98, A 13.225.78.114, A 13.225.78.100 (140)
15:41:34.372124 IP 10.0.0.2.10824 > 8.8.8.8.53: 6304+ A? www.google.com. (32)
15:41:34.372210 IP 172.16.7.225.10824 > 8.8.8.8.53: 6304+ A? www.google.com. (32)
15:41:34.423672 IP 8.8.8.8.53 > 172.16.7.225.10824: 6304 1/0/0 A 172.217.21.4 (48)
15:41:34.957237 IP 10.0.0.2.41139 > 8.8.8.8.53: 36090+ A? gmail.com. (27)
15:41:34.957323 IP 172.16.7.225.41139 > 8.8.8.8.53: 36090+ A? gmail.com. (27)
15:41:35.020244 IP 8.8.8.8.53 > 172.16.7.225.41139: 36090 1/0/0 A 172.217.21.5 (43)
15:41:35.386002 IP 10.0.0.2.10824 > 1.1.1.1.53: 6304+ A? www.google.com. (32)
15:41:35.386087 IP 172.16.7.225.10824 > 1.1.1.1.53: 6304+ A? www.google.com. (32)
15:41:35.386115 IP 10.0.0.2.10824 > 8.8.4.4.53: 6304+ A? www.google.com. (32)
15:41:35.386128 IP 172.16.7.225.10824 > 8.8.4.4.53: 6304+ A? www.google.com. (32)
15:41:35.386135 IP 10.0.0.2.10824 > 8.8.8.8.53: 6304+ A? www.google.com. (32)
15:41:35.386143 IP 172.16.7.225.10824 > 8.8.8.8.53: 6304+ A? www.google.com. (32)
30 packets captured
30 packets received by filter
0 packets dropped by kernel