Mikrotik RouterOS における静的ルーティングの基本

ルーティングは、TCP/IP ネットワーク上でパケットを送信するための最適なパスを見つけるプロセスです。 IPv4 ネットワークに接続されているデバイスには、プロセスとルーティング テーブルが含まれています。

この記事は HOWTO ではなく、RouterOS での静的ルーティングを例とともに説明しています。残りの設定 (たとえば、インターネットにアクセスするための srcnat など) は意図的に省略しています。そのため、内容を理解するには、ネットワークと RouterOS に関するある程度の知識が必要です。

スイッチングとルーティング

スイッチングは、2 つのレイヤ 0 セグメント (イーサネット、ppp など) 内でパケットを交換するプロセスです。 デバイスは、パケットの受信者が同じイーサネット サブネット上にあることを確認すると、arp プロトコルを使用して MAC アドレスを学習し、ルーターをバイパスしてパケットを直接送信します。 ppp (ポイントツーポイント) 接続では参加者は XNUMX 人のみであり、パケットは常に XNUMX つのアドレス XNUMXxff に送信されます。

ルーティングは、レイヤー 2 セグメント間でパケットを転送するプロセスです。 デバイスが、受信者がイーサネット セグメント外にあるパケットを送信したい場合、ルーティング テーブルを調べ、次にパケットを送信する場所を知っている (または、パケットの元の送信者がわからない場合もあります) ゲートウェイにパケットを渡します。これには気づいていません）。

ルーターを考える最も簡単な方法は、2 つ以上のレイヤ XNUMX セグメントに接続され、ルーティング テーブルから最適なルートを決定することによってセグメント間でパケットを渡すことができるデバイスであると考えることです。

すべてを理解している場合、またはすでに知っている場合は、読み続けてください。 残りについては、小さいながらも非常に容量の大きいものに慣れることを強くお勧めします。 論文.

RouterOS と PacketFlow でのルーティング

静的ルーティングに関連するほぼすべての機能がパッケージに含まれています 　。 ビニール袋 ルーティング 動的ルーティング アルゴリズム (RIP、OSPF、BGP、MME)、ルーティング フィルター、および BFD のサポートを追加します。

ルーティングを設定するためのメイン メニュー: [IP]->[Route]。 複雑なスキームでは、パケットに次のルーティング マークを事前に付ける必要がある場合があります。 [IP]->[Firewall]->[Mangle] (チェーン PREROUTING и OUTPUT).

PacketFlow には、IP パケットのルーティング決定が行われる場所が XNUMX つあります。

1. ルーターが受信したパケットのルーティング。 この段階で、パケットがローカル プロセスに送られるか、さらにネットワークに送信されるかが決定されます。 トランジットパッケージの受け取り 出力インタフェース
2. ローカル送信パケットのルーティング。 送信パケットの受信 出力インタフェース
3. 発信パケットの追加ルーティング手順により、ルーティング決定を変更できるようになります。 [Output|Mangle]

• ブロック 1、2 のパケット パスは、 [IP]->[Route]
• ポイント 1、2、および 3 のパケット パスは、次のルールによって異なります。 [IP]->[Route]->[Rules]
• ブロック 1、3 のパッケージ パスは、次を使用して影響を受けることができます。 [IP]->[Firewall]->[Mangle]

RIB、FIB、ルーティング キャッシュ

ルーティング情報ベース
動的ルーティング プロトコル、ppp および dhcp からのルート、静的ルートおよび接続されたルートからルートが収集されるベース。 このデータベースには、管理者によってフィルタされたルートを除くすべてのルートが含まれます。

条件付きで、次のように仮定できます。 [IP]->[Route] RIBを表示します。

転送情報ベース

RIBからの最適なルートを集めた拠点です。 FIB 内のすべてのルートはアクティブであり、パケットの転送に使用されます。 ルートが非アクティブになると (管理者 (システム) によって無効にされた場合、またはパケットの送信に使用されるインターフェイスがアクティブではない場合)、ルートは FIB から削除されます。

ルーティングを決定するために、FIB テーブルは IP パケットに関する次の情報を使用します。

• 送信元アドレス
• 宛先アドレス
• ソースインターフェース
• ルーティングマーク
• 利用規約 (DSCP)

FIB パッケージに入るには、次の段階を経ます。

• パッケージはローカル ルーター プロセスを対象としていますか?
• パケットはシステムまたはユーザーの PBR ルールの対象ですか?
  • 「はい」の場合、パケットは指定されたルーティング テーブルに送信されます。
• パケットはメインテーブルに送信されます

条件付きで、次のように仮定できます。 [IP]->[Route Active=yes] FIBを表示します。

