MikroTikパート2の企業ネットワークであるOSPFでWi-Fiプリンターをキャッチした方法

みなさんこんにちは！ 最後に、私は記事に約束された追加を行うことにしました。MikroTikの内部および外部通信チャネル、静的ルーティング、企業ネットワークの予約。

この記事では、プロジェクトの実装中に私の前に現れたいくつかの追加タスクのソリューションを共有したいと思います。 そのようなタスクには、店舗から店舗に移動する監査部門の従業員のデバイス用のオフィス内のサーバーへのアクセスの編成がありました（パート1）。 また、OSPF動的ルーティングプロトコルを使用してWi-Fiショッピングプリンターをキャッチした方法についても説明します（パート2）。

前と同じように、この解決策が誰かまたは新規参入者が同様の問題を解決するのに役立つことを願っています。 私は専門家からの批判に喜んでいるでしょう。



見出しに興味がある人-カットをお願いします！

パート0.提供されるもの

前の記事で行われたことを簡単に思い出させてください。 組織は私に頼りました-予約の可能性と限られた予算でセグメント化されたネットワークを組織することを要求する小売店のネットワーク。

私の仕事は、都市全体に地理的に分散したフラットネットワークを作成することです。階層化されたアドレッシングを備えたセグメント化されたネットワークであり、最も重要なのは冗長性の可能性です。
市内のすべての店舗間の接続は、ローカルISPによって組織化され、ネットワーク内に別個のVLANを会社に提供します。 したがって、すべての店舗とオフィスのネットワーク全体が1つの大きなLayer2 Broadcastドメインに属していました 。

このモデルにはいくつかの欠点があります。

1. ネットワーク上のすべてのデバイスは、レイヤー2でお互いを見ることができます。
2. トラフィックフィルタリングポリシーの欠如。
3. 単一のブロードキャストドメイン。その結果、400個のデバイスのそれぞれからのブロードキャストパケットは、都市のさまざまな部分にあるこれらの400個のデバイスすべてに必ず転送されます。

サーバーの簡潔で単純化されたレイアウトを、以下の図1に示します。



そして、私たちが持っているものの簡単な説明：

1. 会社には、さまざまな役割を実行するさまざまなサーバーがあります。
2. 特別なデータ収集端末（ TSD ）があり、図ではそれらをタブレットと呼んでいます。
   • 特定のストアに結び付けられ、制限を超えていない固定 TSDがあります。 それらは、ストア内のデバイスプールからのIPアドレスを持っています。
   • リビジョン TSDと、それらが対話する別のリビジョンサーバーがあります。 これらのTSDは、監査を実行するストアからストアに常に移行します。

パート1.「エラーが発生しましたが、ここで修正します」

ネットワークへのMikrotikルーターの導入後、最初の店舗では、同じ日にそこで監査が行われます。

監査部門の仕事の組織は非常に興味深く、独特です。 すべてのストアには、同じSSIDと暗号化キーを持つWi-Fiアクセスポイントがあります。 したがって、リビジョンTSDには独自のプール（192.168.3.0/24）からの静的IPアドレスがあります。

ネットワークは当初フラットだったため、いずれかのストアにアクセスするリビジョンTSDはすべて単一のフラットネットワークになり、問題なくどこにでもあるリビジョンサーバーに接続されました。

リビジョンサーバーは、特別なデータベースを備えたRDPサーバーでした。 これは、改訂前にメインデータベースサーバーと同期されていました。 リビジョンサーバーは、ストレージサーバーから作業に必要なファイルもロードしました。 主に監査サーバーとのみ対話するデータ収集端末（TSD-タブレット）。 ただし、極端な場合、リビジョンサーバーで何か問題が発生すると、オフィスにあるRDPサーバーと直接やり取りすることがありました。 他のすべてのTSD（ストアに常時配置され、それらに関連付けられている）は、メインRDPサーバーとのみ対話しました。

だから、それは明確でシンプルなようです。 定期的に店舗から店舗へと移動し、店舗の従業員にとって恐ろしいことを実行するデバイスのモバイルグループがあります-監査。
彼女は、ストア内のプールから動的にIPを取得し、オフィスにあるリビジョンサーバーに接続するか、極端な場合はメインRDPサーバーに接続するだけです。

しかし、地元のシステム管理者が私に言ったように、会社が長年にわたって存在してきたため、監査中にさまざまなケースがありました。 その1つは、店舗と本社の間の通信の意図的な違反であり 、監査は失敗しました。

