Linuxルートタイプ、ルーティングテーブル、およびPBR
何が起こっているかの本質を理解する前に、Linuxネットワークスタックの特徴的な機能のいくつかを紹介します。
最初の特徴的なポイントは、特別なタイプのルートです。 IPパケットがいずれかのインターフェイスから送信された場合、このホストにアドレス指定されているか、別のホストにアドレス指定されているかを判断する必要があります。 これは非常にエレガントに決定されます-宛先アドレスについてのみ、目的のルートがルーティングテーブルで検索されます。 パケットが「ローカル」タイプのルートに到着した場合、ホストに直接アドレス指定されます。そうでない場合は、さらにルーティングする必要があります（追加のルートはすでにわかっています）。
現在、いくつかのタイプのルートがサポートされています（詳細については、ip-routeマナを参照してください。マナがない場合は、iprouteパッケージを最新のものに更新してください）。 現在、次のタイプのルートのみに関心があります。
- ユニキャストは通常のルートです。 面白くない。
- local-宛先アドレスはこのホスト上にあります。 パケットがこのルートに該当することが判明した後、適切なソケットを検索します。
- ブロードキャスト-ブロードキャストルート。 このルートに到着する着信パケットの場合、ブロードキャストパケットを無視する追加のチェックを除き、実際にはローカルルートとの違いはありません。 発信については、わずかな違いがあります。データリンク層のヘッダーでは、ブロードキャストネットワークを使用するときに、ブロードキャストの宛先アドレスも設定されます。
- 到達不能-ルートを禁止します。 このルートに該当するパケットの場合、使用不可メッセージを含むicmpパケットが送信者に送信されます。
- 禁止-到達不能と同様に、別のメッセージのみが送信されます。
- ブラックホール-このルート上のパケットは静かにドロップされます
したがって、中継パケットのルーティングには、ユニキャストタイプのルートがあれば十分です。また、ホストがパケットに応答できるようにするには、ローカルタイプ、およびオプションでブロードキャストタイプのルートも必要です。 また、近隣ルーターとの接続を確保するために、直接接続されたネットワークルートも必要であることも考慮に入れる必要があります。
ルートはルーティングテーブルにグループ化されます。 デフォルトでは、システムには最初に3つのテーブルがあります。
- local（255）-このテーブルには、ローカルおよびブロードキャストルートが含まれます。 このテーブルは自動的に維持され、インターフェイスに割り当てられたアドレスに基づいて生成されます。
- main（254）-メインルーティングテーブル。 直接接続されたルートが自動的に追加されます。 また、ルーティングテーブルがipユーティリティパラメータで指定されていない場合、メインテーブルが想定されます。
- default（253）-デフォルトルートのテーブル。 その使用は根付いていないため、原則として常に空です。
テーブル名は、ファイル/ etc / iproute2 / rt_tablesに保存されます。 テーブル番号の下に32ビットが与えられていますが、現在、テーブルの最大数は256に厳密に制限されています。ルートを追加/削除/編集する方法は、ip-routeのマナで読むことができます。
ルートを検索するテーブルは、ルーティングポリシーによって決定されます。 このテクノロジーは、ポリシーベースルーティングと呼ばれます。 その本質は、ネットワークパケットの基準に基づいて、ルートを検索するテーブルを選択するか、パケットで実行する必要があるアクションを決定することです。 各ポリシーには番号があり（一意でなくてもかまいません）、優先度も決定します。 ポリシーは優先度の昇順で確認されます。 既存のポリシーの前に新しいポリシーが追加されます。
現在、ポリシーの「基準」は次のとおりです。
- 送信元および/または宛先アドレス
- tosフィールド値
- パケットの受信元のインターフェース
- ソケットがバインドされているインターフェース
- ファイアウォールラベル
各ポリシーには、パッケージがその下にある場合のアクションを定義するタイプがあります。
- ユニキャスト-デフォルトで使用されます。指定されたルーティングテーブルでルートを検索します。
- ブラックホール/禁止/到達不能-アクションは、対応するタイプのルートに似ています。
- nat-状態に関係なく、実際には使用されないアドレスの変換。
テーブル内のルートをロックする
退屈な紹介の後の小さな実用的な例です。 まず、vrf-liteを使用してスキームを手動で実装し、動的ルーティングの例を複雑にします。
このスキームがあるとしましょう：
タスクは、異なる「色」のトラフィックを互いに分離することです。 同時に、色のアドレス空間が交差する可能性があるため、タスクがさらに面白くなります。 非公式に目標を策定します。各色のパケットがルーティングテーブルの制限を超えないようにし、各色のインターフェイスを介してのみ送信されるようにします。
これを行うために、各色ごとに独自のルーティングテーブルを作成し、便宜上、名前を付けます。 次に、色関連インターフェイスの直接接続されたルートをテーブルに追加します。 最後に、パケットが独自のテーブルのみを使用するようにルーティングポリシーを追加します。
最初に、インターフェイスにアドレスを割り当てます。 この場合、接続されたルートはメインテーブルに、ローカルおよびブロードキャストルートはローカルテーブルに分類されます。
ip address add 192.168.0.1/24 dev eth0 ip address add 192.168.1.1/24 dev eth1 ip address add 192.168.2.1/24 dev eth2 ip address add 192.168.3.1/24 dev eth3
便宜上、ルーティングテーブル名を追加します。
echo "10 RED" >> /etc/iproute2/rt_tables echo "20 GREEN" >> /etc/iproute2/rt_tables
対応するテーブルに直接ルートを追加します。 これは、近隣のルーターが利用できるようにするために必要です。
ip route add 192.168.0.0/24 dev eth0 proto static scope link table RED ip route add 192.168.1.0/24 dev eth1 proto static scope link table GREEN ip route add 192.168.2.0/24 dev eth2 proto static scope link table GREEN ip route add 192.168.3.0/24 dev eth3 proto static scope link table RED
残りのルートを追加します。
ip route add 10.0.0.0/24 via 192.168.2.10 dev eth2 proto static table GREEN
ポリシーを追加します。
ip rule add iif eth0 pref 10 lookup RED ip rule add iif eth3 pref 10 lookup RED ip rule add iif eth1 pref 20 lookup GREEN ip rule add iif eth2 pref 20 lookup GREEN
注意点が1つあります。同じ色のパケットがテーブル内でルートを見つけられない場合はどうなりますか？ これは、他のテーブルでルートの検索が続行されることを意味しますが、これは私たちにとってあまり良くありません。 色内でパッケージを「ロック」するには、分離された各テーブルにデフォルトルート（ユニキャストまたは拒否）を追加するか、色内の各ルート検索ポリシーの後に拒否ポリシーを追加します。 1つの色に対して最初のオプションを作成し、もう1つの色に対して2番目のオプションを作成します。
ip route add unreachable default proto static table RED ip rule add unreachable iif eth1 pref 21 ip rule add unreachable iif eth2 pref 21
また、すべてのローカルルートとブロードキャストルートをローカルテーブルから対応する色のテーブルに転送することをお勧めします。そのため、「異国」の色からルーターのローカルインターフェイスにアクセスすることはできません。 これを行うには、それがそれほど疲れないように、ある種のスクリプトを書くことが最善です。
その結果、ルーティングテーブルとポリシーは次のようになります。
ip route list table RED unreachable default proto static broadcast 192.168.0.0 dev eth0 proto static scope link 192.168.0.0/24 dev eth0 proto static scope link local 192.168.0.1 dev eth0 proto static scope host src 192.168.0.1 broadcast 192.168.0.255 dev eth0 proto static scope link broadcast 192.168.3.0 dev eth3 proto static scope link 192.168.3.0/24 dev eth3 proto static scope link local 192.168.3.1 dev eth3 proto static scope host src 192.168.3.1 broadcast 192.168.3.255 dev eth3 proto static scope link ip route list table GREEN 10.0.0.0/8 via 192.168.2.10 dev eth2 proto static broadcast 192.168.1.0 dev eth1 proto static scope link 192.168.1.0/24 dev eth1 proto static scope link local 192.168.1.1 dev eth1 proto static scope host src 192.168.1.1 broadcast 192.168.1.255 dev eth1 proto static scope link broadcast 192.168.2.0 dev eth2 proto static scope link 192.168.2.0/24 dev eth2 proto static scope link local 192.168.2.1 dev eth2 proto static scope host src 192.168.2.1 broadcast 192.168.2.255 dev eth2 proto static scope link ip rule list 0: from all lookup local 10: from all iif eth0 lookup 10 10: from all iif eth3 lookup 10 20: from all iif eth1 lookup 20 20: from all iif eth2 lookup 20 21: from all iif eth1 unreachable 21: from all iif eth2 unreachable 32766: from all lookup main 32767: from all lookup default
GNS3で組み立てられたスタンドは、回路の正しい動作を示しました。 外国の色にアクセスすると、送信者は意図したとおりに宛先が使用できないことに関するメッセージを受け取ります。
今のところはこれですべてですが、継続します。 その中で、バードルーティングデーモンを使用したvrfに関連した動的ルーティング、およびテーブル間のルート交換（vrfリーク）について説明しようとします。