ラベル ネットワーク の投稿を表示しています。 すべての投稿を表示
ラベル ネットワーク の投稿を表示しています。 すべての投稿を表示
2023年8月5日土曜日

EdgeRouter X (ER-X)のファームウェアバージョンアップ手順

先日購入したEdgeRouter X (ER-X)だが、新しいファームウェアがリリースされていたので、ファームウェアバージョンアップを実施してみた。



ファームウェアダウンロードURL

ファームウェアは以下URLからダウンロードできる。2020年1月時点では、数か月に1回は新しいバージョンがリリースされているようだ。
今回は「EdgeRouter ER-X/ER-X-SFP/EP-R6/ER-10X: Firmware v2.0.8」にバージョンアップすることにする。


バージョンアップ用のファイルは「ER-e50.v2.0.8.5247496.tar」といったtar形式のファイルでダウンロードでき、このバージョンの場合は80MB程度の容量となる。tarのまま利用するため、特に解凍する必要はない。

バージョンアップ手順

バージョンアップは管理GUIから行うが、一部CLIからの作業も必要になる。
  1. GUIにログインし、画面下部の「System」タブをクリックする。

  2. 「Upgrade System Image」にある「Upload a file」ボタンをクリックする。


  3. ダウンロードしたtarファイルを選択する。


  4. しばらくすると以下のダイアログボックスにエラーメッセージが表示される。
[System Upgrade Failed]
There wes an error upgrading the system.


このメッセージが表示されたとしても、アップグレードは成功しているパターンがあるので、以降はCLIで確認する。
  1. 現在のバージョンを確認すると、v2.0.4となっている。
$ show version
Version:      v2.0.4
Build ID:     5199165
Build on:     06/05/19 15:49
Copyright:    2012-2018 Ubiquiti Networks, Inc.
HW model:     EdgeRouter X 5-Port
HW S/N:       18E8292F820C
Uptime:       22:38:16 up 3 days, 38 min,  1 user,  load average: 1.21, 1.11, 1.03
ストレージ容量を確認してみると、「/」の空き容量が56.4MBとなっている。空き容量がバージョンアップ用ファイルの80MBより少ないことが、失敗メッセージの原因なのかもしれない。
$ show system storage
Filesystem                Size      Used Available Use% Mounted on
ubi0_0                  214.9M    153.8M     56.4M  73% /root.dev
overlay                 214.9M    153.8M     56.4M  73% /
devtmpfs                123.0M         0    123.0M   0% /dev
tmpfs                   123.7M         0    123.7M   0% /dev/shm
tmpfs                   123.7M      1.8M    121.9M   1% /run
tmpfs                     5.0M         0      5.0M   0% /run/lock
tmpfs                   123.7M         0    123.7M   0% /sys/fs/cgroup
tmpfs                   123.7M      4.0K    123.7M   0% /tmp
tmpfs                   123.7M     68.0K    123.6M   0% /var/log
tmpfs                   123.7M         0    123.7M   0% /run/shm
tmpfs                   123.7M         0    123.7M   0% /lib/init/rw
none                    123.7M    104.0K    123.6M   0% /opt/vyatta/config
overlay                 123.7M      4.0K    123.7M   0% /opt/vyatta/config/tmp/new_config_94812a33023843b680924b175f4b863d
tmpfs                    24.7M         0     24.7M   0% /run/user/1000
バージョンアップ用のファイルのアップロード状況は以下で確認できる。どうやら今回対象となるv2.0.8のファイルはアップロードできているようだ。
$ show system image storage
Image name                        Read-Only   Read-Write        Total
------------------------------ ------------ ------------ ------------
v2.0.8.5247496.191120.1124            80512           48        80560
v2.0.4.5199165.190605.1549            79756          168        79924
  1. 不要なバージョンアップ用のファイルを削除を試みると、「System has already been upgraded and needs a reboot before upgrade」と、すでにアップグレードされているので再起動せよとのメッセージが表示される。
$ delete system image
System has already been upgraded and needs a reboot before upgrade
  1. ER-Xを再起動する。
$ reboot
  1. 再起動後、再度バージョンを確認するとv2.0.8に上がっていることが確認できる。
$ show version
Version:      v2.0.8
Build ID:     5247496
Build on:     11/20/19 11:24
Copyright:    2012-2019 Ubiquiti Networks, Inc.
HW model:     EdgeRouter X 5-Port
HW S/N:       18E8292F820C
Uptime:       19:15:15 up 1 min,  1 user,  load average: 1.49, 0.52, 0.19
  1. 先ほど削除できなかった不要なバージョンアップ用ファイルも削除することができる。今回は前回バージョンとなるv2.0.4を削除した。