そのため、 歴史的には、監査サーバーはショッピングオフィスからTSDとともに移動していました 。 これは通常、監査日の前日の夜に発生しました。 管理者はサーバーをストアに持ち込み、ストア内の任意のスイッチで使用可能なポートに接続します（ネットワークがフラットであり、すべてのポートが単一のL2ドメインによって接続されていることを思い出してください）。 彼はTSDを担当し、立ち去ります。

さらに、夜間、スケジュールに従って、監査サーバーは本社にある他のサーバーに接続し、さまざまな同期とデータ複製を実行します。 接続サーバーは常に改訂サーバーであることに注意することが重要です。

最初のストアでの分散セグメントネットワークの導入に戻ります。 そこにルーターが設置されます。これにより、L2セグメントが一般オフィスから分離され、プロバイダーの通信チャネルに冗長性が提供されます。
ストアで何が変更されたかを明確にするために、前の記事の画像をお見せしましょう。



図から、ストアにインストールされたルーターがデバイスのリビジョングループのモビリティを奪っていることが明らかです。
ルーターの導入後、店舗でのアドレス指定がどのようになるかを思い出させてください。

1. 192.168.1.0/24-セントラルオフィスネットワーク
2. 192.168.2.0/24-12店舗それぞれの192.168.13.0/24ローカルネットワーク
3. 10.10.10.0/24-メインイーサネットチャネルを介してメインオフィスに到着するネットワーク
4. 10.10.20.0/24-バックアップチャネル（PON）を介して本社に到着するネットワーク
5. 10.20.30.0/24-VPN内のネットワーク、外部ネットワークを介してISP-1からIPに固執する店舗用
6. 10.30.40.0/24-VPN内のネットワーク。外部ネットワークを介してISP-2からIPに固執する店舗用

これで、特定のストアに到着すると、以前のようにリビジョンサーバーがスイッチの空きポートに接続し、TSDはWi-Fiアクセスポイントに接続します。 その後、 TSDは地理的に地理的に同じストアにある監査サーバーと自由に通信 できますが、オフィスのメインRDPサーバーに接続することはできません。 また、監査サーバー自体は不在のため、データを同期できません。

なぜなら、それは最初の翻訳可能なストアであり、ネットワーク全体が新しい動作モードに完全に移行されたわけではないからです。 監査チームの作業スケジュールはすでにスケジュールされています。今日は彼らがここにいて、明日は別の店に、そして再びここに、など。

監査チーム（IPアドレスの範囲は静的：192.168.3.0/24）の接続を確保するための緊急のソリューションが必要です。

すでに上で述べたように、このスキームでは、同期イニシエーターはリビジョンサーバー自体です。他のサーバーに接続し、必要なタスクを実行します。 リビジョンTSDは、必要に応じて、オフィスのメインRDPサーバーとのRDPセッションのイニシエーターでもあります。

私の仕事は、オフィスを持つ店舗のいずれかにあるモバイルデバイスのIP接続を保証することです。 同時に、デバイスのアドレス指定は変更されません。 特定のストアでDHCPアドレスを取得するオプションはありません。

したがって、一時的なものとして（そしてそこに一定のままであるように）私の頭に浮かんだ最初の解決策は、 NATの実装です。

システム管理者に説明しましたが、監査部門の従業員によるTSD以外のデバイスが監査サーバーに接続する必要がないのは本当ですか？ 答えはノーでした。 確かに、 RDPを介してプログラマーにリモートで接続する必要がある場合があります 。 ただし、ストア内のPCからいずれか1つに接続することでこれを行うことができます。PCから既にサーバーに接続しています。 もちろん、ストア内のPCがサーバーを見ることができる場合を除きます。

それでは、タスクに取りかかりましょう。

まず、管理者にすべてのリビジョンTSDをインストールし、サーバーにメインゲートウェイのアドレス192.168.3.2をインストールするように依頼します。
ストアにあるルーターで、ストアに向かっているインターフェイスに次のIPアドレスを追加します。

[s@VERTOLET-GW] > ip address export # jun/03/2016 21:22:19 by RouterOS 6.32.3 # /ip address add address=192.168.3.2/24 interface=bridge-VERTOLET network=192.168.3.0 

したがって、この改訂ネットワーク（192.168.3.0/24）は絶対にすべての店舗に追加されます 。これにより、 店舗間を移動するときにデバイスのモバイルグループが設定を再構成せずに、店舗のルーターを参照して 、デバイスがオフィス内のどこにあるかを知ることができます。
しかし、同じアドレスを持つ12のストアがある場合、オフィスのサーバーはパケットの送信先をどのように知るのでしょうか？
ここで、 NATは私たちの助けになります。その目的は、モバイルグループが連絡するIPアドレスを変更することです。

