私の未完成のプロジェクト。 200 台の MikroTik ルーターのネットワーク

こんにちは、みんな。 この記事は、パーク内に多数の Mikrotik デバイスがあり、各デバイスに別々に接続しないように最大限の統合を行いたい人を対象としています。 この記事では、残念ながら人的要因により戦闘状態に至らなかったプロジェクトについて説明します。 つまり、200 台を超えるルーター、迅速なセットアップとスタッフのトレーニング、地域ごとの統合、ネットワークと特定のホストのフィルタリング、すべてのデバイスにルールを簡単に追加する機能、ロギングとアクセス制御です。

以下に説明する内容は、既製のケースを装うものではありませんが、ネットワークを計画し、エラーを最小限に抑える際に役立つことを願っています。 おそらく、いくつかの点や決定があなたにとって完全に正しくないと思われるかもしれません。その場合は、コメントに書き込んでください。 この場合の批判は、一般的な貯金箱での経験になります。 したがって、読者の皆さん、コメントを見てください。おそらく作者が重大な間違いを犯した可能性があります。コミュニティが助けてくれるでしょう。

ルーターの数は 200 ～ 300 で、インターネット接続の品質が異なるさまざまな都市に分散しています。 すべてを美しくし、すべてがどのように機能するかをアクセスしやすい方法でローカル管理者に説明する必要があります。

それでは、すべてのプロジェクトはどこから始まるのでしょうか? もちろん、 TK.

1. 顧客の要件に応じて、すべての支店のネットワーク プランを組織し、ネットワークをセグメント化します (デバイスの数に応じて、支店内の 3 ～ 20 のネットワーク)。
2. 各ブランチにデバイスをセットアップします。 さまざまな動作条件でプロバイダーの実際の帯域幅を確認します。
3. デバイス保護の組織化、ホワイトリスト制御、一定期間の自動ブラックリスト登録による攻撃の自動検出、制御アクセスやサービス妨害の傍受に使用されるさまざまな技術的手段の使用の最小限化。
4. 顧客の要件に応じたネットワーク フィルタリングを使用した安全な VPN 接続の構成。 各ブランチからセンターへの少なくとも 3 つの VPN 接続。
5. ポイント 1、2 に基づいて、フォールト トレラントな vpn を構築する最適な方法を選択します。 請負業者は、適切な理由を備えた動的ルーティング テクノロジーを選択できます。
6. 顧客が使用するプロトコル、ポート、ホスト、およびその他の特定のサービスによるトラフィックの優先順位付けの編成。 (VOIP、重要なサービスを提供するホスト)
7. テクニカル サポート スタッフの対応のためのルーター イベントの監視とログ記録の組織。

私たちが理解しているように、場合によっては、TOR は要件からコンパイルされます。 私は主な問題点を聞いた後、これらの要件を自分で策定しました。 同氏は、他の誰かがこれらの点の実装を引き受ける可能性があることを認めた。

これらの要件を満たすために使用されるツールは次のとおりです。

1. ELK スタック (しばらくして、logstash の代わりに fluentd が使用されることが理解されました)。
2. アンシブル。 管理とアクセスの共有を容易にするために、AWX を使用します。
3. ギットラボ。 ここで説明する必要はありません。 構成のバージョン管理がない場合。
4. パワーシェル。 構成の初期生成には簡単なスクリプトがあります。
5. Doku wiki、ドキュメントとマニュアルの作成用。 この場合、habr.com を使用します。
6. 監視はzabbixを通じて行われます。 全体を理解するための接続図も表示されます。

EFKセットアップのポイント

最初の点については、インデックスが構築される理念についてのみ説明します。 沢山あります
mikrotik を実行しているデバイスのセットアップとログの受信に関する優れた記事。

いくつかの点について説明します。

1. このスキームによれば、さまざまな場所およびさまざまなポートからログを受信することを検討する価値があります。 これを行うには、ログ アグリゲータを使用します。 また、アクセスを共有できる機能を備えたすべてのルーターにユニバーサル グラフィックスを作成したいと考えています。 次に、次のようにインデックスを構築します。

これはfluentdを使用した構成の一部です 弾性検索
logstash_format true
インデックス名 mikrotiklogs.north
logstash_prefix mikrotiklogs.north
フラッシュ間隔 10 秒
ホスト エラスティックサーチ：9200
ポート9200

したがって、計画に従ってルーターとセグメントを組み合わせることができます (mikrotiklogs.west、mikrotiklogs.south、mikrotiklogs.east)。 なぜそんなに難しくするのでしょうか？ デバイスは 200 台以上になると考えています。 すべてに従わないでください。 elasticsearch のバージョン 6.8 以降、セキュリティ設定が (ライセンスを購入せずに) 利用できるため、テクニカル サポートの従業員またはローカル システム管理者の間で表示権限を分散できます。
表、グラフ - ここで同意する必要があるのは、同じものを使用するか、自分にとって都合が良いので全員がそれを使用するかのどちらかです。