ルーティングキャッシュ
ルートキャッシュメカニズム。 ルータはパケットがどこに送信されたかを記憶しており、類似したパケットがある場合（おそらく同じ接続からのもの）、FIB をチェックインせずに、それらを同じルートに沿って送信させます。 ルート キャッシュは定期的にクリアされます。

RouterOS 管理者向けに、ルーティング キャッシュを表示および管理するためのツールは作成されていませんでしたが、ルーティング キャッシュを無効にできる場合は、 [IP]->[Settings].

このメカニズムは Linux 3.6 カーネルから削除されましたが、RouterOS はまだカーネル 3.3.5 を使用しています。おそらくルーティング キャッシュが理由の XNUMX つです。

ルートの追加ダイアログ

[IP]->[Route]->[+]

1. ルートを作成するサブネット (デフォルト: 0.0.0.0/0)
2. パケットの送信先となるゲートウェイ IP またはインターフェイス (複数ある場合があります。以下の ECMP を参照)
3. ゲートウェイの可用性チェック
4. レコードタイプ
5. ルートの距離 (メートル単位)
6. ルーティングテーブル
7. このルートを経由するローカル送信パケットの IP
8. スコープの目的と対象範囲は記事の最後に記載しています。

ルートフラグ

• X - ルートは管理者によって無効にされています (disabled=yes)
• A - ルートはパケットの送信に使用されます
• D - 動的に追加されたルート (BGP、OSPF、RIP、MME、PPP、DHCP、接続済み)
• C - サブネットはルーターに直接接続されています
• S - 静的ルート
• r、b、o、m - 動的ルーティング プロトコルのいずれかによって追加されたルート
• B、U、P - ルートのフィルタリング (パケットを送信せずにドロップします)

ゲートウェイに何を指定するか: IP アドレスまたはインターフェイス?

このシステムでは両方を指定できますが、間違ったことをした場合に悪口を言ったり、ヒントを与えたりすることはありません。

IPアドレス
ゲートウェイ アドレスは、Layer2 経由でアクセスできる必要があります。 イーサネットの場合、これはルーターがアクティブな IP インターフェイスの XNUMX つで同じサブネットのアドレスを持っている必要があることを意味します。ppp の場合、ゲートウェイ アドレスがアクティブなインターフェイスの XNUMX つでサブネット アドレスとして指定されることを意味します。
レイヤ 2 のアクセス条件が満たされていない場合、ルートは非アクティブとみなされ、FIB には入りません。

インターフェース
すべてがより複雑で、ルーターの動作はインターフェースのタイプによって異なります。

• PPP (非同期、PPTP、L2TP、SSTP、PPPoE、OpenVPN *) 接続は XNUMX 人の参加者のみを想定しており、パケットは常に送信のためにゲートウェイに送信されます。ゲートウェイが受信者が自分自身であることを検出すると、パケットを次の宛先に転送します。そのローカルプロセス。
  
• イーサネットは多数の参加者が存在することを想定し、パケットの受信者のアドレスを使用してリクエストを arp インターフェイスに送信します。これは予期されており、接続されたルートではごく普通の動作です。
  しかし、インターフェイスをリモート サブネットのルートとして使用しようとすると、次の状況が発生します。ルートはアクティブで、ゲートウェイへの ping は成功しますが、指定されたサブネットからの受信者に到達しません。 スニファを通じてインターフェイスを見ると、リモート サブネットからのアドレスを持つ arp リクエストが表示されます。
  

可能な限り、ゲートウェイとして IP アドレスを指定するようにしてください。 例外は、接続されたルート (自動的に作成される) と PPP (非同期、PPTP、L2TP、SSTP、PPPoE、OpenVPN*) インターフェイスです。

OpenVPN には PPP ヘッダーが含まれていませんが、OpenVPN インターフェイス名を使用してルートを作成できます。

より具体的なルート

基本的なルーティング ルール。 パケットのルーティング決定では、小さいサブネット (最大のサブネット マスクを持つ) を記述するルートが優先されます。 ルーティング テーブル内のエントリの位置は選択とは関係ありません。主なルールはより具体的なものです。

指定されたスキームからのすべてのルートがアクティブになります (FIB 内にあります)。 異なるサブネットを指しており、互いに競合しません。

ゲートウェイの XNUMX つが使用できなくなると、関連付けられたルートは非アクティブ (FIB から削除される) とみなされ、残りのルートからパケットが検索されます。

サブネット 0.0.0.0/0 のルートには特別な意味が与えられる場合があり、「デフォルト ルート」または「最後の手段のゲートウェイ」と呼ばれます。 実際、これには魔法のようなものは何もなく、考えられるすべての IPv4 アドレスが含まれているだけですが、これらの名前はそのタスクをよく表しており、他により正確なルートがないパケットを転送するゲートウェイを示しています。

