解釋路由決策

在我的 linux 伺服器上，我有以下路由表：

$ ip ro
default via 172.28.127.254 dev wlp0s20f3 proto dhcp metric 600 
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.2 
169.254.0.0/16 dev docker0 scope link metric 1000 linkdown 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.28.96.0/19 dev wlp0s20f3 proto kernel scope link src 172.28.107.175 metric 600

基於它我猜想，如果我要嘗試訪問 IP 8.8.8.8，linux 會通過172.28.127.254interface 後面的預設網關來實現wlp0s20f3。然而，這種情況並非如此：

$ ip ro get 8.8.8.8
8.8.8.8 dev tun0 table 205 src 10.8.3.2 uid 1000 
   cache

請解釋一下，為什麼不使用預設網關？

正如路由決策中所暗示的那樣，您擁有基於策略的路由。table 205

您可以通過至少檢查以下輸出來獲得更多資訊：

• ip rule

除了具有首選項 0、32766 和 32767 的預設三個規則之外，它將具有一個或多個規則。附加規則將引用至少一個附加路由表：table 205. 通常，附加規則取決於目的地以外的其他東西（因為這已經被簡單的路由使用所涵蓋，因此很少在規則中使用），但甚至可以不依賴任何東西（僅閱讀from all lookup 205：充當簡單的覆蓋) 並且如果匹配將選擇另一個路由表：here table 205。

• 可以檢查附加的路由表

ip route show table 205

將評估此路由表，如果找到路由，則不會進行進一步處理：不會評估主表，並且會發生與主表內容不匹配的決策。它很可能會顯示類似以下內容：

default dev tun0 proto static

但由於它是關於隧道tun0並且路由隧道內容必須仍然允許在其自身外部正常路由隧道信封，因此應該在某處（在規則中或在此路由表中）允許通過以下方式到達對等隧道端點正常方式（即：使用dev wlp0s20f3）。

根據隧道的不同，並不總是需要此異常（例如：在與其隧道信封不同的網路名稱空間中使用 WireGuard，但通常會呼叫該介面wg0），並且可以針對不同的方法採用不同的形式。

引用自：https://unix.stackexchange.com/questions/697740