Tại sao bước nhảy đầu tiên của tuyến đường không được chỉ định mặc dù có thể truy cập được?


1

Tóm lược:

Tôi có thể ping cổng nhưng một traceroute qua cổng này không hiển thị nó là bước nhảy đầu tiên, tại sao?

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  * * *

Chi tiết:

Tôi đang gỡ lỗi kết nối trong một container được tường lửa để chỉ cho phép lưu lượng truy cập qua VPN. Điều này không thể nhìn thấy từ phối cảnh của container (tường lửa nằm trên máy chủ của container).

Vấn đề của tôi là kết nối đôi khi không thành công và tôi nghi ngờ nhà cung cấp VPN có lỗi. Triệu chứng điển hình là treo cổ

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

Để điều tra, tôi đã kiểm tra tuyến đường một gói 1.1.1.1 sẽ lấy

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

Đồng thời, một traceroute không nhận ra bước nhảy đầu tiên:

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  * * *

Tại sao nó như vậy? Tôi dự kiến ​​dấu vết sẽ dừng lại sau cánh cổng.

Lưu ý: khởi động lại VPN khắc phục sự cố vì vậy tôi khá chắc chắn đó là thủ phạm.

EDIT: khi được khởi động lại (hoặc chạy chính xác), tuyến đường có thể theo dõi:

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 * *
(...)

traceroute dựa trên các tin nhắn ICMP đã hết hạn của TTL TTL. Một số bộ định tuyến don lồng gửi chúng, đôi khi do cấu hình sai.
Daniel B

@DanielB: điều này là chính xác - nhưng tuyến đường có thể theo dõi được khi VPN hoạt động (tôi đã cập nhật câu hỏi của mình với điều này)
WoJ

Sử dụng wireshark / tcpdump trên giao diện VPN để gỡ lỗi. Nếu sự khác biệt duy nhất giữa làm việc / không hoạt động là bạn không nhận được trả lời "hết hạn", thì có, nhà cung cấp VPN có lỗi và bạn không thể làm gì về điều đó.
dirkt

@WoJ - thử traceroute -I 1.1.1.1 và xem nếu nó hoạt động.
user3788685
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.