私の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.254インターフェイスの背後にあるデフォルトゲートウェイを介してこれを実行すると推測しますwlp0s20f3。しかし、次はそうではありません。
$ ip ro get 8.8.8.8
8.8.8.8 dev tun0 table 205 src 10.8.3.2 uid 1000
cache
説明してください。デフォルトゲートウェイを使用しないのはなぜですか？
答え1
あなたはポリシーベースのルーティングtable 205ルーティング決定に示されているように。
少なくとも、次の出力をチェックすると、より多くの情報を得ることができます。
ip ruleこのルールには、デフォルトの3つのルール（デフォルト設定は0、32766、および32767）に加えて、1つ以上のルールがあります。追加ルールは、1つ以上の追加ルーティングテーブルを参照します
table 205。通常、追加のルールはターゲット以外の項目によって異なりますが（すでに単純なルーティングの使用としてすでに扱われているため、ルールではほとんど使用されていません）、どの項目にも依存する可能性があります（読み取り専用from all lookup 205：単純なオーバーライドとして機能します）。一致する場合は、ここから別のルーティングテーブルを選択してくださいtable 205。追加のルーティングテーブルは、次のコマンドを使用して確認できます。
ip route show table 205このルートテーブルは評価され、ルートが見つかった場合は追加の処理は行われません。基本表は評価されず、基本表の内容と一致しない決定が下されます。次のような内容が表示される可能性が高いです。
default dev tun0 proto staticただし、これはトンネルとルーティングに関するものであり、トンネル
tun0エントリはまだトンネルエンベロープが外部から正常にルーティングできるようにする必要があるため、次のものを使用できるようにどこか（ルールまたはこのルーティングテーブル）に例外が必要です。トンネルエンドポイント：一般的な方法（例：使用dev wlp0s20f3）。トンネルによっては、この例外は必ずしも必要ではなく（たとえば、トンネルエンベロープとは異なるネットワーク名前空間でWireGuardを使用しますが、通常はインターフェイスが呼び出されます
wg0）、メソッドごとに異なる形式を取ることができます。