はじめに
本記事は、VMware Workstation Pro上にBIG-IP Virtual Edition（BIG-IP VE）の検証環境を構築するシリーズの最終回です。
本シリーズでは、以下の環境構築を目標としています。
- VMware Workstation Pro上にBIG-IP VEを2台構築し、Active/Standby構成で冗長化する。
- BIG-IPのVirtual Serverを利用して、バックエンドのWebサーバ（Zabbix）へのアクセスを実現する。
- ロードバランシング、SNAT、Cookie Persistenceなどの動作を確認できる学習環境を構築する。
前回までに、BIG-IPの冗長化、リアルサーバの準備、Virtual Serverの設定が完了しました。
今回は、検証用端末としてRocky Linux 9を導入し、Virtual Server経由でZabbixのWebコンソールへアクセスできることを確認します。
また、Cookie Persistenceによる接続先サーバの固定や、通信できない場合のトラブルシューティングについても解説します。
検証環境の構成
今回の検証で使用する機器と通信経路を整理します。
ネットワーク構成図
以下は、今回の通信確認に関係する部分を抜き出した論理構成図です。
※ 実際の物理・仮想インターフェースの接続関係は簡略化しています。また、Active/Standbyでは通常、Active側が対象Traffic Groupの通信を処理します。
今回使用するIPアドレス
| 機器・オブジェクト | IPアドレス | 役割 |
|---|---|---|
| 検証用端末 | 172.16.1.2/24 | Webアクセス元 |
| vyos-01 | 172.16.1.254 | 検証端末側のNext Hop |
| BIG-IP Virtual Server | 192.168.1.1 | HTTPアクセス先のVIP |
| BIG-IP SNAT Pool | 192.168.2.1 | サーバ側通信の送信元アドレス変換 |
| zabbix-01 | 前回設定したアドレス | リアルサーバ |
| zabbix-02 | 前回設定したアドレス | リアルサーバ |
今回、検証用端末は172.16.1.0/24に配置します。
Virtual ServerのIPアドレスは192.168.1.1です。
異なるネットワークに配置されているため、VyOSを経由するStatic Routeを設定する必要があります。
Rocky Linux 9のインストール
検証用端末としてRocky Linux 9を使用します。
Rocky Linuxは、Red Hat Enterprise Linux（RHEL）との互換性を目指して開発されているLinuxディストリビューションです。
ISOイメージは以下の公式サイトからダウンロードできます。
VMware Workstation Proへのインストールは、通常のLinux仮想マシンの作成手順と同様です。
仮想マシンの作成ウィザードからISOイメージを指定し、Rocky Linux 9をインストールしてください。
ネットワークアダプタの追加
インストール後、VMware Workstation Proで仮想マシンのネットワーク設定を変更します。
本環境では、検証用端末をホストオンリーネットワークであるVMnet1に接続します。
手順は以下のとおりです。
- Rocky Linuxの仮想マシンをシャットダウンします。
- VMware Workstation Proで対象仮想マシンの設定画面を開きます。
- 「ハードウェア」から「追加」をクリックします。
- 「ネットワーク アダプタ」を追加します。
- 「ネットワーク接続」で「カスタム」を選択します。
- 仮想ネットワークに
VMnet1（ホストオンリー）を指定します。 - 設定を保存し、仮想マシンを起動します。
既存のネットワークアダプタをVMnet1に変更しても構いませんが、今回は2つ目のネットワークアダプタを追加する方法で進めます。
VMnet1にVMwareのDHCPサーバが設定されている場合、固定IPアドレスとの競合が発生しないようにしてください。
また、VMnet1のサブネットが今回の172.16.1.0/24と一致しているか確認してください。既存アダプタがブリッジ接続の場合、検証ネットワーク以外への接続にも注意が必要です。
Rocky LinuxのIPアドレス設定
Rocky Linuxのインストールが完了したら、追加したネットワークアダプタに固定IPアドレスを設定します。
今回設定する値は以下のとおりです。
| 設定項目 | 設定値 |
|---|---|
| インターフェース | ens224 |
| IPv4アドレス | 172.16.1.2 |
| サブネットマスク | 255.255.255.0 |
| Prefix Length | /24 |
| Next Hop | 172.16.1.254 |
| Static Route宛先 | 192.168.1.0/24 |
※ インターフェース名は仮想NICの認識順序によって異なります。
1. ネットワーク設定画面を開く
Rocky Linuxへコンソール接続します。
デスクトップ画面右上のネットワークアイコンをクリックし、ネットワーク設定画面を開きます。
追加したネットワークアダプタに対応するEthernet（ens224）を選択します。
接続が無効の場合は有効化してください。
続いて、設定画面の歯車アイコンをクリックします。
2. IPv4アドレスを設定する
ネットワーク設定画面から「IPv4」タブを選択します。
IPv4メソッドを「手動（Manual）」に変更します。
以下のアドレスを設定してください。
| 項目 | 入力値 |
|---|---|
| Address | 172.16.1.2 |
| Netmask | 255.255.255.0 |
| Gateway | 空欄 |
今回は追加したインターフェースにデフォルトゲートウェイを設定せず、後述するStatic RouteでVirtual Server宛ての通信を制御します。
別のネットワークアダプタにデフォルトゲートウェイを設定している場合、今回の検証用インターフェースにもデフォルトゲートウェイを設定すると、意図しない経路選択が発生する場合があります。
3. Static Routeを設定する
次に、Virtual Serverが存在するネットワークへのStatic Routeを追加します。
設定するStatic Routeは以下のとおりです。
| 項目 | 設定値 |
|---|---|
| Destination | 192.168.1.0 |
| Netmask | 255.255.255.0 |
| Gateway / Next Hop | 172.16.1.254 |
| Metric | 必要に応じて設定 |
これにより、検証用端末から192.168.1.0/24宛ての通信は、vyos-01（172.16.1.254）へ転送されます。
宛先: 192.168.1.0/24
|
v
Next Hop: 172.16.1.254
|
v
vyos-01
|
v
BIG-IP Virtual Server
設定が完了したら、「適用（Apply）」をクリックします。
4. ネットワーク設定を反映する
GUIからネットワーク設定を変更した場合、接続の再有効化が必要になることがあります。
ネットワーク接続を一度OFFにしてから、再度ONにしてください。
その後、ターミナルを開き、IPアドレスが反映されていることを確認します。
ip -br addr
ens224に172.16.1.2/24が設定されていれば問題ありません。
続いて、ルーティングテーブルを確認します。
ip route
今回設定したStatic Routeが登録されていることを確認してください。
192.168.1.0/24 via 172.16.1.254 dev ens224
さらに、Virtual Server宛ての実際の経路を確認します。
ip route get 192.168.1.1
想定どおりであれば、172.16.1.254をNext Hopとし、ens224から送信する経路が表示されます。
検証用端末からの疎通確認
続いて、検証用端末から各機器に対して疎通確認を行います。
1. vyos-01への疎通確認
Rocky Linuxのターミナルを開き、以下のコマンドを実行します。
ping -c 3 172.16.1.254
応答が返ってくれば、検証用端末とvyos-01の間でIP通信が成立していることを確認できます。
通信できない場合は、以下を確認してください。
- VMware Workstation ProのネットワークアダプタがVMnet1に接続されているか。
- Rocky LinuxのIPアドレスとサブネットマスクが正しいか。
- VyOS側のインターフェースが有効になっているか。
- VMwareの仮想ネットワークのサブネット設定に誤りがないか。
2. Virtual Serverへの疎通確認
続いて、BIG-IPのVirtual Serverに対してICMP疎通確認を行います。
ping -c 3 192.168.1.1
応答があれば、Virtual ServerのIPアドレスまで到達可能であることを確認できます。
ただし、BIG-IP側のICMP Echo設定によっては、Virtual Serverが正常に稼働していてもPingに応答しない場合があります。
そのため、ICMPだけでなくHTTP通信も確認することが重要です。
curl -v http://192.168.1.1/
HTTPレスポンスが返ってくることを確認してください。
Virtual Server経由でZabbixへアクセスする
ここからは、実際にWebブラウザを使用してZabbixのWebコンソールへアクセスします。
1. Firefoxを起動する
Rocky Linuxのデスクトップ画面から「アクティビティ」をクリックし、Firefoxを起動します。
アドレスバーへ以下のURLを入力します。
http://192.168.1.1
Zabbixのログイン画面が表示されれば、BIG-IPのVirtual Serverを経由してリアルサーバにアクセスできています。
今回の通信経路は以下のとおりです。
BIG-IPでは、Virtual Serverに設定したPoolから接続先のリアルサーバを選択し、リクエストを転送しています。
また、今回の構成ではSNAT Poolを使用しているため、サーバ側の通信では送信元IPアドレスがSNAT Poolのアドレスへ変換されます。
2. Zabbixへログインする
Zabbixのログイン画面が表示されたら、管理者アカウントでログインします。
Zabbixの初期設定を変更していない検証環境では、以下の初期認証情報が使用される場合があります。
| 項目 | 値 |
|---|---|
| ユーザー名 | Admin |
| パスワード | zabbix |
※ 初期認証情報はバージョンや導入方法により異なる場合があります。実運用では必ず初期パスワードを変更してください。
正常にログインできれば、HTTP通信だけでなく、ZabbixのWebアプリケーションが利用できることも確認できます。
Cookie Persistenceの動作確認
前回の記事では、Virtual ServerにCookie Persistenceを設定しました。
ここでは、その動作を確認します。
Cookie Persistenceとは
Cookie Persistenceは、HTTP Cookieを利用してクライアントからのリクエストを同じPool Memberへ振り分ける仕組みです。
一般的なロードバランシングでは、負荷分散アルゴリズムに基づいて接続先のサーバが選択されます。
しかし、Webアプリケーションによっては、ログイン後のリクエストが別のサーバへ振り分けられると、セッション情報を正常に引き継げない場合があります。
Cookie Persistenceを利用すると、クライアントのブラウザに保存されたCookieをもとに、同じPool Memberへの振り分けを継続できます。
今回の例では、最初にzabbix-01が選択され、その後もCookieに基づいて同じサーバへ振り分けられる動作を確認します。
この方式では、同じブラウザで繰り返し操作しても、Cookieが有効な間は原則として同じPool Memberが選択されます。
ただし、対象サーバの障害やPersistence設定の変更などによって、振り分け先が変わる場合があります。
Cookie Persistenceを確認する手順
- Firefoxから
http://192.168.1.1へアクセスします。 - Zabbixにログインします。
- Webコンソール内の各画面を移動します。
- BIG-IPの管理画面でPool Memberの統計情報を確認します。
- 同じPool Memberに対する通信が継続していることを確認します。
Cookie Persistenceが正常に動作していれば、同じブラウザでのアクセスは、基本的に最初に選択されたリアルサーバへ継続して転送されます。
BIG-IPのPool統計情報を確認する
BIG-IPの管理画面で、以下のメニューを開きます。
Local Traffic > Pools > Pool List
対象Poolを選択し、統計情報（Statistics）を確認します。
ここでは、zabbix-01とzabbix-02の通信量やコネクション数を確認します。
今回の検証では、zabbix-01への通信が継続していることを確認できました。
ただし、統計情報には過去の通信が累積されている場合があるため、画面上の値がそのまま現在のセッション数を表しているとは限りません。
できれば、検証前後でカウンタの増分を比較してください。
CLIから確認する場合は、以下のコマンドも利用できます。
tmsh show ltm virtual
tmsh show ltm pool
さらに、ブラウザの開発者ツールからHTTPレスポンスヘッダーを確認することで、BIG-IPが挿入したPersistence Cookieを確認できる場合があります。
別のブラウザセッションで検証する
Cookie Persistenceの挙動を詳しく確認したい場合は、Firefoxのプライベートウィンドウや別のブラウザプロファイルを使用してみてください。
Cookieを共有しない独立したセッションであれば、初回リクエスト時に新しくPool Memberが選択されます。
ただし、別セッションだからといって、必ず別のリアルサーバに振り分けられるわけではありません。
実際の振り分け先は、ロードバランシング方式、Pool Memberの状態、既存のコネクションなどによって変わります。
トラブルシューティング
Virtual Serverへアクセスできない場合、ネットワークのどこで通信が失敗しているかを切り分けることが重要です。
今回の環境では、以下の順番で確認します。
- 検証用端末からvyos-01への通信
- vyos-01からVirtual Serverへの通信
- Virtual Serverの稼働状態
- BIG-IPからリアルサーバへの通信
- SNATと戻り経路
- ZabbixのWebサービス
1. vyos-01からVirtual ServerへPingを実行する
まず、vyos-01へログインします。
Virtual ServerのIPアドレスである192.168.1.1に対してPingを実行します。
vyos@vyos-1:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.681 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.907 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.921 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2063ms
rtt min/avg/max/mdev = 0.681/0.836/0.921/0.109 ms
今回の検証では、正常に応答が返ってきています。
ただし、前述のとおりVirtual ServerのICMP Echo設定によって応答の有無が変わるため、Pingだけで正常性を判断しないようにしてください。
2. vyos-01から検証用端末へPingを実行する
続いて、検証用端末のIPアドレスである172.16.1.2へPingを実行します。
vyos@vyos-1:~$ ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2) 56(84) bytes of data.
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=0.726 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=64 time=0.472 ms
64 bytes from 172.16.1.2: icmp_seq=3 ttl=64 time=0.392 ms
^C
こちらも正常に応答が返ってきています。
この結果から、vyos-01と検証用端末の間で双方向のIP通信が可能であることを確認できます。
3. ZabbixサーバからSNAT PoolのアドレスへPingを実行する
次に、リアルサーバからBIG-IP側への通信を確認します。
今回の構成では、SNAT Poolとして192.168.2.1を使用しています。
zabbix-01とzabbix-02の両方から、以下のコマンドを実行します。
ping -c 3 192.168.2.1
今回の検証では、以下のような応答を確認できました。
[root@zabbix-02 ~]# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=254 time=1.19 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=254 time=1.24 ms
^C
ただし、SNAT Poolのアドレスに対してICMP応答が返るかどうかは、BIG-IPの設定やネットワーク構成によって異なります。
SNAT Poolのアドレスは、SNATによって変換される送信元アドレスとして利用されるものであり、Ping応答があることはSNAT処理そのものの正常性を証明するものではありません。
実際のHTTP通信を確認することが重要です。
4. BIG-IPのVirtual Serverの状態を確認する
BIG-IPにログインし、Virtual Serverの状態を確認します。
GUIでは以下を開きます。
Local Traffic > Virtual Servers > Virtual Server List
確認する項目は以下のとおりです。
| 確認項目 | 確認内容 |
|---|---|
| Availability | Virtual Serverが利用可能か |
| State | Virtual Serverが有効化されているか |
| Destination | 192.168.1.1:80が設定されているか |
| Default Pool | 正しいPoolが指定されているか |
| Source Address Translation | SNAT Poolが指定されているか |
| Persistence | Cookie Persistenceが設定されているか |
CLIからは以下のコマンドで確認できます。
tmsh show ltm virtual
設定内容も確認する場合は以下を実行します。
tmsh list ltm virtual
5. Pool Memberの状態を確認する
Virtual Serverが正常に動作していても、Pool Memberが利用できなければWebアクセスは成功しません。
以下のメニューからPool Memberの状態を確認します。
Local Traffic > Pools > Pool List
確認する項目は以下のとおりです。
-
zabbix-01とzabbix-02がPoolに登録されているか。 - Pool Memberが有効になっているか。
- Health Monitorの状態が正常か。
- 設定したサービスポートでWebサービスが待ち受けているか。
CLIでは以下のコマンドで確認できます。
tmsh show ltm pool
Pool Memberが利用不可の場合、Health Monitorの設定やWebサーバ側のサービス状態を確認してください。
6. ZabbixサーバのHTTPサービスを確認する
Zabbixサーバにログインし、Webサーバが起動していることを確認します。
例えばApacheを利用している場合は、以下のコマンドを実行します。
sudo systemctl status httpd
HTTPの待ち受けポートも確認します。
sudo ss -lntp | grep ':80'
HTTPで応答できるかを確認します。
curl -I http://127.0.0.1/
正常に応答が返る場合は、Webサーバ自体が動作していると判断できます。
ただし、ZabbixのWeb画面が実際に表示できるかについては、PHPやZabbix関連サービスなども含めた確認が必要です。
7. パケットキャプチャによる切り分け
ここまで確認しても通信できない場合は、パケットキャプチャを利用します。
Rocky Linuxの検証用端末では、次のように実行します。
sudo tcpdump -ni ens224 host 192.168.1.1
別のターミナルからHTTPアクセスを実行します。
curl -v http://192.168.1.1/
TCPの3ウェイハンドシェイクが成立しているか、HTTPレスポンスが返ってきているかを確認します。
BIG-IP側でも、対象VLANのインターフェースや送信元・宛先IPアドレスを指定してパケットキャプチャを取得することで、通信の流れを追跡できます。
また、SNATを利用している構成では、クライアント側とサーバ側でIPアドレスが変換されるため、それぞれの区間でキャプチャ条件を変更する必要があります。
まとめ
今回は、Rocky Linux 9を検証用端末として構築し、BIG-IPのVirtual Server経由でZabbixのWebコンソールにアクセスできることを確認しました。
今回確認した主なポイントは以下のとおりです。
- 検証用端末をVMnet1に接続し、固定IPアドレスを設定できた。
- Static Routeによって、VyOS経由でVirtual Serverへ通信できた。
- Virtual Server経由でZabbixのログイン画面にアクセスできた。
- Cookie Persistenceを利用し、同一ブラウザからのアクセスを同じPool Memberへ振り分けられた。
- BIG-IPの統計情報を利用して、実際の負荷分散先を確認できた。
- Ping、HTTPアクセス、BIG-IPの状態確認によって通信障害を切り分ける方法を整理できた。
これで、VMware Workstation Pro上でBIG-IPのActive/Standby構成を構築し、リアルサーバへの負荷分散を検証する一連の環境が完成しました。
今回の環境では、ロードバランシングだけでなく、SNAT、Persistence、Active/Standby切り替え時の通信なども学習できます。
今後は、Active側のBIG-IPを停止させたときのフェイルオーバー、Pool Memberの障害発生時の振り分け、Health Monitorの動作などを試すと、さらに理解が深まると思います。