IPv4 で使用できる最大のサブネット マスクは /32 で、このルートは特定のホストを指し、ルーティング テーブルで使用できます。

より具体的なルートを理解することは、TCP/IP デバイスにとって基本です。

距離

距離 (またはメトリック) は、複数のゲートウェイを介してアクセスできる単一のサブネットへのルートの管理フィルタリングに必要です。 メトリックが低いルートは優先とみなされ、FIB に含まれます。 メトリックが低いルートがアクティブでなくなると、FIB 内のメトリックがより高いルートに置き換えられます。

同じメトリックを持つ同じサブネットへのルートが複数ある場合、ルーターは内部ロジックに従って、そのうちの XNUMX つだけを FIB テーブルに追加します。

メトリックは 0 ～ 255 の値を取ることができます。

• 0 - 接続されたルートのメトリック。 距離 0 は管理者が設定できません
• 1-254 - 管理者がルートを設定するために使用できるメトリック。 値が低いメトリクスの優先度が高くなります
• 255 - 管理者がルートを設定するために使用できるメトリック。 1 ～ 254 とは異なり、メトリック 255 のルートは常に非アクティブなままであり、FIB には含まれません。
• 特定の指標。 動的ルーティング プロトコルから派生したルートには標準のメトリック値があります

ゲートウェイをチェックする

ゲートウェイの確認は、icmp または arp 経由でゲートウェイの可用性を確認するための MikroTik RoutesOS 拡張機能です。 10 秒ごとに (変更不可)、要求がゲートウェイに送信され、応答が XNUMX 回受信されない場合、ルートは使用不可とみなされ、FIB から削除されます。 ゲートウェイのチェックが無効になっている場合、パスのチェックは続行され、チェックが XNUMX 回成功するとルートが再びアクティブになります。

ゲートウェイをチェックすると、そのゲートウェイが設定されているエントリと、指定されたゲートウェイの他のすべてのエントリ (すべてのルーティング テーブルおよび ECMP ルート内) が無効になります。

一般に、ゲートウェイへのパケット損失に問題がない限り、チェック ゲートウェイは正常に動作します。 チェック ゲートウェイは、チェック ゲートウェイの外部の通信で何が起こっているかを知りません。これには、スクリプト、再帰ルーティング、動的ルーティング プロトコルなどの追加ツールが必要です。

ほとんどの VPN およびトンネル プロトコルには、接続アクティビティをチェックするためのツールが組み込まれており、それらのチェック ゲートウェイを有効にすると、ネットワークとデバイスのパフォーマンスに追加の (ただし非常に小さい) 負荷がかかります。

ECMP ルート

等コスト マルチパス - ラウンド ロビン アルゴリズムを使用して、複数のゲートウェイを同時に使用して受信者にパケットを送信します。

ECMP ルートは、管理者が XNUMX つのサブネットに複数のゲートウェイを指定することによって (または、同等の OSPF ルートが XNUMX つある場合は自動的に) 作成されます。

ECMP は XNUMX つのチャネル間の負荷分散に使用されます。理論的には、ecmp ルートに XNUMX つのチャネルがある場合、パケットごとに送信チャネルが異なる必要があります。 しかし、ルーティング キャッシュ メカニズムは、最初のパケットがたどったルートに沿って接続からパケットを送信するため、接続に基づいて一種のバランシング (接続ごとの負荷バランシング) が行われます。

ルーティング キャッシュを無効にすると、ECMP ルート内のパケットは正しく共有されますが、NAT に問題が発生します。 NAT ルールは接続からの最初のパケットのみを処理し (残りは自動的に処理されます)、同じ送信元アドレスを持つパケットは異なるインターフェイスから送信されることがわかります。

チェックゲートウェイが ECMP ルートで機能しない (RouterOS のバグ)。 ただし、ECMP のエントリを無効にする追加の検証ルートを作成することで、この制限を回避できます。

ルーティングによるフィルタリング

Type オプションは、パッケージをどう扱うかを決定します。

• ユニキャスト - 指定されたゲートウェイ (インターフェース) に送信します。
• ブラックホール - パケットを破棄します
• 禁止、到達不能 - パケットを破棄し、送信者に icmp メッセージを送信します。

フィルタリングは通常、誤った方向へのパケットの送信を保護する必要がある場合に使用されます。もちろん、これをファイアウォール経由でフィルタリングすることもできます。

いくつかの例

ルーティングに関する基本的な事項をまとめます。

一般的なホームルーター

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. 0.0.0.0/0 への静的ルート (デフォルト ルート)
2. プロバイダとのインターフェース上の接続ルート
3. LANインターフェース上の接続経路

PPPoEを備えた一般的なホームルーター

