重要性が増したSophos UTM9の担当箇所

我が家で長らく動いてるSophos UTM9。Home Editionライセンスで稼働していて、今ではかなり重要な経路を担当しています。

• サーバ用デフォルトゲートウェイ
• Office365向けインターネットゲートウェイ
• メールゲートウェイ
• Mastodon/Misskeyインスタンス用対外部Webゲートウェイ
• 内部ネットワーク/DMZ間のボーダールーター(OSPFv2)
• IPS

にも拘わらず長年シングル構成をとっていました。ってのも、なかなかHA構成を挑んでうまくいくことがなかったのです。

思い立って実行したが・・

はい。そこで思い立ってHA構成を組んでいこうと言うことでリソースを確保して実装しました。・・・が、早速初期化して間もないスタンバイノードのデータがPrimaryデータとして既存UTMに同期される始末・・・。一度は見事にUTMが全面初期化され、いろんな所に通信できなくなりました。

が、3点ほど気をつければきちんと設定できることが分かりました。取り敢えずこれを備忘録として記載しようと思います。

VirtualNICの順とUTMが認識する順は異なる

これは、もしかしたらVXNET3を使用している時に限り発生するのかもしれません。と言うのも、昔E1000として組んだ時はきちんと配列が対応できていたからです。VXNET3に切り替えて新規構築した時、ものの見事にNICの順序がずれてました。

解決策としては、きちんとVM側のMACアドレスの対応付けを確認することです。最初の時点ではまだShell Login出来る状態ではないので手探りになりますが、その後はCLIを実行可能にする、もしくはGUI上の インタフェースとルーティング->ハードウェア の画面にて、MACアドレスを確認することです。

Standbyにする側は、「自動構成」にすること

HAを構成する際、UTM9には3つの構成モードが存在します。

• OFF
• 自動構成
• ホットスタンバイ

実際には以下の通りであると理解しました。

• OFF->文字通り
• 自動構成->Standbyノードが参加する時に使用する
• ホットスタンバイ->Masterノードが使用する

最初にやらかした失敗は、間違いなくこれが原因でした。両者ともに手動で設定するという意味合いに受け止めてアクティブ＝パッシブモードにしていたのですが、何故かスプリットブレーンとなり、結果として初期化直後のスタンバイ機のConfigが正になってしまったのです。

というわけで、後で追加するノードは特に細かい設定は要らないので、かならずHAモード有効時は「自動構成」にしましょう。ライセンス含めて同期が行われるので、ぶっちゃけライセンスも要らないです。

VM環境ではVirtual MACアドレスは使用できない

これが一番はまったポイントでした。
HA構成にした場合、デフォルトでUTM9はVirtual MACアドレスを使用します。仮想NICのMACアドレスは、以下のような感じに定義されます。HA対象となるNICはeth0,1の2つです。eth2はHA通信用のポートになります。eth3は現状未使用です。

■1号機のMACアドレス
eth0	00:1a:8c:f0:40:e0
eth1	00:1a:8c:f0:40:e1
eth2	00:50:56:bf:e4:13
eth3	00:50:56:bf:66:ed

■2号機のMACアドレス
eth0	00:1a:8c:f0:40:e0
eth1	00:1a:8c:f0:40:e1
eth2	00:50:56:bf:71:2d
eth3	00:50:56:bf:d6:77

物理アプライアンスの場合、これで問題ありませんが、仮想環境の場合以下のような不具合が生じます。

• ESXi1にUTM1号機が存在する
• ESXi2にUTM2号機が存在する
• UTM1号機がMasterノードであり、2号機はSlaveノードである

このとき、実はESXi1号機に所属するVMしかUTMへアクセスできなくなります。
というのも、各ESXiのvSwitch上では双方に仮想MACアドレスが定義されています。そして、そのアービトレーションは上位の物理スイッチ上で行われ、有効なインタフェースであるMaster側のポートがARPテーブルに登録されてます。

以下は我が家のL3スイッチで確認されたARPテーブルの該当箇所です。

192.168.100.4   001a.8cf0.40e0  vlan10       sa3         dynamic

ESXi2に所属する側では、お隣のESXi1号機上にいるUTM9へ到達して欲しいと頃なんですが、自身のvSwitch上に存在するような形になります。そのためそこから本来のポートにたどり着けず、結果としてUTMに到達できなくなるようです。

解決策としては、Virtual MACアドレスの使用を以下のコマンドにて禁じます。CLI必須で、root権限にてコマンド実行をする必要があります。

# /usr/locl/bin/confd-client.plx set ha advanced virtual_mac 0

その後確認されたMACアドレスは以下の通りとなりました。

■1号機のアドレス
eth0	00:0c:29:5a:42:82
eth1	00:50:56:a7:67:14
eth2	00:50:56:bf:e4:13
eth3	00:50:56:bf:66:ed


■2号機のアドレス
eth0	00:50:56:bf:30:31
eth1	00:50:56:bf:04:13
eth2	00:50:56:bf:e4:13
eth3	00:50:56:bf:66:ed

スイッチ側も、Active側の仮想NICに割り当てられたMACアドレスが登録されています。

192.168.100.4   000c.295a.4282  vlan10       sa2         dynamic

HA化すると、上記のようにGUIからどちらがMasterノードになるのか分かるようになっています。我が家ではプライマリノードを1号機に定めているので、フェイルオーバーした後にMasterノードが復帰すると自動的にフォールバックするようになっています。

これとNginxが握っているリバースプロキシ部分を冗長化することで現在分散SNSをフル冗長構成にすることを考えています。本当はH2OというHTTPサーバを組み合わせてそれを実現できてた・・・はずなんですが、土壇場になってうまく外部からアクセスできず・・・

こちらはこちらで記事作成途上で悩んでる最中なんですが、コツコツ組み立てていきたいと思います。