これを行うには、どのサーバーがモバイルグループのデバイスにアクセスする必要があるかを見つけ、それらのデバイス用に個別のアドレスリストを作成します。

 [s@VERTOLET-GW] > ip firewall address-list export # jun/03/2016 21:32:00 by RouterOS 6.32.3 # /ip firewall address-list add address=192.168.1.2XX list=REVISION-Servers add address=192.168.1.2XX list=REVISION-Servers add address=192.168.1.2XX list=REVISION-Servers 

次に、 NAT変換のルールを作成して、モバイルグループの連絡先のアドレスを非表示にします。

 [s@VERTOLET-GW] > ip firewall nat export # jun/03/2016 21:42:00 by RouterOS 6.32.3 /ip firewall nat add action=masquerade chain=srcnat comment=FROM-REVISION dst-address-list=REVISION-Servers src-address=192.168.3.0/24 

このNATルールは、オフィス内の必要なサーバーにアクセスするときに、送信元アドレス（192.168.3.0）を中継ネットワークのルーターのアドレス（10.0.0.0/8）に変更します。
そのため、問題はすでに部分的に解決されています。 モバイルグループは任意の店舗に自由に来て、既製のゲートウェイが待機しているネットワークに接続し、中央オフィスへの接続を開始できます。

ソリューションを実装した最初の日に直面したこの問題を思い出させてください。 ネットワーク全体が変更の準備ができて いなかったため、 サーバーがストア間のアドレス指定について何も知らなかったという状況がありました。 また、Kerioサーバーは、翻訳されたストアのネットワークへのルートが、オフィス内の独立した控えめなMikrotikルーターに静的に登録された、それらのゲートウェイでした。
後にメインルーターになることでした。

これは、オフィスで（モバイルグループによってアクセスされる）サーバーから中継ネットワーク（10.0.0.0/8）を隠すために別のNAT変換を行う必要があることを意味します。
ストアと同じように、アドレスリストを追加します

 [s@MAIN-BORDER-ROUTER] > ip firewall address-list export # jun/03/2016 21:52:12 by RouterOS 6.32.2 # /ip firewall address-list add address=192.168.1.2XX list=REVISION add address=192.168.1.2XX list=REVISION add address=192.168.1.2XX list=REVISION 

また、翻訳ルール：

 [s@MAIN-BORDER-ROUTER] > ip firewall nat export # jun/03/2016 21:52:12 by RouterOS 6.32.2 # /ip firewall nat add action=masquerade chain=srcnat comment=NAT-KOSTUL-REVISION dst-address-list=REVISION src-address=10.0.0.0/8 

ご覧のとおり、このソリューションに名前を付ける考えがなかったため、このルール-松葉杖に正直に署名する必要がありました。
この段階で、モバイルデバイスグループと任意のストアからオフィス内のサーバーとの接続を確保するタスクが完了しました。
プログラマーの監査サーバーへのリモートアクセスは、必要に応じて、店舗のルーターを介してネットワーク192.168.3.0/24にアクセスする店舗内の任意のPCに接続し、このネットワークを直接接続されたネットワークとして認識して取得できます。

パート2. Wi-Fiプリンターが値札の印刷を拒否します！

最初のストアにネットワークが導入され、最後のストアがこのスキームに移行されてから約3週間が経過しました。 この時点で、軽微な欠点が表面化し、急いで修正されました。 一般に、計画通りにすべてがうまくいきました。 面白いのは、最初の店舗を新しい操作モードに切り替えた後、ISPが事故を起こしてこの店舗を通信できず、システムが完全に動作して予備に切り替えたことです。

最後の店舗での導入が行われたとき、システム管理者は、経営者が解決する必要があるタスクとして提示した別のニュアンスについて不確実性を持って私に言った。
モバイルグループには、別の店舗に行く範囲（192.168.3.0/24 ）のTSDを持つ別の従業員がいますが、彼のタスクは、有効期限が切れる商品を再評価することです。
TSDから、彼はオフィスにあるメインRDPサーバーに接続し、データベースを操作します。 製品をスキャンし、新しい値札を印刷します。

すべてが順調で、従業員は静かに1つまたは別の店に来て、以前のようにWi-Fiネットワークにしがみつき、問題なくオフィスのRDPサーバーに接続し、必要なことを行い、プリンターへの印刷を開始しますが、値札が印刷されているプリンターモバイル！ 以前は192.168.1.0/24の範囲のIPアドレスを持ち、単一のL2を持つフラットネットワークでは、どのストアからも利用できました。

