MikroTikのデュアルWanおよびNetWatch実装機能

「Mikrotikが単純な構成で機能しない場合、調理方法がわからない...または明らかに何かを見逃した」







フェールオーバーとネットウォッチの連携方法 内部からの外観。



多かれ少なかれ成長している企業のほとんどが、コミュニケーションの質を求め始めています。 とりわけ、顧客はフォールトトレラントな「デュアルWAN」とVoIPテレフォニーを求めています。 もちろん、耐障害性もあります。 各トピックに関する多くのガイドと記事が別々に書かれていますが、突然すべての人が最初と2番目を組み合わせることができるわけではないことが判明しました。



Habréの記事「Mikrotik。 フェイルオーバー。 ロードバランシング」 by vdemchuk 。 判明したように、多くのルーターのコピー/貼り付けコードのソースとして機能しました。



優れた有効なソリューションですが、NATを介して外部IP-PBXに接続しているLANからのSIPクライアントは、切り替え時に接続を失いました。 問題は既知です。 これは、外部の既存の接続を記憶し、他の条件に関係なく状態を保存する接続トラッカーの機能と接続されています。



パケットフロー図を見ると、これが起こる理由を理解できます。







中継トラフィックの場合、接続トラッカーの処理手順は、ルートと発信インターフェイスを選択する前に、1つのチェーン（事前ルーティング（ルーティングの前））でのみ実行されます。 この段階では、パケットがインターネットに送信されるインターフェースはまだ不明であり、いくつかのWanインターフェースでsrc-ipを追跡することは不可能です。 このメカニズムは、事後的に確立された接続をキャプチャします。 パケットが接続を通過するまで、または指定されたタイムアウトの期限が切れるまで、しばらくの間修正して記憶します。

---

説明されている動作は、MikroTikルーターだけでなく、NATを実行しているほとんどのLinuxベースのシステムでも一般的です。

---

その結果、WAN1を介した接続が中断されると、データストリームは素直にWAN2を介してルーティングされます。 接続トラッカーにはすでに対応するエントリがあります。 当然、そのようなパケットへの回答はWAN1インターフェイスに送られますが、WAN1インターフェイスはすでに外部との接続を失っています。 結局、接続はそこにあるように見えますが、実際にはそうではありません。 この場合、すべての新しい接続が正しく確立されます。



ヒント：NATがどのアドレスからどのアドレスに送信されるかは、「Reply Src。 アドレスおよび返信先 アドレス」。 これらの列の表示は、マウスの右ボタンを使用して「接続」テーブルで有効にします。







一見したところ、出力は非常に単純に見えます-切り替え時に、以前に確立されたSIP接続をリセットして、すでに新しいSRC-IPで再確立されます。 幸いなことに、インターネット上の簡単なスクリプトはさまよいます。

失敗する3つのステップ

最初のステップ。 コピーパスツールは、フェールオーバー再帰ルーティングの構成を忠実に転送します。





ステップ2 切り替えイベントを追跡します。 なに？ 「/ツールネットウォッチ」は自然に！ WAN1ゲートウェイの落下を追跡しようとすると、通常次のようになります。





ステップ3 検証



管理者は最初のアップリンクWAN1を消滅させ、スクリプトを手動で実行します。 SIPクライアントが再接続しました。 動作しますか？ 動作します！

管理者はWAN1に切り替え、スクリプトを手動で実行します。 SIPクライアントが再接続しました。 動作しますか？ 動作します！

失敗する

実際の環境では、このような構成は機能しません。 手順3を繰り返し繰り返すと、管理者は苦い状態になり、「あなたのmicroticは機能しません！」

デブリーフィング

Netwatchユーティリティの動作を理解していないことがすべてです。 正確に再帰的なルーティングに関連して、ユーティリティは、 アクティブなルートを使用して、メインルーティングテーブルに従って、指定されたホストに単にpingを実行します。



実験してみましょう。 メインチャネルWAN1を無効にし、インターフェイス/ツールネットウォッチを確認します。 ホスト8.8.8.8がまだUP状態になっていることがわかります。



比較のために、check-gateway = pingオプションは、各ルートに対して個別に機能します。 再帰的に、ルート自体をアクティブまたは非アクティブにします。



Netwatchは現在アクティブなルートを使用します。 ISP1（WAN1）プロバイダーゲートウェイへのリンクで何かが発生すると、WAN1を介した8.8.8.8へのルートが非アクティブになり、netwatchはそれを無視して、新しいデフォルトルートにパケットを送信します。 フェールオーバーはトリックを使用しており、netwatchはすべてが正常であると考えています。



2番目のネットウォッチの動作はダブルトリガーです。 そのメカニズムは次のとおりです。netwatchからのpingがcheck-gateway timeoutに該当する場合、ホストは1つのチェックサイクルの間DOWNと認識されます。 チャネル切り替えスクリプトが機能します。 SIP接続は、新しいリンクに正しく切り替わります。 動作しますか？ そうでもない。



すぐにルーティングテーブルが再構築され、ホスト8.8.8.8がUPステータスを受け取り、SIP接続リセットスクリプトが再び機能します。 WAN2を介して2回目の接続が再インストールされます。



その結果、ISP1がサービスに戻り、仕事用トラフィックがWAN1に切り替わっても、SIP接続はISP2（WAN2）を介してハングします。 これは、予備チャネルに問題がある場合、システムはこれに気付かず、電話接続も行われないという事実に満ちています。

解決策

モニタリングに使用されるホスト8.8.8.8へのトラフィックがISP2にラップされないようにするには、8.8.8.8へのバックアップルートが必要です。 ISP1がクラッシュした場合、distance = 10およびtype = blackholeなど、大きな距離値を使用してバックアップルートを作成します。 WAN1ゲートウェイへのリンクがなくなると、アクティブになります。



/ ip route add distance = 10 dst-address = 8.8.8.8 type = blackhole



その結果、1行だけで構成が追加されます。





この状況は、ISP1ゲートウェイが使用できなくなったときに、最後のマイルが落ちるときの典型的な状況です。 または、チェーンの依存性により落下しやすいトンネルを使用する場合。



この記事がこのようなエラーの回避に役立つことを願っています。 新鮮なマニュアルを選択してください。 最新の状態に保つと、すべてがあなたから離陸します。