$ delete system image
The system currently has the following image(s) installed:

v2.0.8.5247496.191120.1124     (running image) (default boot)
v2.0.4.5199165.190605.1549

You are about to delete image [v2.0.4.5199165.190605.1549]
Are you sure you want to delete ? (Yes/No) [Yes]: yes
Removing old image... Done
削除すると、「/」の空き容量が133.3MBとなり、バージョンアップ用ファイルが再度アップロード可能となる。
$ show system image storage
Image name                        Read-Only   Read-Write        Total
------------------------------ ------------ ------------ ------------
v2.0.8.5247496.191120.1124            80512          160        80672

$ show system storage
Filesystem                Size      Used Available Use% Mounted on
ubi0_0                  214.9M     76.9M    133.3M  37% /root.dev
overlay                 214.9M     76.9M    133.3M  37% /
devtmpfs                123.0M         0    123.0M   0% /dev
tmpfs                   123.6M         0    123.6M   0% /dev/shm
tmpfs                   123.6M      1.3M    122.4M   1% /run
tmpfs                     5.0M         0      5.0M   0% /run/lock
tmpfs                   123.6M         0    123.6M   0% /sys/fs/cgroup
tmpfs                   123.6M      4.0K    123.6M   0% /tmp
tmpfs                   123.6M     56.0K    123.6M   0% /var/log
tmpfs                   123.6M         0    123.6M   0% /lib/init/rw
tmpfs                   123.6M         0    123.6M   0% /run/shm
none                    123.6M    104.0K    123.5M   0% /opt/vyatta/config
tmpfs                    24.7M         0     24.7M   0% /run/user/1000

以上でバージョンアップ作業は完了となる。

更新履歴

  • 2020/1/15 新規作成
  • 2023/8/5 ファームウェアダウンロードURL変更に伴い更新

2022年6月25日土曜日

同一セグメントにおいてルーティングが必要な場合の対処方法 (ロンゲストマッチはAD値よりも優先される話)

ネットワーク機器やサーバなどにおいては、直接属しているネットワークを「Connected」という状態で認識する。Connectedのネットワークは同一セグメントとなることから、ルーティングはされることなく直接通信することが可能となる。

ただし、同一セグメントにおいても、ネクストホップを指定してルーティングを実施したい場合がある。

本記事では、同一セグメントにおいてもルーティングが必要なケースを例として挙げ、それを解決するための方法について記載する。

Connectedネットワークにおいてもルーティングが必要なケース

例として、負荷分散装置が存在するような以下ネットワーク構成で考えてみよう。負荷分散装置の仮想IP間で通信するサーバが2セット(サーバA-1・A-2とB-1・B-2)ある場合を想定する。すべてのサーバは同一セグメントではあるが、負荷分散装置を経由して通信させたい場合を考える。

この場合、各サーバはConnectedとなっているネットワークとなることから、負荷分散装置経由で通信を受け取っても、戻りの通信を負荷分散装置ではなくサーバに直接返そうとする。これにより、行きと戻りで非対称のルーティングとなるため通信に失敗する。

解消方法①:負荷分散装置でSource NATする

本方法はルーティングによる解決ではないく、負荷分散装置でSource NAT (送信元NAT) をすることで、同一セグメント間の通信として戻り通信を負荷分散装置に戻す方法となる。

Source NATすることで通信は必ず負荷分散装置に戻るため、非対称ルーティングとならない。ただし、通信元のIPアドレスがすべて負荷分散装置のIPアドレスとなってしまうため、通信元のIPアドレスを特定するためには、アプリケーション側で何らかの考慮をする必要がある。

解消方法②:Connectedのネットワークよりもプレフィックス長が長いスタティックルートを設定する

通信元のIPアドレスを必ず実IPで受け取りたい場合など、Source NAT使えない場合がある。そのような場合、あるルールを満たせばスタティックルートをConnectedより優先させることができる。

通常ルーティングには、優先順位として「AD値 (Administrative Distance)」が設定されている。AD値は低いほど優先順位が高く、Cisco機器を例として記載すると、Connectedのネットワークは0、スタティックルートは1、それ以外のダイナミックルーティングは1より大きい数で設定されている。

したがって、一見するとConnectedのネットワークは最優先で処理されてしまい、スタティックルートで制御することは困難であると考えてしまう。しかし、もう一つルーティングの優先順位を決めるルールとして、「ロンゲストマッチ (Longest match)」がある。

ロンゲストマッチとは、同じIPアドレス宛てのルーティングルールが複数ある場合、もっともサブネットのプレフィックス長が長いものを優先するというルールである。例えば、以下のような2つのスタティックルートがある場合は、よりプレフィックス長が長い/28のルートが採用される。

