RTLINKを使用してLinuxカーネル(ネットワークネームスペース)で使用可能なIPパスを照会すると、あるテストシステムでRTLINKが属性のないパス、RTA_OIF
つまり発信ネットワークインターフェースが指定されていないパスを返したことがわかりました。
残念ながら、私はコマンドを使用して(テストのために)この状況を再現する方法を知りませんip route add
。ありません。相互作用。 Linuxカーネルのソースコードを見てみると、出てくるネットワークインタフェースのプロパティが実際にはオプションであることがわかりました。しかし、私の試みは、常に出ip route add
てくるネットワークインターフェイスがカーネルによって自動的に追加またはアクセスできないことで終わります。
ip route add 1.1.1.1/32 via 1.1.1.2
与えられたRTNETLINK answers: Network is unreachable
。
次の(失敗した)試み:
ip addr add 1.1.1.2/32 dev ens33
ip route add 1.1.1.1/32 via 1.1.1.2
ip route show
...その後、1.1.1.1 via 1.1.1.2 dev ens33
カーネルは自動的に適切な発信ネットワークインターフェイスを挿入します(したがって、RTA_OIF
最初に指定しなかったにもかかわらず存在します)。
「発信インターフェイスを持たないlinux ipパス」または同様の検索は、ここで重要なことを見落とさない限り、有用な結果を提供しません。
それでは、発信ネットワークインターフェイスなしでIPパスを持つ(テスト)ケースをどのように生成しますか?私はここで何を見落としていますか?
答え1
発信ネットワークインターフェイス(ルーティング関連のルールではない)を持たないルーティングは、少なくとも3つのユースケースに役立つことがわかりました。
- いわゆるブラックホールルートが指定されると、IP スタックはそのルートに一致するすべてのトラフィックを自動的に破棄します。
- アクセスできないIPスタックがそのルートに向かうすべてのトラフィックを破棄し、追加のICMP(v6)に接続できない応答をトリガーするルート。
- 禁止するIPスタックは再びすべてのトラフィックへのルートを破棄し、ICMP(v6)応答も送信しますが、今回は「アクセスできません」ではなく「禁止」です。
これらのパスは次のように簡単に作成できます。
# ip route add blackhole 1.2.3.4
# ip route add unreachable 1.2.3.5
# ip route add prohibit 1.2.3.6
次に、次のパスip route show
への発信ネットワークインターフェイスがないことを確認します。
$ ip route show
...
blackhole 1.2.3.4
unreachable 1.2.3.5
prohibit 1.2.3.6