1. デフォルト ルートへのスタティック ルート。自動的に追加されます。 接続プロパティで指定されます
2. PPP接続の接続経路
3. LANインターフェース上の接続経路

XNUMX つのプロバイダーと冗長性を備えた一般的なホーム ルーター

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. メトリック 1 とゲートウェイ可用性チェックを持つ最初のプロバイダーを経由するデフォルト ルートへの静的ルート
2. メトリック 2 の XNUMX 番目のプロバイダーを経由するデフォルト ルートへの静的ルート
3. 接続ルート

0.0.0.0/0 へのトラフィックは、このゲートウェイが使用可能な間は 10.10.10.1 を通過し、それ以外の場合は 10.20.20.1 に切り替わります。

このような方式はチャネル予約と見なすことができますが、欠点がないわけではありません。 プロバイダーのゲートウェイの外側 (たとえば、オペレーターのネットワーク内) で切断が発生した場合、ルーターはそれを認識せず、引き続きそのルートをアクティブであると見なします。

冗長性と ECMP の XNUMX つのプロバイダーを備えた一般的なホーム ルーター

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. チェックゲートウェイをチェックするための静的ルート
2. ECMPルート
3. 接続ルート

チェックするルートは青色 (非アクティブなルートの色) ですが、これはチェック ゲートウェイに干渉しません。 RoS の現在のバージョン (6.44) では、ECMP ルートに自動的に優先順位が与えられますが、他のルーティング テーブルにテスト ルートを追加することをお勧めします (オプション) routing-mark)

Speedtest や他の同様のサイトでは速度は向上しません (ECMP はパケットではなく接続ごとにトラフィックを分割します) が、p2p アプリケーションのダウンロードは速くなります。

ルーティングによるフィルタリング

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. スタティックルートからデフォルトルートへ
2. ipip トンネル経由の 192.168.200.0/24 への静的ルート
3. ISP ルーター経由の 192.168.200.0/24 への静的ルートの禁止

ipip インターフェイスが無効になっている場合、トンネル トラフィックがプロバイダーのルーターに送信されないフィルタリング オプション。 このようなスキームが必要になることはほとんどありません。 ファイアウォールを介したブロックを実装できます。

ルーティングループ
ルーティング ループ - ttl が期限切れになる前にパケットがルーター間で実行される状況。 通常、これは構成エラーの結果ですが、大規模なネットワークでは動的ルーティング プロトコルの実装によって処理され、小規模なネットワークでは注意が必要です。

それはこのように見えます：

同様の結果を得る方法の (最も単純な) 例:

ルーティング ループの例は実際には役に立ちませんが、ルータが近隣ルーティング テーブルについて何も知らないことを示しています。

ポリシーベースルーティングと追加ルーティングテーブル

ルートを選択するとき、ルーターはパケット ヘッダーの XNUMX つのフィールド (宛先アドレス) のみを使用します。これが基本的なルーティングです。 送信元アドレス、トラフィックの種類 (ToS)、ECMP を使用しないバランシングなどの他の条件に基づくルーティングは、ポリシー ベース ルーティング (PBR) に属し、追加のルーティング テーブルを使用します。

より具体的なルート は、ルーティング テーブル内の主要なルート選択ルールです。

デフォルトでは、すべてのルーティング ルールがメイン テーブルに追加されます。 管理者は、任意の数の追加ルーティング テーブルを作成し、そこにパケットをルーティングできます。 異なるテーブルのルールは互いに競合しません。 パッケージは、指定されたテーブル内に適切なルールが見つからない場合、メイン テーブルに移動します。

ファイアウォール経由での配布の例:

• 192.168.100.10-> 8.8.8.8
  1. 192.168.100.10 からのトラフィックにラベルが付けられます ISP1経由 в [Prerouting|Mangle]
  2. テーブルのルーティング段階で ISP1経由 8.8.8.8へのルートを検索します
  3. ルートが見つかりました。トラフィックはゲートウェイ 10.10.10.1 に送信されます
• 192.168.200.20-> 8.8.8.8
  1. 192.168.200.20 からのトラフィックにラベルが付けられます ISP2経由 в [Prerouting|Mangle]
  2. テーブルのルーティング段階で ISP2経由 8.8.8.8へのルートを検索します
  3. ルートが見つかりました。トラフィックはゲートウェイ 10.20.20.1 に送信されます
• ゲートウェイの 10.10.10.1 つ (10.20.20.1 または XNUMX) が使用できなくなると、パケットはテーブルに送られます。 メイン そこで適切なルートを探します

用語の問題

RouterOS には特定の用語の問題があります。
でルールを操作する場合 [IP]->[Routes] ルーティング テーブルが示されていますが、ラベルには次のように書かれています。

В [IP]->[Routes]->[Rule] テーブルアクションのラベル条件はすべて正しいです。