種類 ネットワーク ネクストホップ
Static route 192.168.10.0/24 192.168.20.254
Static route 192.168.10.0/28 192.168.20.201

重要な点は、ロンゲストマッチはAD値よりも優先されて処理されることである。そのため、Connectedのネットワークよりもプレフィックス長が長いスタティックルートを作れば、スタティックルートを優先させることができる

今回の例では、以下の通りサーバB-1およびサーバB-2に/32のスタティックルートを設定すればよい。これによって、サーバA-1およびサーバB-2あての通信は、必ず負荷分散装置のIPアドレスを経由させることができる。

種類 ネットワーク ネクストホップ
Connected 192.168.10.0/24 -
Static route [サーバA-1のIP]/32 [負荷分散装置のIP]
Static route [サーバA-2のIP]/32 [負荷分散装置のIP]

ただし、もしサーバA-1とサーバB-1間で負荷分散装置を経由せず、直接通信させる要件などもある場合はこの方法では対処できない。そのような場合は、解消方法①のSource NATによる対応を検討しよう。

以上。

2022年4月16日土曜日

Cisco Business 250 (CBS250-8T-E-2G) のファームウェアバージョンアップ手順

先日、Cisco Business 250の10ポートモデルである「CBS250-8T-E-2G」を購入した。購入した経緯としては、CLIを使ってCiscoライクなコマンドで設定できて、SNMPを使って監視できる機器が欲しかったことが理由となる。

Cisco Business 250はAmazonで売ってはいる。以下にAmazonの購入リンクを記載しておくが、Yahoo! ショッピングで探した方がより安価で購入することができるのでお勧めとなる。

届いたスイッチのファームウェアを確認すると最新のファームウェアではなかったことから、まずはファームウェア更新を行うことにした。

本記事では、Cisco Business 250のファームウェアバージョンアップ手順を記載する。

環境

Cisco Business 250の機器型番と新旧のファームウェアバージョンを以下に記載する。

  • 機器型番 : CBS250-8T-E-2G
  • 旧ファームウェアバージョン : 3.0.0.69
  • 新ファームウェアバージョン : 3.1.1.7

Cisco Business 250ファームウェアバージョンアップ手順

1. ファームウェア及び言語ファイルをダウンロード

ファームウェアは以下からダウンロードできる。

機器型番は「Business 250-8T-E-2G Smart Switch」を選択し、最新のファームウェアの「ダウンロード オプション」リンクを選択する。

次の画面では、ファームウェア本体と言語ファイルの2つのファイルをダウンロードする。なお、ファームウェアは40MB程度と軽量である。

  • Firmware image for CBS250 release 3.1.1.7
  • JapaneseLanguage file for Cisco Business 250 series switches release 3.1.1.7

2. GUIよりファームウェアを更新

ファームウェア更新はGUIより実施できる。Cisco Business 250のGUIにログインし、左メニューの「管理者」→「ファイル管理」→「ファームウェア操作」を選択する。

ファームウェア操作では以下を設定し、右上の「適用」ボタンを押すことでファームウェアの更新が開始される。

設定項目 設定値
操作タイプ ファームウェアの更新
コピー方式 HTTP/HTTPS
ファイル名 先ほどダウンロードしたファームウェアファイル (拡張子.bin)

1~2分ほど待機し、画面上部に「成功」と表示されれば成功となる。ただし、この段階では「アクティブなファームウェアバージョン」は旧ファームウェアバージョンのままとなる。

3. スイッチを再起動

新ファームウェアで起動させるため、スイッチの再起動を行う。左メニューの「管理者」→「リブート」を選択し、「即時」が選択された状態で右上の「リブート」を選択する。

4, ファームウェアの更新を確認

5分ほど待機しGUIにログインしなおして、再度、左メニューの「管理者」→「ファイル管理」→「ファームウェア操作」を選択する。「アクティブなファームウェアバージョン」が新ファームウェアバージョンとなっていれば問題ない。

5. 言語ファイルをアップロード

左メニューの「管理者」→「ファイル管理」→「ファイル操作」を選択する。ファイル操作では以下を設定し、右上の「適用」ボタンを押すことで言語ファイルがアップロードされる。

設定項目 設定値
操作タイプ ファイルの更新
宛先ファイルタイプ 言語ファイル
コピー方式 HTTP/HTTPS
ファイル名 先ほどダウンロードしたフ言語ファイル (拡張子.lang)

なお、言語ファイルがアップロードに成功すると、一時的に言語設定が英語に変更される。

