Por que o primeiro salto de uma rota não é indicado apesar de estar acessível?

Question

Resumo:

Eu posso pingar o gateway, mas um traceroute via este gateway não mostra como o primeiro salto, por quê?

root@tor ~# traceroute 1.1.1.1  -nn
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *

Detalhes:

Estou depurando a conectividade em um contêiner que tem firewall para permitir o tráfego apenas através de uma VPN. Isso não é visível a partir da perspectiva do contêiner (o firewall está no host do contêiner).

Meu problema é que a conectividade às vezes falha e suspeito que o provedor de VPN esteja com defeito. O sintoma típico é um enforcamento

root@tor ~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

Para investigar, verifiquei a rota que um pacote para 1.1.1.1 levaria

root@tor ~# 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: host0@if59: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d6:fa:2e:69:dd:30 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.200.0.3/24 brd 10.200.0.255 scope global host0
       valid_lft forever preferred_lft forever
    inet6 fe80::d4fa:2eff:fe69:dd30/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 10.29.10.6 peer 10.29.10.5/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::8d09:3f0d:9e5f:8298/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

root@tor ~# ip route get 1.1.1.1
1.1.1.1 via 10.29.10.5 dev tun0 src 10.29.10.6 uid 0
    cache

root@tor ~# ip route
0.0.0.0/1 via 10.29.10.5 dev tun0
default via 10.200.0.254 dev host0 proto dhcp src 10.200.0.3 metric 1024
10.1.1.0/24 via 10.200.0.254 dev host0 proto static onlink
10.29.10.1 via 10.29.10.5 dev tun0
10.29.10.5 dev tun0 proto kernel scope link src 10.29.10.6
10.30.1.0/24 via 10.200.0.254 dev host0 proto static onlink
10.100.10.0/24 via 10.200.0.254 dev host0 proto static onlink
10.100.20.0/24 via 10.200.0.254 dev host0 proto static onlink
10.200.0.0/24 dev host0 proto kernel scope link src 10.200.0.3
10.200.0.254 dev host0 proto dhcp scope link src 10.200.0.3 metric 1024
46.166.138.140 via 10.200.0.254 dev host0
128.0.0.0/1 via 10.29.10.5 dev tun0

Ao mesmo tempo, um traceroute não reconhece o primeiro salto:

root@tor ~# traceroute 1.1.1.1  -nn
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *

Por que isso acontece? Eu esperava que o rastreamento parasse após o gateway.

Observação: a reinicialização da VPN corrige o problema, portanto, tenho certeza de que é o culpado.

EDIT: quando reiniciado (ou executando corretamente) a rota é rastreável:

root@tor /e/s/system# traceroute 1.1.1.1  -nn
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.38.10.1  17.959 ms  18.217 ms  18.230 ms
 2  46.166.138.190  18.393 ms * *
(...)