2. ログを記録することによって。 ファイアウォール ルールでログを有効にすると、名前にスペースが含まれなくなります。 fluentd の簡単な設定を使用して、データをフィルタリングし、便利なパネルを作成できることがわかります。 下の写真は我が家のルーターです。

3. 占有スペースとログに応じて。 平均すると、1000 時間あたり 2 メッセージの場合、ログは 3 日あたり 7.5 ～ XNUMX MB を消費しますが、これはそれほど多くありません。 elasticsearch バージョン XNUMX。

ANSIBLE.AWX

幸いなことに、私たちは Routero 用の既製のモジュールを持っています。
AWX について指摘しましたが、以下のコマンドは最も純粋な形式の ansible に関するものにすぎません。ansible を使用したことのある人にとっては、GUI を介して awx を使用することに問題はないと思います。

正直に言うと、その前に ssh を使用する他のガイドを見ましたが、応答時間やその他の多くの問題についてはそれぞれが異なる問題を抱えていました。 繰り返しますが、戦闘には至りませんでした 、この情報は、20 台のルーターのスタンドを超えない実験として受け取ってください。

証明書またはアカウントを使用する必要があります。 それはあなたが決めることですが、私は証明書を支持します。 権利に関する微妙な点。 私は書き込み権限を与えます - 少なくとも「設定のリセット」は機能しません。

証明書の生成、コピー、インポートには問題はないはずです。

コマンドの簡単なリストパソコン上で
ssh-keygen -t RSA、質問に答え、キーを保存します。
mikrotik にコピーします。
ユーザー ssh-keys import public-key-file=id_mtx.pub user=ansible
まず、アカウントを作成し、それに権限を割り当てる必要があります。
証明書との接続を確認する
ssh -p 49475 -i /keys/mtx [メール保護]

vi /etc/ansible/hosts に書き込みます
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible

プレイブックの例: 名前: add_work_sites
ホスト:testmt
シリアル: 1
接続:network_cli
リモートユーザー: mikrotik.west
事実の収集: はい
タスク：
名前: Work_sites を追加
ルートロス_コマンド:

- /ip ファイアウォール アドレス リストの追加 address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip ファイアウォール アドレス リストの追加 address=habr.com list=work_sites comment=for_habr

上記の構成からわかるように、独自の Playbook をコンパイルするのは簡単です。 cli mikrotikをマスターすれば十分です。 すべてのルーター上の特定のデータを含むアドレスリストを削除する必要がある状況を想像してください。

見つけて削除する/ip ファイアウォール アドレス リストの削除 [リスト = "gov.ru" を検索]

ここでは、ファイアウォールのリスト全体を意図的に含めませんでした。 それはプロジェクトごとに個別になります。 ただし、一つだけ確実に言えるのは、アドレスリストのみを使用するということです。

GITLAB によると、すべてが明らかです。 この瞬間にこだわるつもりはありません。 個々のタスク、テンプレート、ハンドラーに関しては、すべてが美しいです。

PowerShell

3つのファイルになります。 なぜパワーシェルなのか？ 構成を生成するためのツールは、慣れている人であれば誰でも選択できます。 この場合、誰もが自分の PC に Windows を持っているのに、PowerShell の方が便利であるのに、なぜ bash で実行するのでしょうか。 誰がより快適ですか。

スクリプト自体 (シンプルでわかりやすい):[cmdletBinding()] Param(
[パラメータ(必須=$true)] [文字列]$EXTERNALIPADDRESS,
[パラメータ(必須=$true)] [文字列]$EXTERNALIPROUTE,
[パラメータ(必須=$true)] [文字列]$BWorknets,
[パラメータ(必須=$true)] [文字列]$CWorknets,
[パラメータ(必須=$true)] [文字列]$BVoipNets,
[パラメータ(必須=$true)] [文字列]$CVoipNets,
[パラメータ(必須=$true)] [文字列]$CClientss,
[パラメータ(必須=$true)] [文字列]$BVPNWORKs,
[パラメータ(必須=$true)] [文字列]$CVPNWORKs,
[パラメータ(必須=$true)] [文字列]$BVPNCLIENTS,
[パラメータ(必須=$true)] [文字列]$cVPNCLIENTS,
[パラメータ(必須=$true)] [文字列]$NAMEROUTER,
[パラメータ(必須=$true)] [文字列]$ServerCertificates,
[パラメータ(必須=$true)] [文字列]$infile,
[パラメータ(必須=$true)] [文字列]$outfile
)