この場合は一度GUIからログオフし、ログイン画面で言語設定を日本語に変更することで、日本語に戻すことが可能となる。

6. 言語ファイルの更新を確認

言語ファイルが更新されていることの確認は、左メニューの「ステータスと統計画面」→「システムサマリー」にて確認することができる。なお、ダウンロードした言語ファイルのバージョンは「3.1.1.7」と表記されているが、実際のバージョンは「3.1.0.59」である点に注意しよう。

以上で、Cisco Business 250のファームウェアバージョンアップは完了となる。

2021年7月6日火曜日

OSSのロードバランサ「ZEVENET Community Edition」にてTCP half-openのカスタムモニターを実装する

OSSのロードバランサである「ZEVENET」では、カスタムモニター (Farmguardian) を作成することができる。この作成方法は以下記事にした通りで、Linuxのncコマンドやnmapコマンドなどを利用したスクリプトを作成することで実装できる。

今回は、ZEVENETにてTCP half-openチェックと呼ばれる方法で負荷分散対象のサーバを監視するカスタムモニターを作成したので、実装方法を記載する。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

TCP half-openチェックとは

そもそも、TCP half-openチェックどのような監視手法かについて説明しよう。

ロードバランサで頻繁に使用されるモニターとして「TCP チェック」がある。TCPチェックでは、以下のTCPの3ウェイ・ハンドシェイクのステップを負荷分散対象のサーバに対して行い、問題なくコネクションの確立ができたのちに、FINパケットを送信してコネクションを切断する。

  1. 送信元→送信先へSYNパケット送信
  2. 送信先→送信元へSYN+ACKパケットを送信
  3. 送信元→送信先へACKパケット送信

しかし、TCPチェックには問題があり、TCPのコネクションを確立した後に切断処理をすることから、サーバ側のログにアクセス記録やエラーログが残ってしまう場合がある。

例えば、以下はPostfixにて構築したメールサーバに対するTCPチェックのログの例となる。ロードバランサ (IPアドレス : 192.168.33.25) からのconnectされたメッセージとdisconnectされたメッセージが確認できる。

Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: connect from unknown[192.168.33.25]
Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 18 06:34:50 64362e23f9d3 postfix/smtpd[158]: disconnect from unknown[192.168.33.25] commands=0/0
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: connect from unknown[192.168.33.25]
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 18 06:35:05 64362e23f9d3 postfix/smtpd[158]: disconnect from unknown[192.168.33.25] commands=0/0

上記ログは、無視すれば問題ないものであるが、不要なログが出力されることにより、ログの可読性の低下や、容量増加といった問題が発生する。

そこで、サーバ側にログを残さずTCPチェックを実現する方法として、「TCP half-openチェック」のカスタムモニターを実装することにした。TCP half-openチェックの動作について、再度3ウェイ・ハンドシェイクのステップを見ながら説明する。

  1. 送信元→送信先へSYNパケット送信
  2. 送信先→送信元へSYN+ACKパケットを送信
  3. 送信元→送信先へACKパケット送信

TCP half-openチェックでは、上記の2番目ステップのSYN+ACKパケットを受け取った時点でサーバのポートに問題がないものと判断する。3番目のステップでは、ACKパケットを送信するのではなくRSTパケットを送信することで、3ウェイ・ハンドシェイクを中断させ、コネクション確立前に通信を終了させる。

上記のように、送信元からSYN+ACKを受け取った状態 (half-open) で通信を終了させることで、サーバ側に不要なログが残ることを抑止できる。

ZENEVETでTCP half-openのカスタムモニターを作成する

1. カスタムモニター用のスクリプトを作成

TCP half-openチェックはnmap -sSを使うことで簡単に実行できる。以下はRHEL 7でnmapを実行した例となる。正常に接続できればSTATEopenで表示される。

▼接続成功例
# nmap -sS -p 25 192.168.33.23

