☰

為什麼此路由設定不起作用

tag-icon • tag-icon linux routing linux-networking
為什麼此路由設定不起作用

我在伺服器機器上有兩個介面。接下來的輸出ip route是：

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

接下來是ip address（MAC 被隱藏）：

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

值為/proc/sys/net/ipv4/ip_forward1；防火牆已停用。

我想要的是訪問192.168.100.1從10.8.0.100。存取網路伺服器（正在監聽本機上的所有連接埠）curl --interface 10.8.0.100 http://10.8.0.1運作正常。但curl --interface 10.8.0.100 http://192.168.100.201輸出是Network unreachable.

Curl發起tcp握手並將資料包推送到10.8.0.100介面.然後資料包到達伺服器計算機10.8.0.1。伺服器查看資料包目標並發現它是192.168.100.201。然後它查看路由表並看到192.168.100.201是本地的。現在答案又回來了。寄件者是10.8.0.100。查看路由表，我們可以發現它可以透過 訪問tap0，這是本地的。所以現在它進入tap0並達到 10.8.0.100。

但實際上 -不是。難道是我的思路錯了？我認為所描述的表提供的資訊足以確定如何轉發資料包。這實際上是不完整的嗎？

答案1

首先，使用 -I 參數提供 IP 位址和介面不是ping同義詞。首先告訴source IP我們要選哪一個。它將根據網路流量進行路由，包括本地位址和路由表。第二個告訴直接選擇將封包傳送到的介面（並且它將選擇第一個分配的 IP 作為來源）。

接下來你在做什麼與封包轉送無關。轉發意味著資料包必須實際從「外部」到達。當您從該主機產生資料包時，不涉及轉送。這是本地產生的資料包。由於您的目標 IP 是本地分配的位址之一，因此當您不強制 ping 將封包傳送到「外部」（帶有-I interface選項）的特定介面時，核心將在內部處理此封包流。它只是不會嘗試將其輸出到真實的介面，因為它的目的地「已經在這裡」。這就是所發生的情況以及為什麼它在一種情況下有效而在另一種情況下無效。

PS：也請檢查-r該ping工具的選項，以防您知道自己正在執行操作並且兩個介面都附加到同一廣播網域（我對 TAP 介面對此表示懷疑）。

答案2

問題在於對--interface IP和之間差異的誤解--interface dev。第一個使用路由表：

封包--interface 10.8.0.100將不會轉送到tap0介面（該 ip 所屬的介面）。相反，根據路由表，它將被轉送到192.168.100.58（lan 介面）。所以路線是10.8.0.100 -> 192.168.100.58 -> 192.168.100.201.即使發送了 SYN，伺服器也奇怪地不會回應 SYN-ACK - 這就是curl 失敗的原因。

使用--interface tap0ie 連結層位址，它將按預期工作：10.8.0.100 -> 10.8.0.1 -> 192.168.100.201。 SYN-ACK 將使用相同的路由傳回。

相關內容