また、オフィスから改訂サーバーに接続するとき、改訂が行われた店舗のコンピューターの1つが、改訂サーバーがNATの背後にあるという事実のためにプログラマーによって占有され、それにアクセスするには、店。

一般に、新しいタスクが設定されています。

1. オフィスからモバイルプリンターに印刷する機能を提供する
2. オフィスから直接RDP経由で監査サーバーに接続する機能を提供する

さて、今、私たちは、動的ルーティングプロトコルの導入から来ました。そこから、出てこないで、最初の部分に残すことにしました。

OSPFへようこそ！

ここで、最初の記事で書いたように、 OSPFパケットがISP-1ネットワークを通過しなかったため、真実は再び別の松葉杖を作らなければなりませんでした 。 CPE（HuaweiのxPON端末）が単にプロトコル89をドロップしたため、マルチキャストでもユニキャストでもありません。

そのため、主に冗長性を目的としたトンネルインターフェイスにOSPFを実装することにしました。
この状況でのOSPFは、次の2つのことに必要です。

1. 印刷用の小さなファイルを転送するために、オフィスのルーターにWi-Fiプリンターを探す場所を動的に指定します
2. リビジョンサーバーを探す場所をオフィスのルーターに動的に示し、そこにRDP制御コマンドを送信します（リビジョンサーバーからオフィスへのリターントラフィックは、最初の記事で意図したとおりになります）

OSPFを介してモバイルグループ（192.168.3.0/24）のネットワーク全体を送信する必要はありません。さらに、これを行うことはできません。 再評価担当者と監査チームは異なる場所にいることが多く、北とWi-Fiプリンターを同時に接続する必要があります。

したがって、この問題に対する最も最適な解決策は、 より具体的なアドレス/ 32をこれら2つのデバイス（プリンターとサーバー）に転送することであると判断しました。

これを行うには、リッチOSPF機能の次のツールが必要です。

1. ポイントツーポイントネットワークタイプ
2. 静的ルートの再配布
3. フィルタリング

最初に、店舗からオフィスにWi-Fiプリンターとサーバーに関する情報を転送する方法のアルゴリズムを決定します。
このため、OSPFは、これらのネットワークがこのルーターに接続されていること、およびこれらのルートが中央ルーターにアドバタイズされる必要があることを認識している必要があります。
OSPFは、2つの方法でネットワークをアナウンスします。

1. このインターフェイスがパッシブでない場合、OSPFが有効になっているインターフェイスに属するすべてのネットワークをアナウンスします。
2. 他の動的ルーティングプロトコル、直接接続されたルート、静的ルートの再配布によるネットワークアナウンス

だから、私は次のことをすることにしました：

1. すべてのストアと中央ルーターでOSPFプロセスを起動する
2. すべてのストアのサーバーおよびプリンター用に静的ルート/ 32を作成します
3. 再配布中およびOSPFでの不要な x静的ルート（および多数あり）のフィルタリング
4. NetWatchを 使用して、特定のストア内のデバイスの実際の可用性を追跡し、静的ルートを管理します。

すべてが明らかなようで、実装に進みます。
店舗およびオフィスのルーターでOSPFプロセスを起動します。
すべての店舗は1つのデフォルトエリア0にあります。
OSPFルーター間の近隣状態は、トンネルインターフェイスで発生します 。各店舗とオフィスの間には2つあります。
Mikrotikルーターでは、デフォルトでポイントツーポイントインターフェイスのコストは-10です。 各店舗とオフィスの間に2つのVPNチャネルがあるため、チャネル2のコストを20に設定します。

 [s@KREDO-MAIN-BORDER-ROUTER] > routing ospf export # jun/03/2016 22:42:36 by RouterOS 6.32.2 # /routing ospf instance set [ find default=yes ] router-id=255.255.255.255 /routing ospf interface add cost=20 interface=2.VERTOLET-VPN-RESERVE network-type=point-to-point /routing ospf network add area=backbone network=10.20.30.0/24 add area=backbone network=10.30.40.0/24 

店舗内のルーターで同様のアクションを実行し、さらに静的ルートを再配布する必要性を指摘し、それらをタイプ1としてアナウンスすることにしました。

 [s@KREDO-VERTOLET-GW] > routing ospf export # jun/03/2016 22:50:17 by RouterOS 6.32.3 # /routing ospf instance set [ find default=yes ] redistribute-static=as-type-1 router-id=192.168.15.2 in-filter=ospf-in out-filter=ospf-out /routing ospf interface add cost=20 interface=VPN-OFFICE-RESERVE network-type=point-to-point add interface=VPN-OFFICE network-type=point-to-point /routing ospf network add area=backbone network=10.20.30.0/24 add area=backbone network=10.30.40.0/24 