Starting Nmap 6.40 ( http://nmap.org ) at 2021-02-20 10:28 JST
Nmap scan report for t3023cent.intrat.local (192.168.33.23)
Host is up (0.00036s latency).
PORT   STATE SERVICE
25/tcp open  smtp

接続に失敗する場合は、STATEclosedであったりfilteredになる。

▼接続失敗例
# nmap -sS -p 123 192.168.33.23

Starting Nmap 6.40 ( http://nmap.org ) at 2021-02-20 10:29 JST
Nmap scan report for t3023cent.intrat.local (192.168.33.23)
Host is up (0.00035s latency).
PORT    STATE  SERVICE
123/tcp closed ntp

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

ZEVENETにおいてもnmapコマンドは使用できるのだが、単独ポートでスキャンを実行するとfilteredになるという不具合が存在する。

# nmap -sS -p 25 192.168.33.23
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-20 10:34 JST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.33.23
Host is up (-0.20s latency).

PORT   STATE    SERVICE
25/tcp filtered smtp
MAC Address: 00:0C:29:1F:E0:DE (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

スキャン対象のポートを単独ではなく、範囲指定を行うとなぜか成功し、openステータスとなる。

# nmap -sS -p 25-26 192.168.33.23
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-20 10:34 JST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.33.23
Host is up (-0.15s latency).

PORT   STATE  SERVICE
25/tcp open   smtp
26/tcp closed rsftp
MAC Address: 00:0C:29:1F:E0:DE (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

上記をふまえ、あまり綺麗な回避策とはいえないが、nmapを監視対象と監視対象ポート+1のポート範囲を指定して実行するようカスタムモニタースクリプトを作成することにする。

結果、カスタムモニタースクリプトcheck_tcp_half_openは以下内容となった。本スクリプトは/usr/lib/nagios/pluginsのディレクトリに配置しておく。

# cat /usr/lib/nagios/plugins/check_tcp_half_open
------------------------------
#!/bin/bash

HOST=$1
PORT=$2
NextPORT=$((${PORT}+1))

nmap -n -sS -p ${PORT}-${NextPORT} ${HOST} | grep open | grep ${PORT}
------------------------------

最後にスクリプトに実行権限を付けておく。

# chmod +x /usr/lib/nagios/plugins/check_tcp_half_open

2. モニター (Farmguardians) を作成

管理GUIにログインし、「Monitoring」→「Farmguardians」にて「CREATE FARMGUARDIAN」を選択する。

Farmguardianの設定は以下の通りとする。Commandの「HOST」はチェック対象のホストのIPアドレス (またはホスト名)、「PORT」はチェック対象のポート番号を示す変数となる。Intervalは負荷分散対象にチェックを行う間隔となるので、要件に応じて設定すればよい。

設定項目 設定値 (TCP half-openチェック)
Name check_tcp_half_open
Command check_tcp_half_open HOST PORT
Interval 15 seconds

3. Farmの設定を修正

「LSLB」→「Farms」で修正対象のFarmの「Edit」ボタンを選択する。

「Health Checks for backend」を先ほど作成したモニターに設定変更する。なお、ZEVENETではなぜか本設定を変更すると「Submit」ボタンを押すことなく即座に設定反映されてしまうので、設定時は注意が必要となる (反映された旨が、自動的に右下にメッセージとして表示される)。

4. 動作確認

設定変更後、「Monitoring」→「Farm Stats」を確認し、負荷分散対象がUpステータスになっていることを確認する。

また、負荷分散対象のサーバのログを確認し、負荷分散装置からのモニターによるアクセスログが出力されていないことを確認する。

▼Postfixのログの例

15秒間隔で出力された接続・切断のログが表示されなくなった。

Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: connect from unknown[192.168.33.25]
Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 21 06:44:05 64362e23f9d3 postfix/smtpd[203]: disconnect from unknown[192.168.33.25] commands=0/0
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: connect from unknown[192.168.33.25]
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: lost connection after CONNECT from unknown[192.168.33.25]
Feb 21 06:44:20 64362e23f9d3 postfix/smtpd[203]: disconnect from unknown[192.168.33.25] commands=0/0

▼Squidのログの例

15秒間隔で出力されたerror:transaction-end-before-headersのログが表示されなくなった。

1613857802.748      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1613857817.752      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
1613857832.756      0 192.168.33.25 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -

参考

2021年6月29日火曜日

OSSのファイアウォール「pfSense」の初期インストール&冗長構成手順

OSSのファイアウォールの「pfSense」は、ファイアウォール機能をメインとしつつ、DHCPサーバ、DNSフォワーダ、VPN (IPsec、L2TP、OpenVPN)、さらにはロードバランサの機能までも有しており、多機能なネットワーク仮想アプライアンスとして利用することができる。
※パッケージを追加することでWebプロキシサーバなどの機能追加もできる。

pfSenseは物理ハードウェアだけではなく、ESXi上の仮想マシンとしてもインストールすることができる。今回は、pfSenseをESXiに初期インストールしたうえで、2台のpfSenseを使って冗長構成にする手順を記載する。

環境

使用するESXi及びpfSenseのバージョンを以下に記載する。pfSense 2.4.xはFreeBSD 11ベースのアプライアンスとなる。

  • ESXi : 6.7.0 Update 3
  • pfSense : 2.4.5-RELEASE-p1

pfSenseを冗長構成とする場合は、ハートビート用のNICが個別に必要となるため、WAN、LAN、OPT1の3つのNICを仮想マシンに付与する。以下に簡単なネットワーク構成図を記載する。

初期インストール

1. ESXi上で仮想マシンを作成

pfSenseをインストールするたの仮想マシンを新規作成する。以下の内容で仮想マシンを構成する。今回導入するpfSense 2.4.5-RELEASE-p1はFreeBSD 11ベースとなるため、仮想マシンのタイプもFreeBSD 11を選択する。

設定項目 設定値
ゲストOSファミリ その他
ゲストOSのバージョン FreeBSD 11 (64ビット)
CPU 1コア
メモリ 1024MB
ディスク 8GB
ネットワークアダプタ1 WAN用のポートグループを指定
ネットワークアダプタ2 LAN用のポートグループを指定
ネットワークアダプタ3 ハートビート用のポートグループを指定

なお、各pfSenseのバージョンとベースとなるFreeBSDのバージョンは以下サイトにて確認することができる。

2. インストールウィザードに従ってインストール

pfSenseのインストールイメージから起動すると、インストールウィザードが起動する。ウィザードでは以下選択を行う。

設定項目 設定値
Welcome [Install]を選択
Keymap Selection [Japanese 106]を選択したのち、[Continue with jp.kbd keymap]を選択
Partitioning [Auto (UFS)]を選択
Manual Configuration [No]を選択
Complete [Reboot]を選択

3. 初回起動時にてインタフェースを設定

インストールウィザード完了後に再起動されると、CLIによるインタフェースの初期設定が開始される。

設定項目 設定値
Should VLANs be set up now [y|n]? n
Enter the WAN interface name or ‘a’ for auto-detection vmx0
Enter the LAN interface name or ‘a’ for auto-detection vmx1
Enter the Optional 1 interface name or ‘a’ for auto-detection vmx2
Do you want to proceed [y|n]? y

以上を設定すると、「Bootup complete」と表示され、CLIで各種セットアップのメニューが表示される。

4. LAN側インタフェースにIPアドレスを設定

WAN側インタフェースはデフォルトでDHCPでIPアドレスを取得するが、LAN側インタフェースはIPアドレスがデフォルトで192.168.1.1/24に固定設定されている。このIPアドレスを適切なIPに変更しWeb管理画面にログインできるようにする。

CLIで「2) Set interface(s) IP address」を選択したのち、以下の設定を行う。

設定項目 設定値
Enter the number of the interface you wish to configure 2 (LAN)
Enter the new LAN IPv4 address 任意のIPアドレス (例:192.168.11.45)
Enter the new LAN IPv4 subnet bit count 任意のサブネットマスク (例:24)
For a WAN, enter the new LAN IPv4 upstream gateway address. For a LAN, press <ENTER> for none そのままエンター
Enter the new LAN IPv6 address そのままエンター
Do you want to enable the DHCP server on LAN? (y/n) n
Do you want to revert to HTTP as the webConfigurator protocol? (y/n) y
Press <ENTER> to continue そのままエンター


5. Web管理画面にログイン

http://[設定したLANインタフェースのIPアドレス]にアクセスすると、Web管理画面にアクセスすることができるので、以下デフォルトのユーザ、パスワードを入力してログインする。

  • ユーザ名 : admin
  • パスワード : pfsense

6. 初回ログイン時のセットアップウィザードに従って初期設定を実施

初回ログイン時はセットアップウィザードが表示されるので、以下のように初期設定を行う。

設定項目 設定値
pfSense Setup そのまま[Next]
Netgate Global Support is available 24/7 そのまま[Next]
General Information [Hostname]、[Domain]、[Primary DNS Server]を環境に合わせて設定
Time Server Information [Time server hostname]にNTPサーバのIPアドレスを指定、[Timezone]にAsis/Tokyoを指定
Configure WAN Interface 環境に合わせてDHCPまたはStatic (固定IP) を指定
Configure LAN Interface そのまま[Next]
Set Admin WebGUI Password 任意のパスワードを設定
Reload configuration そのまま[Reload]
Wizard completed. そのまま[Finish]

7. open-vm-toolsをインストール

pfSenseはデフォルトではopen-vm-toolsがインストールされていない。ESXi上で動作させるためには導入が必要となることから、追加インストールを行う。

Web管理画面にて、System > Package Manager > Available Packagesを選択する。「Search term」にopen-vm-toolsを入力し検索するとパッケージが表示されるため、「Install」ボタンを押してインストールを行う。

冗長化

1. 冗長化用インタフェースのIPアドレスを設定

冗長化用インタフェースとしてOPT1を使用する。Web管理画面にてInterfaces > OPT1を選択し、「Enable」にチェックしOPT1のインタフェースを有効化したうえで、固定IPを設定する。

2. 冗長化用インタフェースに対するファイアウォールルール追加 (#1/#2両方で設定)

OPT1のインタフェースを有効にしただけではファイアウォールにルールが存在しないことから、暗黙のDenyにてすべての通信が拒否されてしまう。

pfSenseを冗長化するうえで必要となる通信を許可する必要があるため、Web管理画面にてFirewall > Rules > OPT1を選択し、以下に設定を行う。

設定項目 設定値
Action Pass
Protocol TCP/UDP
Source OPT1 net
Destination OPT1 address
Destination Port Range any

3. 「State Synchronization Settings」を有効化 (#1/#2両方で設定)

ファイアウォールの保持しているセッションのState tableをpfSense間で同期させるため、冗長構成となるすべてのpfSenseにて同期の設定を行う。

Web管理画面にてSystem > High Availability Syncを選択し、「State Synchronization Settings」を有効化する。

設定項目 設定値
Synchronize states チェックあり
Synchronize Interface OPT1
pfsync Synchronize Peer IP 対向のpfSenseのOPT1インタフェースのIPアドレス

4. 「Configuration Synchronization Settings」を有効化 (#1のみ)

pfSenseに対して設定変更した内容をpfSense間で同期させるため、冗長構成の中でメインとなるpfSenseのみに対して設定を行う。

Web管理画面にてSystem > High Availability Syncを選択し、「Configuration Synchronization Settings」を有効化する。

設定項目 設定値
Synchronize Config to IP 対向のpfSenseのOPT1インタフェースのIPアドレス
Remote System Username admin
Remote System Password adminユーザのパスワード
Select options to sync [Toggle All]ボタンを押してすべてをチェック

もしここまでの作業において、設定不備やネットワーク構成に問題がある場合は、Web管理画面の右上に「Communications error occurred」というエラーメッセージが表示される。再度設定やpfSenseのOPT1インタフェース間で問題なく通信ができることを確認しよう。

5. VIPを作成

最後に、冗長構成となったpfSense間で共有するVIPを作成する。Web管理画面にてFirewall > Virtual IPsを選択し、以下内容でWANとLANインタフェースのそれぞれに対してVIPを作成する。

設定項目 設定値
Type CARP
Interface WAN及びLANそれぞれで1つずつ作成
Address(es) 任意のIPアドレス
Virtual IP Password 任意のパスワード
VHID Group 重複しない任意の番号
Advertising frequency 1 (デフォルト値)

なお、pfSenseではVIP冗長化に「CARP (Common Address Redundancy Protocol)」と呼ばれるプロトコルを使用する。プロトコルの仕様として、VRRPとMACアドレスの生成ルールが共通となっているため、もし同一ネットワーク内にVRRPを使用している機器が存在する場合は、グループID (以下表のVHID Group) が重複しないよう注意すること。

フェイルオーバー動作確認

実際にpfSenseをフェイルオーバーした場合でも、通信が問題なくできることを確認する。

LAN側に配置した端末からpfSense経由でインターネットにアクセスしている際に、アクティブとなっているpfSenseをESXiにてシャットダウンさせてフェイルオーバーを発生させる。

結果としてはフェイルオーバー後も問題なくインターネットアクセスをすることができ、フェイルオーバー中のPingの欠落は1回 (1秒) のみとなることが確認できた。

参考

2021年4月25日日曜日

ZabbixでSNMPを使ってネットワーク機器のトラフィック量を取得する

ZabbixではSNMPを使って機器を監視する機能があり、特にネットワーク機器ではトラフィック量などを取得する場合に便利な機能となる。

今回は仮想ネットワークOSであるVyOSに対して、ZabbixからSNMPによる監視設定を行い、各インタフェースに発生しているトラフィック量をグラフで表示させる手順を記載する。

環境

  • Zabbix 5.0.10
  • VyOS 1.3

手順

1. 取得対象機器でSNMPを有効化

ZabbixでSNMPによる監視を実施するために、事前に監視対象機器にてSNMPの有効化を行う。

今回はVyOSの監視設定となるので、対象のVyOSにて以下の通り設定を行う。community名「public」をread-onlyで設定している。

# show service snmp
 community public {
     authorization ro
 }
 trap-source 192.168.11.33
 trap-target 192.168.11.24 {
     community public
 }

2. snmpwalkによるSNMP情報取得確認

取得対象スイッチ側で、SNMPを使って情報取得ができることを事前に確認しておく。ZabbixのOSにログインし、snmpwalkコマンドで確認すればよい。snmpwalkの使い方は以下の通り。

snmpwalk -v 2c -c <SNMP community名> <対象機器のIPアドレス>

snmpwalkを実行すると大量の情報が表示される。もし表示されないようであれば、情報取得対象の設定やコミュニティ名が誤っているなどが考えられるため、設定を確認しよう。

試しに私の環境でsnmpwalkすると以下のような表示結果となる。

# snmpwalk  -v 2c -c public 192.168.33.33
SNMPv2-MIB::sysDescr.0 = STRING: VyOS 1.3-rolling-202012311144
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.44641
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (10170228) 1 day, 4:15:02.28

~(中略)~

IF-MIB::ifNumber.0 = INTEGER: 3
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: VMware VMXNET3 Ethernet Controller
IF-MIB::ifDescr.3 = STRING: VMware VMXNET3 Ethernet Controller

~(中略)~

SNMPv2-SMI::mib-2.207.1.2.5.1.12.2.10.1 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::mib-2.207.1.2.5.1.12.3.10.1 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::mib-2.207.1.2.5.1.13.2.10.1 = Gauge32: 1000
SNMPv2-SMI::mib-2.207.1.2.5.1.13.3.10.1 = Gauge32: 1000

4. SNMP監視用のテンプレート「Template Module Interfaces Simple SNMPv2」を複製

SNMP機器の監視には、あらかじめZabbixに用意されている「Template Net Network Generic Device SNMPv2」を利用する。ただし、一部修正が必要となるため、本テンプレートを複製したのち修正を行うことにする。

「テンプレート」から「Template Module Interfaces Simple SNMPv2」を選択し、「すべて複製」を選択し、テンプレートを複製する。

今回は「Template Module Interfaces Simple SNMPv2 SNMPINDEX」という名称で複製を作成した。

5. ディスカバリルールのアイテムとグラフの名前を修正

「Template Module Interfaces Simple SNMPv2」をVyOSのような仮想ネットワークOSに対して適用すると、ディスカバリルールにて、以下エラーメッセージが表示される。

Cannot create graph: graph with the same name "Interface VMware VMXNET3 Ethernet Controller: Network traffic" already exists.

これは、SNMPのifDescrの値が重複しており、アイテムやグラフの名前が重複し作成に失敗したことを示すエラーとなる。エラーとなった場合は、情報が正しく取得・表示ができないので、修正対応を行う。

複製したテンプレートの「ディスカバリルール」にて、「Network interfaces discovery」を選択する。

ここで表示される「アイテムのプロトタイプ」と「グラフのプロトタイプ」にて、以下の通りアイテムとグラフの名前にifIndexの番号となる{#SNMPINDEX}を付与する。ifIndexはインタフェース毎に連番となり重複しないため、ifDescrが重複したとしても、異なるアイテム、グラフが作成される

Interface {#IFDESCR}: XXXX
   ↓
Interface {#IFDESCR} {#SNMPINDEX}: XXXX

▼アイテムのプロトタイプ


▼グラフのプロトタイプ


なお、普通のスイッチであればifDescrが重複することはないと思われる。例えばCiscoスイッチであれば、”GigabitEthernet 0/0”といった値で表示される。

6. 「Template Net Network Generic Device SNMPv2」のテンプレートを修正

「Template Net Network Generic Device SNMPv2」のテンプレートから「Template Module Interfaces Simple SNMPv2」を削除し代わりに複製した「Template Module Interfaces Simple SNMPv2 SNMPINDEX」を追加する。

7. ホストにSNMPインタフェースを設定

「設定」→「ホスト」にて監視対象ホストを選択し、「SNMPインターフェース」の箇所に、IPアドレスとポート番号(通常は161)を設定する。

8. ホストにテンプレートをリンク

ホストの設定のテンプレートに「Template Net Network Generic Device SNMPv2」を追加する。

1時間ほど待つと、特にエラーもなくSNMP情報の取得に成功するはずだ。取得されたインターフェースのトラフィック量は、グラフにて確認できる。MRTGなどと同じように、Incoming traffic (ポートから見て入力方向)とOutgoing traffic (ポートから見て出力方向)が一つのグラフで表示されるという一般的なものであり、他の監視ソフトを使っている人であっても違和感はないだろう。

以上で設定は完了となる。

VyOSの仕様によりテンプレートの修正対応が必要だったが、普通のスイッチであれば、ホストを登録し「Template Net Network Generic Device SNMPv2」のテンプレートをリンクするだけで設定が完了する。このようにZabbixでは、非常に簡単にネットワーク機器の監視が実現できる。

更新履歴

  • 2017/9/14 新規作成
  • 2021/4/25 Zabbix 5.0の環境に合わせて全面刷新

人気の投稿