特定のルーティング テーブルにパケットを送信する方法

RouterOS にはいくつかのツールが用意されています。

• のルール [IP]->[Routes]->[Rules]
• ルートマーカー (action=mark-routing）で [IP]->[Firewall]->[Mangle]
• VRF

規制 [IP]->[Route]->[Rules]
ルールは順番に処理され、パケットがルールの条件に一致する場合、それ以上通過しません。

ルーティング ルールを使用すると、受信者のアドレスだけでなく、送信元アドレスやパケットを受信したインターフェイスにも依存して、ルーティングの可能性を拡張できます。

ルールは条件とアクションで構成されます。

• 条件。 実際には、FIB でパッケージをチェックするための標識のリストを繰り返します。ToS だけが欠落しています。
• 活動
  • lookup - パケットをテーブルに送信します
  • テーブル内のみ検索 - テーブル内のパッケージをロックします。ルートが見つからない場合、パッケージはメイン テーブルに移動しません。
  • ドロップ - パケットをドロップします
  • 到達不能 - 送信者通知とともにパケットを破棄します

FIB では、ローカル プロセスへのトラフィックはルールをバイパスして処理されます。 [IP]->[Route]->[Rules]:

マーキング [IP]->[Firewall]->[Mangle]
ルーティング ラベルを使用すると、ほぼすべてのファイアウォール条件を使用してパケットのゲートウェイを設定できます。

実際には、それらすべてが意味をなすわけではなく、一部は不安定に動作する可能性があるためです。

パッケージにラベルを付けるには XNUMX つの方法があります。

• すぐに入れる ルーティングマーク
• 最初に置く 接続マーク、次に基づいて 接続マーク 設定する ルーティングマーク

ファイアウォールに関する記事で、私は XNUMX 番目のオプションが望ましいと書きました。 ルートをマークする場合、CPU の負荷が軽減されますが、これは完全に真実ではありません。 これらのマーキング方法は必ずしも同等であるとは限らず、通常はさまざまな問題を解決するために使用されます。

使用例

ポリシー ベース ルーティングの使用例に移りましょう。これが必要な理由を示すのがはるかに簡単です。

MultiWAN と戻りの発信 (出力) トラフィック
MultiWAN 構成に関する一般的な問題: Mikrotik は、「アクティブな」プロバイダーを介してのみインターネットから利用できます。

ルーターは、要求がどの IP に送信されたかを気にせず、応答を生成するときに、isp1 を経由するルートがアクティブであるルーティング テーブル内のルートを探します。 さらに、そのようなパケットは受信者に届くまでの過程でフィルタリングされる可能性が高くなります。

もう一つ興味深い点があります。 「単純な」ソース nat が ether1 インターフェイスに設定されている場合: /ip fi nat add out-interface=ether1 action=masquerade パッケージは src を使用してオンラインになります。 address=10.10.10.100、これは事態をさらに悪化させます。

この問題を解決するにはいくつかの方法がありますが、いずれの方法でも追加のルーティング テーブルが必要になります。

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

使用 [IP]->[Route]->[Rules]
指定された送信元 IP を持つパケットに使用されるルーティング テーブルを指定します。

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

使用できます action=lookupただし、ローカル発信トラフィックの場合、このオプションは間違ったインターフェイスからの接続を完全に除外します。

• システムは Src を含む応答パケットを生成します。 住所: 10.20.20.200
• ルーティング決定(2) ステップのチェック [IP]->[Routes]->[Rules] そしてパケットはルーティングテーブルに送信されます over-isp2
• ルーティング テーブルによれば、パケットは ether10.20.20.1 インターフェイス経由でゲートウェイ 2 に送信される必要があります。

この方法では、Mangle テーブルを使用する場合とは異なり、動作する Connection Tracker は必要ありません。

使用 [IP]->[Firewall]->[Mangle]
接続は受信パケットで始まるため、それにマークを付けます (action=mark-connection)、マークされた接続からの送信パケットに対して、ルーティング ラベル (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

XNUMX つのインターフェイスに複数の IP が設定されている場合は、条件に追加できます。 dst-address 念のため。

• パケットは、ether2 インターフェイス上で接続を開きます。 パッケージは入ります [INPUT|Mangle] これは、接続からのすべてのパケットを次のようにマークすることを示しています from-isp2
• システムは Src を含む応答パケットを生成します。 住所: 10.20.20.200
• ルーティング決定(2) ステージでは、パケットはルーティング テーブルに従って、ether10.20.20.1 インターフェイスを介してゲートウェイ 1 に送信されます。 これを確認するには、パッケージにログインします。 [OUTPUT|Filter]
• ステージ上 [OUTPUT|Mangle] 接続ラベルがチェックされています from-isp2 そしてパケットはルートラベルを受け取ります over-isp2
• ルーティング調整(3) ステップでは、ルーティング ラベルの存在を確認し、それを適切なルーティング テーブルに送信します。
• ルーティング テーブルによれば、パケットは ether10.20.20.1 インターフェイス経由でゲートウェイ 2 に送信される必要があります。

MultiWAN とリターン dst-nat トラフィック

より複雑な例は、プライベート サブネット上のルーターの背後にサーバー (Web など) があり、プロバイダー経由でサーバーへのアクセスを提供する必要がある場合にどうするかです。

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

問題の本質は同じで、解決策は Firewall Mangle オプションと似ており、他のチェーンのみが使用されます。

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

この図には NAT が示されていませんが、すべてが明らかだと思います。

MultiWAN とアウトバウンド接続

PBR 機能を使用すると、異なるルーター インターフェイスから複数の VPN (この例では SSTP) 接続を作成できます。

追加のルーティング テーブル:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

パッケージのマーキング:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

単純な NAT ルール。そうでない場合、パケットは間違った Src でインターフェイスから送信されます。 住所：

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

解析：

• ルーターは XNUMX つの SSTP プロセスを作成します
• ルーティング決定 (2) 段階では、メイン ルーティング テーブルに基づいてこれらのプロセスのルートが選択されます。 同じルートからパケットは Src を受信します。 ether1 インターフェイスにバインドされたアドレス
• В [Output|Mangle] 異なる接続からのパケットは異なるラベルを受け取ります
• パケットはルーティング調整段階でラベルに対応するテーブルに入り、パケットを送信するための新しいルートを受け取ります。
• ただし、パッケージにはまだ Src があります。 ether1 のステージ上の演説 [Nat|Srcnat] アドレスはインターフェースに従って置き換えられます

興味深いことに、ルーターには次の接続テーブルが表示されます。

接続トラッカーが早期に機能する [Mangle] и [Srcnat]したがって、すべての接続は XNUMX つのアドレスから来ているため、さらに詳しく見ると、 Replay Dst. Address NAT の後にアドレスが存在します。

VPN サーバー (テストベンチに XNUMX つあります) では、すべての接続が正しいアドレスから来ていることがわかります。

途中で待ってください
もっと簡単な方法があります。各アドレスに特定のゲートウェイを指定するだけです。

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

しかし、そのようなルートは発信トラフィックだけでなく通過トラフィックにも影響を与えます。 さらに、VPN サーバーへのトラフィックが不適切な通信チャネルを通過する必要がない場合は、さらに 6 つのルールを追加する必要があります。 [IP]->[Routes]с type=blackhole。 前のバージョンでは - 3 つのルール [IP]->[Route]->[Rules].

通信チャネル別のユーザー接続の分布

単純な日常のタスク。 ここでも、追加のルーティング テーブルが必要になります。

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

使い方 [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

使うなら action=lookup、チャネルの XNUMX つが無効になると、トラフィックはメイン テーブルに送られ、作業チャネルを通過します。 これが必要かどうかはタスクによって異なります。

でのマーキングの使用 [IP]->[Firewall]->[Mangle]
IP アドレスのリストを使用した簡単な例。 原則として、ほぼすべての条件を使用できます。 Layer7 の唯一の注意点は、接続ラベルと組み合わせた場合でも、すべてが正しく機能しているように見えても、一部のトラフィックは依然として間違った方向に進むことです。

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

XNUMX つのルーティング テーブルでユーザーを「ロック」できます。 [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

どちらかを通して [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

リトリートプロ dst-address-type=!local
追加条件 dst-address-type=!local ユーザーからのトラフィックがルーターのローカル プロセス (DNS、winbox、ssh など) に到達する必要があります。 複数のローカル サブネットがルーターに接続されている場合は、たとえば次のコマンドを使用して、それらの間のトラフィックがインターネットに送信されないようにする必要があります。 dst-address-table.

を使用した例では、 [IP]->[Route]->[Rules] そのような例外はありませんが、トラフィックはローカル プロセスに到達します。 実際には、でマークされた FIB パッケージに入るということです。 [PREROUTING|Mangle] にはルート ラベルがあり、ローカル インターフェイスが存在しないメイン以外のルーティング テーブルに入ります。 ルーティング ルールの場合、最初にパケットがローカル プロセス向けであるかどうかがチェックされ、ユーザー PBR 段階でのみ指定されたルーティング テーブルに送信されます。

使い方 [IP]->[Firewall]->[Mangle action=route]
このアクションは次の場合にのみ機能します。 [Prerouting|Mangle] また、ゲートウェイ アドレスを直接指定することで、追加のルーティング テーブルを使用せずに、指定したゲートウェイにトラフィックを送信できます。

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

アクション route ルーティング ルールよりも優先度が低くなります ([IP]->[Route]->[Rules]）。 ルート マークの場合、すべてはルールの位置に依存します。 action=route 以上の価値がある action=mark-route、その後、それが使用されます（フラグに関係なく） passtrough)、それ以外の場合はルートをマークします。
このアクションに関する Wiki には情報がほとんどなく、すべての結論は実験的に得られたものですが、いずれにしても、このオプションを使用すると他のオプションよりも利点があるというオプションが見つかりませんでした。

PPC ベースの動的バランシング

Per Connection Classifier - ECMP のより柔軟な類似物です。 ECMP とは異なり、トラフィックを接続ごとにより厳密に分割します (ECMP は接続については何も知りませんが、ルーティング キャッシュと組み合わせると、同様の結果が得られます)。

PCC はかかります 指定されたフィールド ip ヘッダーから取得し、32 ビット値に変換し、で除算します。 分母。 除算の余りが指定された値と比較されます。 残り それらが一致する場合、指定されたアクションが適用されます。 もっと。 クレイジーに聞こえるかもしれませんが、うまくいきます。

XNUMX つのアドレスの例:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

XNUMX つのチャネル間の src.address によるトラフィックの動的分散の例:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

ルートをマークする場合、追加の条件があります。 in-interface=br-lan、下にない場合 action=mark-routing インターネットからの応答トラフィックは受信され、ルーティング テーブルに従ってプロバイダーに戻ります。

通信チャネルの切り替え

Check ping は優れたツールですが、最も近い IP ピアとの接続のみをチェックします。通常、プロバイダー ネットワークは多数のルーターで構成されており、最も近いピアの外側で接続の切断が発生する可能性があります。また、バックボーン通信事業者も同様に接続を切断する可能性があります。問題がある場合、一般に、ping をチェックしても、グローバル ネットワークへのアクセスに関する最新情報が常に表示されるわけではありません。
プロバイダーや大企業が BGP ダイナミック ルーティング プロトコルを導入している場合、家庭やオフィスのユーザーは、特定の通信チャネルを介してインターネット アクセスを確認する方法を独自に見つけ出す必要があります。

通常、特定の通信チャネルを通じてインターネット上の IP アドレスの可用性をチェックし、信頼できるもの (Google DNS: 8.8.8.8 など) を選択するスクリプトが使用されます。 8.8.4.4。 しかし、Mikrotik コミュニティでは、より興味深いツールがこれに適応されています。

再帰ルーティングについて一言
マルチホップ BGP ピアリングを構築する場合、再帰的ルーティングが必要であり、スタティック ルーティングの基本に関する記事に取り上げられたのは、チェック ゲートウェイと組み合わせた再帰的ルートを使用して、追加のスクリプトを使用せずに通信チャネルを切り替える方法を見つけ出した狡猾な MikroTik ユーザーのおかげです。

ここで、スコープ/ターゲット スコープのオプションを一般的に理解し、ルートがインターフェイスにどのようにバインドされるかを理解します。

1. ルートは、スコープ値と、ターゲット スコープ値以下のメイン テーブル内のすべてのエントリに基づいて、パケットを送信するインターフェイスを検索します。
2. 検索されたインターフェースの中から、指定したゲートウェイにパケットを送信できるインターフェースが選択されます
3. 見つかった接続エントリのインターフェイスが選択され、ゲートウェイにパケットが送信されます。

再帰ルートが存在する場合、すべてが同じように起こりますが、次の XNUMX つの段階で行われます。

• 1-3 接続されているルートに、指定したゲートウェイに到達できるルートをもう XNUMX つ追加します
• 4-6 「中間」ゲートウェイの接続ルートを検索する

再帰的検索によるすべての操作は RIB で行われ、最終結果のみが FIB に転送されます。 0.0.0.0/0 via 10.10.10.1 on ether1.

再帰ルーティングを使用して経路を切り替える例

構成：

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

パケットが 10.10.10.1 に送信されることを確認できます。

チェック ゲートウェイは再帰ルーティングについて何も認識せず、アドレス 8.8.8.8 に ping を送信するだけです。このアドレスは (メイン テーブルに基づくと) ゲートウェイ 10.10.10.1 経由で到達可能です。

10.10.10.1 と 8.8.8.8 の間の通信が失われると、ルートは切断されますが、8.8.8.8 へのパケット (テスト ping を含む) は引き続き 10.10.10.1 を通過します。

ether1 へのリンクが失われると、8.8.8.8 より前のパケットが XNUMX 番目のプロバイダーを通過するときに不快な状況が発生します。

これは、8.8.8.8 が使用できないときに NetWatch を使用してスクリプトを実行している場合に問題になります。 リンクが壊れた場合、NetWatch はバックアップ通信チャネルを介して動作し、すべてが正常であると想定します。 追加のフィルター ルートを追加することで解決しました。

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

ハブレにはあります 記事ここでは、NetWatch の状況をより詳細に検討します。

そして、そのような予約を使用する場合、アドレス 8.8.8.8 はプロバイダーの XNUMX つにハードコーディングされるため、それを DNS ソースとして選択することは得策ではありません。

仮想ルーティングおよび転送 (VRF) について一言

VRF テクノロジーは、3 つの物理ルーター内に複数の仮想ルーターを作成するように設計されており、このテクノロジーは通信事業者によって (通常は MPLS と組み合わせて) 重複するサブネット アドレスを持つクライアントに LXNUMXVPN サービスを提供するために広く使用されています。

ただし、Mikrotik の VRF はルーティング テーブルに基づいて編成されており、多くの欠点があります。たとえば、ルーターのローカル IP アドレスはすべての VRF から利用できます。 リンク.

VRF 設定例:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

ether2 に接続されているデバイスからは、ping が別の VRF からルーター アドレスに送信されていることがわかります (これが問題です)。一方、ping はインターネットには送信されていません。

インターネットにアクセスするには、メイン テーブルにアクセスする追加のルートを登録する必要があります (VRF 用語では、これをルート リークと呼びます)。

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

ルート リークには、ルーティング テーブルを使用する XNUMX つの方法があります。 172.17.0.1@main そしてインターフェース名を使用します: 172.17.0.1%wlan1.

そしてリターントラフィックのマーキングを設定します [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

同じアドレスを持つサブネット
VRF とネットマップを使用した、同じルーター上の同じアドレスを持つサブネットへのアクセスの構成:

基本構成:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

ファイアウォールのルール:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

戻りトラフィックのルーティング ルール:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

dhcp 経由で受信したルートを特定のルーティング テーブルに追加する
VRF は、動的ルート (たとえば、dhcp クライアントから) を特定のルーティング テーブルに自動的に追加する必要がある場合に役立ちます。

VRF へのインターフェイスの追加:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

テーブルを介してトラフィック（送信および通過）を送信するためのルール over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

送信ルーティングが機能するための追加の偽のルート:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

このルートは、ローカル発信パケットがルーティング決定 (2) を通過できるようにするためにのみ必要です。 [OUTPUT|Mangle] ルーティング ラベルを取得します。メイン テーブルの 0.0.0.0/0 より前にルーター上に他のアクティブなルートがある場合、これは必要ありません。

チェーン connected-in и dynamic-in в [Routing] -> [Filters]

ルート フィルタリング (受信および送信) は、通常、動的ルーティング プロトコルと組み合わせて使用​​されるツールです (したがって、パッケージのインストール後にのみ使用可能です) ルーティング) ですが、受信フィルターには XNUMX つの興味深いチェーンがあります。

• Connected-in — 接続されたルートのフィルタリング
• Dynamic-in - PPP および DCHP によって受信された動的ルートのフィルタリング

フィルタリングを使用すると、ルートを破棄するだけでなく、距離、ルーティング マーク、コメント、スコープ、ターゲット スコープなどの多くのオプションを変更することもできます。

これは非常に正確なツールであり、ルーティング フィルターを使用せずに何かを実行できる (ただしスクリプトは使用できない) 場合は、ルーティング フィルターを使用しないでください。また、自分自身と、後でルーターを構成する人たちを混乱させないでください。 動的ルーティングのコンテキストでは、ルーティング フィルターはより頻繁に、より生産的に使用されます。

動的ルートのルーティングマークの設定
ホームルーターの例。 XNUMX つの VPN 接続が構成されており、それらのトラフィックはルーティング テーブルに従ってラップされる必要があります。 同時に、インターフェイスがアクティブ化されたときにルートが自動的に作成されるようにします。

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

理由はわかりませんが、おそらくバグですが、ppp インターフェイスの VRF を作成すると、0.0.0.0/0 へのルートがメイン テーブルに入ります。 そうでなければ、すべてがさらに簡単になるでしょう。

接続されたルートの無効化
場合によってはこれが必要になります。

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

デバッグツール

RouterOS には、ルーティングをデバッグするためのツールが多数用意されています。

• [Tool]->[Tourch] - インターフェイス上のパケットを表示できます
• /ip route check - パケットがどのゲートウェイに送信されるかを確認できますが、ルーティング テーブルでは機能しません
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - 指定されたルーティング テーブルを使用した ping とトレース
• action=log в [IP]->[Firewall] - パケット フローに沿ってパケットのパスを追跡できる優れたツール。このアクションはすべてのチェーンとテーブルで利用できます。

出所： habr.com