はじめに
ネットワーク機器では、脆弱性対応や不具合修正のためにファームウェア更新が必要になることがあります。対象機器が増えると、1台ずつログインしてファームウェアを転送し、更新コマンドを実行する作業にも時間がかかります。
UnimusのMass Config Pushでは、CLIで行う操作をあらかじめPush Presetとして登録し、指定した機器へ実行できます。
今回は実運用を想定し、更新ファイルを事前に配布して結果を確認したうえで、通信断を伴う再起動はメンテナンス時間帯に実施する流れを検証しました。
Unimusとは？
Unimusは、ルーターやスイッチなどのネットワーク機器のコンフィグを一元管理するためのツールです。登録した機器からコンフィグを自動で取得し、バックアップや変更履歴、差分をWeb画面から確認できます。
また、Mass Config Pushを利用すると、複数のネットワーク機器に対してCLIコマンドを実行できます。コンフィグのバックアップだけでなく、設定変更や今回のようなファームウェア更新作業など、日常的なネットワーク運用にも利用できます。
今回の検証内容
検証には、Hyper-V上で動作するMikroTik CHR（Cloud Hosted Router）を使用しました。
CHRはあらかじめUnimusに登録し、Discovery済みで、コンフィグバックアップを取得できる状態から検証を開始しています。
作業の流れは以下のとおりです。
- 更新前のコンフィグをバックアップ
- Mass Config Pushでファームウェアを事前配布
- 配布結果を確認
- メンテナンス時間帯に再起動
- 更新後のバージョンを確認
- 再度バックアップし、更新前後を比較
検証環境は以下のとおりです。
| 項目 | 内容 |
|---|---|
| Unimus Server | Windows PC |
| 検証機 | MikroTik CHR |
| CHR IPアドレス | 192.168.200.10 |
| 更新前 | RouterOS 7.23.3 |
| 更新後 | RouterOS 7.24.2 |
| ファームウェア配布 | TFTP |
| TFTPサーバー | Tftpd64 |
| TFTPサーバーIP | 192.168.200.1 |
構成と運用のイメージ
Unimusで管理しているMikroTik CHRに対し、ファームウェアを事前配布して更新する構成
今回の検証では、Unimus Serverを動かしているWindows PC上にTftpd64もインストールしました。Hyper-V上には検証対象のCHRを配置しています。
UnimusからCHRへはSSHで接続し、コンフィグバックアップやMass Config Pushを実行します。ファームウェアは、同じWindows PC上のTftpd64からTFTPで配布します。
本記事ではUnimusの操作を中心に紹介するため、Hyper-VやTftpd64の構築手順は割愛します。
以下で使用するコマンドはMikroTik CHR向けです。ファームウェアの転送方法や更新手順は、メーカーや機種によって異なります。
更新前にコンフィグをバックアップする
まず、ファームウェア更新前の状態を残すため、Unimusから最新のコンフィグバックアップを取得しました。
今回のCHRでは、更新前のRouterOSは7.23.3です。
更新前にバックアップを取得しておけば、作業前の設定状態をUnimus上に残せます。
今回は更新後にもバックアップを取得し、前後の状態を比較します。
Mass Config Pushでファームウェアを事前配布する
次に、RouterOS 7.24.2のパッケージをCHRへ配布します。
今回は、ファームウェアの配布と再起動を別々のPush Presetにしました。
先に更新ファイルだけを配置し、正常に取得できたことを確認してから再起動します。
ファームウェア配布用のPush Presetを作成する
Unimusの「Mass config push」からPush Presetを作成し、対象デバイスにCHRを指定します。
登録したコマンドは以下です。
/tool fetch address=192.168.200.1 src-path=routeros-7.24.2.npk mode=tftp dst-path=routeros-7.24.2.npk
/file print1行目で、Windows PC上のTFTPサーバーからrouteros-7.24.2.npkを取得します。
2行目の/file printでは、ファイルがCHR上に配置されたことを確認します。
配布結果を確認する
Push Presetを保存したら、「Execute」から実行します。
実行結果には以下のように表示されました。
status: finished
downloaded: 20344KiB
duration: 1s続けて実行した/file printでも、
routeros-7.24.2.npk package 19.9MiBと表示され、更新用パッケージがCHR上に配置されたことを確認できました。
ここではまだ再起動しません。
実運用では、更新ファイルをあらかじめ配布しておけば、メンテナンス時間帯に入る前にファイルの取得結果を確認できます。
複数台を対象にする場合も、各機器の配布結果を確認してから更新作業へ進めます。
メンテナンス時間帯に再起動する
ファームウェアの配置を確認したら、更新を実行します。
MikroTik CHRでは、更新用パッケージを配置した状態で再起動すると、新しいRouterOSが適用されます。
再起動用のPush Presetには、以下を登録しました。
/system reboot
y
今回は通信断が許容されるメンテナンス時間帯で、担当者が「Execute」から手動で再起動コマンドを実行する運用を想定しました。
ファームウェア配布と再起動を分けることで、更新ファイルの準備は事前に済ませ、サービス影響を伴う処理だけを決められた時間帯に実施できます。
なお、再起動するとSSH接続はいったん切断されます。起動後に再接続し、更新結果を確認します。
更新後の状態を確認する
再起動後にRouterOSのバージョンを確認したところ、
RouterOS 7.23.3
↓
RouterOS 7.24.2へ正常に更新されていました。
その後、Unimusからもう一度バックアップを取得しました。
更新前後のバックアップをDiff機能で比較すると、RouterOSのバージョン表示が、
RouterOS 7.23.3から
RouterOS 7.24.2へ変わっていることを確認できました。
更新後もUnimusからバックアップを取得できており、そのまま対象機器を管理できることも確認できました。
実運用での確認ポイント
ファームウェア更新にMass Config Pushを利用する場合は、事前にメーカーが案内する更新手順や、対象機種に対応するファームウェア、アップグレード経路を確認しておく必要があります。
複数台を対象にする場合も、最初から全台へ実行するのではなく、検証機や少数台で動作を確認してから対象を広げる方が安全です。
また、冗長構成では通信への影響を考慮し、更新する機器の順序も事前に決めておきます。
今回はTFTPを使用しましたが、実環境では機器の対応状況や社内のセキュリティポリシーに合わせて、SCP、SFTP、HTTPSなども含めて転送方法を検討します。
まとめ
今回は、UnimusのMass Config Pushを使って、MikroTik CHRのファームウェア更新を検証しました。
更新ファイルを事前に配布して結果を確認し、再起動はメンテナンス時間帯に実行するという、一連の更新手順を確認できました。
また、更新前後のバックアップを比較し、RouterOS 7.23.3から7.24.2への更新もUnimusのDiff画面で確認できました。
今回の検証ではCHR 1台を対象にしましたが、Mass Config Pushでは複数の機器へ同じコマンドを実行できます。同一機種を複数台管理している環境では、確認済みのPush Presetを使って同じ手順を展開できます。
Unimusのインストールから初期設定、デバイス登録、バックアップ取得までの詳しい操作手順を確認したい場合は、Unimus評価ガイドもあわせてご活用ください。
Unimusの詳細や評価版については、弊社Webサイトもご確認ください。