指定された構成には、 タイプ1などの静的ルートの再配布を担当するコマンドが含まれ、このタイプはタイプ2よりも優先度が高く、ルーター間でアドバタイズされるとメトリックが変化します 。 また、 OSPF設定で2つのフィルターを指定しました： ospf-inおよびospf-out 、 Mikrotikのこれらのフィルターは、 Ciscoルーターのルートマップに似た役割を果たします。

これらのフィルターを検討することを提案します。

 [s@VERTOLET-GW] routing filter export # jun/03/2016 23:01:57 by RouterOS 6.32.3 # /routing filter add action=discard chain=ospf-in ospf-type=external-type-1 add action=discard chain=ospf-in ospf-type=intra-area add action=accept chain=ospf-out prefix=192.168.3.3 protocol=static add action=accept chain=ospf-out prefix=192.168.3.252 protocol=static add action=discard chain=ospf-out protocol=static 

ospf-inフィルターは、 OSPFを経由してルーターに到達する可能性のあるルートをフィルタリングします。
ospf-outフィルターは、サーバーおよびWi-Fiプリンター用のより具体的な/ 32ルートを除き、再配布を通じてアドバタイズできるすべての可能なルートをフィルターで除外します。

現在、モバイルデバイス用に静的/ 32ルートを追加する必要がありますが、その場所に注意する必要があります。

 [s@VERTOLET-GW] > ip route export # jun/03/2016 23:08:46 by RouterOS 6.32.3 # /ip route add comment=MOBILE-WiFi-PRINTER disabled=yes distance=1 dst-address=192.168.3.3/32 gateway=bridge-VERTOLET add comment=Revision-SERVER disabled=yes distance=1 dst-address=192.168.3.252/32 gateway=bridge-VERTOLET 

disabled = yesパラメーターを使用してこれらの静的ルートを追加していることに注意してください。つまり、 これらのルートはオフになり、アクセスできなくなります。 つまり、 OSPF を通じてアナウンスされません 。

なんで？ なぜなら、すべてのストアにアクティブルートを一度に追加すると、メインルーター上でそれらがすべてのストアから見えるようになり、元のルートに戻るからです。 Wi-Fiプリンターをどこでキャッチするのか具体的にわからない場合は、 これらのルートはすべての店舗に存在します。
したがって、 静的ルートはデフォルトでオフになって おり、デバイスが特定のストアに実際に表示されるまで誰も静的ルートについて話しません。

pingを介したデバイスの可用性によってこれを理解できるため、単純なスクリプトを使用して2つのNetWatchルールを作成します。

 [s@KREDO-VERTOLET-GW] >tool netwatch expoart # jun/03/2016 23:15:59 by RouterOS 6.32.3 # /tool netwatch add down-script="/ip route set [find comment=\"MOBILE-WiFi-PRINTER\"] disable=yes" host=192.168.3.3 interval=10s timeout=2s up-script="/ip route set [find comment=\"MOBILE-WiFi-PRINTER\"] disable=no" add down-script="/ip route set [find comment=\"Revision-SERVER\"] disable=yes" host=192.168.3.252 interval=10s timeout=2s up-script="/ip route set [find comment=\"Revision-SERVER\"] disable=no" 

これらのルールは非常に単純な役割を果たします。これは、ちなみにシスコの世界のip sla + trackに似ています。

サーバーとWi-Fiプリンターに2秒のタイムアウトで10秒ごとにpingを実行します。 pingが成功した場合は 、 静的ルートを有効にします 。これにより、 再配布によりOSPFに即座に切り替わり、オフィスのメインルーターがデバイスの場所を見つけます。

したがって、 Wi-Fiプリンターは以前と同じように再び印刷されるようになり、プログラマーはリビジョンサーバーでRDPを直接操作できます。 フラットネットワークがあるかのように。

6か月後、プロジェクトが完全に開始された瞬間から記事を書きました。 過去6か月間、すべてが完璧に機能し、失敗することはありませんでした。 Wi-Fiプリンターは正常にキャッチされ、残念ながらISPのクラッシュが発生しますが、店舗はこれに気付きません。

この記事は再び大きな記事になりました。ご注意と忍耐に感謝します。 批判とコメントを歓迎します。 ご質問がある場合は、喜んでお答えください。