コンテンツの取得 $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Object {$_.Replace("CClients", $CClientss)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach-Object {$_.Replace("BVPNCLIENTS", $BVPNCLIENTS)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTS)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | セットコンテンツ $outfile

申し訳ありませんが、すべてのルールを説明することはできません。 それは美しくありません。 ベスト プラクティスに基づいて、自分でルールを作成できます。

たとえば、私が参考にしたリンクのリストは次のとおりです。wiki.mikrotik.com/wiki/マニュアル:あなたのルーターの保護
wiki.mikrotik.com/wiki/マニュアル:IP/ファイアウォール/フィルター
wiki.mikrotik.com/wiki/マニュアル:OSPF の例
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/マニュアル:ウィンボックス
wiki.mikrotik.com/wiki/マニュアル:RouterOS のアップグレード
wiki.mikrotik.com/wiki/マニュアル:IP/Fasttrack - ここでは、Fasttrack が有効になっている場合、トラフィックの優先順位付けとシェーピング ルールが機能しないことを知っておく必要があります。これは、弱いデバイスに役立ちます。

変数の規則:次のネットワークを例として取り上げます。
192.168.0.0/24 稼働ネットワーク
172.22.4.0/24 VOIP ネットワーク
LAN アクセスのないクライアント用の 10.0.0.0/24 ネットワーク
192.168.255.0/24 大規模支店向け VPN ネットワーク
172.19.255.0/24 小規模向け VPN ネットワーク

ネットワーク アドレスは、それぞれ ABCD の 4 つの 192.168.0.0 進数で構成されます。置換は同じ原則に従って行われます。起動時に B が要求された場合、ネットワーク 24/0 の場合は数値 0 を入力する必要があり、C = XNUMX の場合は数値 XNUMX を入力する必要があります。 。
$EXTERNALIPADDRESS - プロバイダーから割り当てられたアドレス。
$EXTERNALIPROUTE - ネットワーク 0.0.0.0/0 へのデフォルト ルート
$BWorknets - 動作中のネットワーク。この例では 168 になります。
$CWorknets - 職場ネットワーク。この例では 0 になります。
$BVoipNets - この例の VOIP ネットワーク 22
$CVoipNets - この例の VOIP ネットワーク 4
$CClientss - クライアント用のネットワーク - インターネットへのアクセスのみ、ここでは 0
$BVPNWORKs - 大規模な支店用の VPN ネットワーク、この例では 20
$CVPNWORKs - 大規模ブランチ用の VPN ネットワーク、この例では 255
$BVPNCLIENTS - 小規模支店向けの VPN ネットワーク、19 を意味します
$CVPNCLIENTS - 小規模ブランチ向けの VPN ネットワーク、255 を意味します
$NAMEROUTER - ルーター名
$ServerCertificate - 最初にインポートする証明書の名前
$infile - 構成を読み取るファイルへのパスを指定します。たとえば、D:config.txt (引用符やスペースを含まない英語のパスの方が適切です)
$outfile - 保存先のパスを指定します (例: D:MT-test.txt)

明らかな理由から、例内のアドレスを意図的に変更しました。

攻撃と異常な動作の検出に関する要点を見逃していました。これは別の記事にする価値があります。 ただし、このカテゴリでは、Zabbix からの監視データ値と elasticsearch から計算されたcurl データを使用できることを指摘する価値があります。

注目すべきポイント:

1. ネットワークプラン。 読みやすい形で書いた方が良いです。 エクセルで十分です。 残念ながら、ネットワークが「新しいブランチが登場しました、ここに /24 があります」という原則に従ってコンパイルされているのをよく見かけます。 特定の場所でどれだけのデバイスが予想されるか、さらに増加するかどうかは誰も知りません。 たとえば、小規模なストアがオープンしましたが、そこではデバイスが10以下であることが最初は明らかですが、なぜ/ 24を割り当てるのでしょうか？ 逆に、大規模なブランチの場合は、/ 24 が割り当てられ、デバイスが 500 台あります。ネットワークを追加するだけで済みますが、すぐにすべてを検討する必要があります。
2. フィルタリングルール。 プロジェクトがネットワークの分離と最大限のセグメンテーションを想定している場合。 ベスト プラクティスは時間の経過とともに変化します。 以前は、PC ネットワークとプリンター ネットワークを共有していましたが、現在ではこれらのネットワークを共有しないのがごく普通のことです。 常識的に考えて、必要のないサブネットを多数作成したり、すべてのデバイスを XNUMX つのネットワークに結合したりしないことが重要です。
3. すべてのルーターの「ゴールデン」設定。 それらの。 計画があるなら。 一度にすべてを予測し、すべての設定が同一であることを確認することは価値があります。アドレスリストと IP アドレスが異なるだけです。 問題が発生した場合、デバッグにかかる​​時間が短縮されます。
4. 組織的な側面は技術的な側面と同様に重要です。 多くの場合、怠け者の従業員は、既製の構成やスクリプトを使用せずに、これらの推奨事項に「手動で」従うため、最終的には問題がゼロから発生します。

動的ルーティングによる。 ゾーニングを備えた OSPF が使用されました。 しかし、これはテストベンチであり、戦闘状態では、そのようなものをセットアップする方が興味深いです。

私がルーターの設定を投稿しなかったことに腹を立てる人がいなかったことを願っています。 リンクだけで十分だと思いますが、それは要件次第です。 そしてもちろんテスト、さらに多くのテストが必要です。

新年に皆さんがそれぞれのプロジェクトを実現できることを願っています。 アクセス権があなたとともにありますように!!!

出所： habr.com