言語: English | 日本語

本書では、サイト間クラスタリングを含む、Cisco Secure Firewall の個別インターフェイス モードによるクラスタリング導入のリファレンス アーキテクチャを包括的に説明します。単一または複数の地理的拠点にまたがる、優れた耐障害性と冗長性を備えたファイアウォール クラスタを構築するための設計原則、具体的な設定、および運用面について詳しく解説します。個々のノード障害、インターフェイス障害、サイト全体の停止など、一連の障害シナリオをシミュレーションし、クラスタがステートフルな接続を維持してトラフィック フローを継続できることを示すとともに、このアーキテクチャに備わる強力な高可用性とディザスタ リカバリの機能を紹介します。

本ガイドは主に、Cisco Secure Firewall を使用した高度で可用性の高いセキュリティ インフラストラクチャの設計、実装、および検証を担当するネットワーク アーキテクト、セキュリティ エンジニア、および技術コンサルタントを対象としています。ネットワークの概念、Cisco Secure Firewall の動作、およびルーティング プロトコルについて、基礎的な知識があることを前提としています。

クラスタリングの基礎

Cisco のファイアウォール クラスタリングは、複数のファイアウォールを単一の論理ユニットに統合します。接続されたルータやスイッチは、クラスタ全体を個別のファイアウォールではなく、1 つのユニットとして認識します。クラスタは、スループットの向上と、ステートフル フェールオーバーによる冗長性の確保を目的として構築されます。クラスタ全体のスループットは、個々のノードのスループットを合計した値の 80% です。残りの 20% は、フローの作成と維持に伴う CPU およびメモリのオーバーヘッドと、クラスタ制御リンクのトラフィックに使用されます。必要なスループットを N 台のファイアウォールで確保できる場合は、クラスタに N+1 台のファイアウォールを導入することを推奨します。これにより、ファイアウォール 1 台に障害が発生しても、クラスタのスループットに影響しません。クラスタには 1 台のコントロールノードがあり、残りはデータノードです。すべてのノードが通過する接続を処理し、クラスタ内にスタンバイ モードのノードはありません。

クラスタと高可用性の比較

クラスタ:

高可用性:

クラスタ制御リンク (CCL)

CCL は、クラスタ内の通信に使用する、分離された高速バックプレーン ネットワークです。クラスタ内の各ユニットの専用インターフェイスをスイッチに接続してクラスタ制御リンクを構成し、制御トラフィックとデータ トラフィックを伝送します。各クラスタ制御リンクには、同一サブネット上の IP アドレスが割り当てられます。このサブネットは、他のすべてのトラフィックから分離し、クラスタ制御リンクのインターフェイスだけを含める必要があります。CCL は、設定のレプリケーションやコントロールノードの選出などの制御トラフィック、ハートビート パケット、および他のノードからトラフィック フローの接続オーナーに送られるデータ トラフィックを伝送します。接続は接続オーナーが所有し、その接続に属するパケットが接続オーナー以外のノードに届くと、CCL 経由で接続オーナーに転送されます。

CCL のオーバーヘッドは 100 バイトのため、CCL の MTU はデータ インターフェイスの MTU より少なくとも 100 バイト大きくすることを推奨します。仮想クラスタの場合は、VXLAN のオーバーヘッドとしてさらに 54 バイトが必要になるため、CCL の MTU をデータ インターフェイスの MTU より少なくとも 154 バイト大きくする必要があります。

以下の要件と推奨事項を満たしていれば、クラスタリングは Cisco のスイッチおよび他の主要スイッチ ベンダーの Cisco 以外のスイッチのいずれでも動作し、既知の相互運用性の問題はありません。クラスタリングは、vPC (Nexus)、VSS (Catalyst)、StackWise および StackWise Virtual (Catalyst) などのテクノロジーに対応しています。

スイッチの要件

• すべてのサードパーティ製スイッチは、IEEE 標準 (802.3ad) の Link Aggregation Control Protocol に準拠している必要があります。
• Firepower デバイスに接続した場合、EtherChannel のバンドルを 45 秒以内に完了する必要があります。
• クラスタ制御リンクでは、すべてのクラスタ メンバー間で、レイヤ 2 のユニキャストおよびブロードキャスト接続が一切妨げられないようにする必要があります。
• クラスタ制御リンクでは、スイッチが IP アドレッシングやレイヤ 2 ヘッダーより上位のパケット形式に制限を設けてはなりません。
• クラスタ制御リンクでは、スイッチ インターフェイスがジャンボ フレームをサポートし、1600 を超える MTU を設定できる必要があります。

スイッチに関する推奨事項

• スイッチは、EtherChannel の各リンクにトラフィックを均等に分散できる必要があります。
• スイッチには、トラフィックの対称性を確保できる EtherChannel のロード バランシング アルゴリズムが必要です。
• EtherChannel のロード バランシング用ハッシュ アルゴリズムは、5 タプル、4 タプル、または 2 タプルを使用してハッシュを計算するよう設定できる必要があります。

接続のロール
ファイアウォール クラスタを通過する各接続には、以下の主なロールが定義されています。

1. 接続オーナー (Owner) - 接続を最初に受信するノードです。各接続の接続オーナーは 1 台だけです。
2. バックアップオーナー (Backup Owner) - 接続オーナーから受信した TCP/UDP の状態情報を保存するノードです。障害が発生した場合、接続を新しい接続オーナーにシームレスに引き継ぐことができます。
3. ディレクタ (Director) - フォワーダからの接続オーナー検索要求を処理するノードです。
4. フォワーダ (Forwarder) - パケットを接続オーナーに転送するノードです。

クラスタのモード

ファイアウォール クラスタは、個別インターフェイス モードとスパンド EtherChannel モードの 2 つのモードで導入できます。それぞれレイヤ 3 とレイヤ 2 で動作します。

個別インターフェイス モードでは、各ユニットが、IP アドレスの範囲であるクラスタ プールから固有のインターフェイス IP アドレスを取得します。また、固定のメイン クラスタ IP アドレスがあり、常にコントロールノードに属します。トラフィックのロード バランシングは、接続されたルータまたはスイッチで、ポリシー ベース ルーティング (PBR)、等コスト マルチパス (ECMP)、または Intelligent Traffic Director (ITD) を使用して行う必要があります。ECMP によるロード バランシングには、スタティック ルーティングまたはダイナミック ルーティング プロトコルを使用できます。ノード障害時にルートが自動的に更新されるため、ダイナミック ルーティング プロトコルを推奨します。

下図では、x.x.x.1 と y.y.y.1 がメイン クラスタ IP アドレスです。

一方、スパンド インターフェイス モードでは、各ユニットの対応するインターフェイスを EtherChannel にバンドルし、送信元または宛先の IP アドレスと TCP および UDP のポート番号に基づく EtherChannel 独自のハッシュ アルゴリズムで、トラフィックをロード バランシングします。パブリック クラウドではレイヤ 2 のセマンティクスがサポートされず、プライベート クラウドでは EtherChannel がサポートされないため、仮想 FTD ではスパンド インターフェイス モードはサポートされません。

サイト間クラスタ

地理的に異なる 2 つ以上の拠点（サイト）にまたがるクラスタを、サイト間クラスタと呼びます。ここでは、クラスタ ノードにサイト ID を指定して設定します。

スパンド インターフェイス モードの場合、CCL をサイト間でレイヤ 2 に拡張し、データ インターフェイスを分割スパンド EtherChannel インターフェイス モードに設定します。このモードでは、EtherChannel はスイッチ側では各サイト内で構成され、ファイアウォール クラスタ側ではサイト間にまたがります。

個別インターフェイス モードの場合も CCL をレイヤ 2 で拡張しますが、データ インターフェイスにはそれぞれ固有の IP アドレスを設定します。以下の例では、Port-Channel 1 (Po1) がファイアウォール側に、Port-Channel 10 および 11 (Po10 および Po11) がスイッチ側にあります。

クラスタの利点

1. アクティブ/アクティブ - Cisco Secure Firewall は、すべてのファイアウォール ノードがセキュリティの適用を同時に実行できるアクティブ/アクティブのクラスタリングをサポートし、リソース使用率を最適化します。
2. シームレスな拡張性 - Secure Firewall クラスタリングは、トラフィックを中断することなく最大 16 台まで拡張でき、非対称トラフィックのステートフルな処理と障害復旧を提供します。
3. 管理の一元化 - Secure Firewall は、統合されたレポートと管理を提供します。単一の統合ポリシーを持つ 1 台のデバイスとしてクラスタ全体を管理することで、運用を簡素化します。
4. 接続状態のレプリケーション - クラスタ制御リンク (CCL) は、状態のレプリケーションと接続の所有権の照会を支援します。これにより、コントロールノードに障害が発生しても接続状態が保持され、他のノードへシームレスに引き継がれます。

リファレンス トポロジ

この例では、SITE 1 と SITE 2 の 2 つのサイトを使用し、各サイトにファイアウォール、ルータ、およびスイッチを配置します。各サイトに 2 ノードずつ配置し、4 ノードのクラスタを構築します。

構成要素

ファイアウォール（ハードウェア モデル FPR4245）はルーテッド モードで動作し、ここでは個別インターフェイス モードのクラスタを使用します。

a. ファイアウォール

上記のトポロジで強調表示されているデバイスは、SITE 1 と SITE 2 の 2 つのサイトに配置されたファイアウォールです。
SITE 1 のファイアウォールは次のとおりです。

1. etihad
2. allegiant

SITE 2 のファイアウォールは次のとおりです。

3. frontier
4. spirit

b. CCL スイッチ

クラスタを通るすべての CCL トラフィックを制御するクラスタ制御リンク (CCL) スイッチは次のとおりです。
• airlines37

このトポロジでは、両サイトで同じスイッチを使用しています。これは、CCL をレイヤ 2 で延伸する必要があることに対応しています。

c. データ スイッチ

クラスタのデータ インターフェイスを接続するデータ スイッチは次のとおりです。

SITE1:

1. sudan
2. angola

SITE2:

1. qatar
2. Vistara

d. ロード バランシング用ルータ

前述のとおり、個別インターフェイス モードのクラスタでは、接続されたルータがロード バランシングを行います。このトポロジでは、上図で強調表示されたルータとファイアウォール ユニットの間でネイバー関係を確立し、ルーティング プロトコル BGP によりクラスタへのロード バランシングを行います。

SITE1:

1. africa20
2. arsenal

SITE2:

1. asiana
2. bakerstreet

e. クライアント側およびサーバ側のスイッチ

トラフィック ジェネレータに接続するスイッチは次のとおりです。

1. africa22 – クライアント側
2. brighton – サーバ側

IP サブネット 10.101.0.0/16（クライアント）および 20.201.0.0/16（サーバ）では SITE1 経由のルートを優先し、IP サブネット 10.102.0.0/16（クライアント）および 20.202.0.0/16（サーバ）では SITE 2 経由のルートを優先します。

設定

本書に記載する設定の抜粋は、ファイアウォールの設定も含め、すべて CLI から取得したものです。ただし、使用したファイアウォールは FTD であり、設定自体は Firewall Management Center の UI を使用して行いました。

a. ファイアウォール (Etihad)

クラスタの設定:

cluster group cluster
 local-unit fp4245-1
 cluster-interface Port-channel48 ip 10.10.4.1 255.255.255.224
 priority 1
 health-check holdtime 3
 health-check data-interface auto-rejoin 3 5 2
 health-check cluster-interface auto-rejoin unlimited 5 1
 health-check system auto-rejoin 3 5 2
 health-check monitor-interface debounce-time 500
 site-id 1
 site-redundancy
 no health-check monitor-interface Management1/1
 no health-check monitor-interface Management1/2
 enable
 director-localization
no cluster replication delay http
!

ファイアウォール ユニットの名前は次のとおりです。
• etihad - fp4245-1
• allegiant - fp4245-2
• frontier - fp4245-3
• spirit - fp4245-4

設定した SITE ID は次のとおりです。
• etihad – site-id 1
• allegiant – site-id 1
• frontier – site-id 2
• spirit – site-id 2

CCL のサブネットとして 10.10.4.1/255.255.255.224 を使用し、各ファイアウォールにこのサブネットから 1 つずつ IP アドレスを割り当てます。

インターフェイスの設定:

bfd-template single-hop BFDTemplate
 interval min-tx 100 min-rx 100 multiplier 3
!
ip local pool Inside-pool 10.0.255.10-10.0.255.15 mask 255.255.255.0
ip local pool Outside-pool 20.0.255.10-20.0.255.15 mask 255.255.255.0
!
interface Port-channel1
 nameif data
 security-level 0
 no ip address
!
interface Port-channel1.10
 vlan 10
 nameif outside
 security-level 0
 ip address 10.0.255.16 255.255.255.0 cluster-pool Inside-pool 
 bfd template BFDTemplate
!
interface Port-channel1.20
 vlan 20
 nameif inside
 security-level 0
 ip address 20.0.255.16 255.255.255.0 cluster-pool Outside-pool 
 bfd template BFDTemplate
!

直接接続するシングルホップのインターフェイスでは、Bidirectional Forwarding Detection (BFD) を有効にします。BFD は、小さな「hello」パケットをネイバーに定期的に送信することで、2 台のデバイス間の転送パスの障害を検出する、非常に高速なプロトコルです。これらのパケットが所定の回数受信されないと、BFD はリンクまたはパスのダウンを速やかに通知します。

IP アドレス 10.0.255.16/255.255.255.0 および 20.0.255.16/255.255.255.0 は、コントロールノード eithad に属するメイン クラスタ IP アドレスです。コントロールノードを含め、クラスタ内のすべてのノードが、設定されたクラスタ プールから IP アドレスを取得します。

BGP の設定:

ip local pool clusterpool 0.0.0.1-0.0.0.4 mask 255.255.255.0
router bgp 65000
 bgp log-neighbor-changes
 bgp router-id cluster-pool clusterpool
 address-family ipv4 unicast
  neighbor 10.0.255.1 remote-as 65111
  neighbor 10.0.255.1 ebgp-multihop 255
  neighbor 10.0.255.1 transport path-mtu-discovery disable
  neighbor 10.0.255.1 fall-over bfd single-hop
  neighbor 10.0.255.1 activate
  neighbor 20.0.255.1 remote-as 65112
  neighbor 20.0.255.1 ebgp-multihop 255
  neighbor 20.0.255.1 transport path-mtu-discovery disable
  neighbor 20.0.255.1 fall-over bfd single-hop
  neighbor 20.0.255.1 activate
  neighbor 10.0.255.2 remote-as 65001
  neighbor 10.0.255.2 ebgp-multihop 255
  neighbor 10.0.255.2 transport path-mtu-discovery disable
  neighbor 10.0.255.2 fall-over bfd single-hop
  neighbor 10.0.255.2 activate
  neighbor 20.0.255.2 remote-as 65002
  neighbor 20.0.255.2 ebgp-multihop 255
  neighbor 20.0.255.2 transport path-mtu-discovery disable
  neighbor 20.0.255.2 fall-over bfd single-hop
  neighbor 20.0.255.2 activate
  redistribute connected
  no auto-summary
  no synchronization
 exit-address-family
!

設定した BGP ネイバーは次のとおりです。

• africa20 (10.0.255.1)
• arsenal (20.0.255.1)
• asiana (10.0.255.2)
• bakerstreet (20.0.255.2)

b. CCL スイッチ (airlines37)

インターフェイスの設定:

vlan 1,48
vlan 48
  name clusterlink
interface port-channel1
  switchport
  switchport access vlan 48
  spanning-tree port type edge
  mtu 9000
interface port-channel2
  switchport
  switchport access vlan 48
  spanning-tree port type edge
  mtu 9000
interface port-channel3
  switchport
  switchport access vlan 48
  spanning-tree port type edge
  mtu 9000
interface port-channel4
  switchport
  switchport access vlan 48
  spanning-tree port type edge
  mtu 9000
interface Ethernet1/9
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 1 mode active
  no shutdown
interface Ethernet1/10
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 1 mode active
  no shutdown
interface Ethernet1/11
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 2 mode active
  no shutdown
interface Ethernet1/12
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 2 mode active
  no shutdown
interface Ethernet1/13
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 3 mode active
  no shutdown
interface Ethernet1/14
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 3 mode active
  no shutdown
interface Ethernet1/15
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 4 mode active
  no shutdown
interface Ethernet1/16
  switchport
  switchport access vlan 48
  mtu 9000
  channel-group 4 mode active
  no shutdown

各ファイアウォールからのインターフェイスを Port-Channel として設定します。たとえば、etihad に接続する Ethernet 1/9 と Ethernet 1/10 で Port-Channel 1 を構成し、allegiant に接続する Ethernet 1/11 と Ethernet1/12 で Port-Channel 2 を構成します。その他も同様です。

c. データ スイッチ

c.1. Sudan

VPC の設定:

vpc domain 10
  peer-switch
  peer-keepalive destination 198.18.175.138 source 198.18.175.135

c.2. Angola

VPC の設定:

vpc domain 10
  peer-switch
  peer-keepalive destination 198.18.175.135 source 198.18.175.138

SITE1 のスイッチ sudan と angola は VPC ペアを構成します。同様に、SITE 2 の qatar と vistara も VPC ペアを構成します。Ethernet 1/11 を VPC ピアリンクとして使用します。

c.1. Sudan

インターフェイスの設定:

vlan 1,10,20
interface port-channel9
  switchport
  switchport access vlan 10
  spanning-tree port type edge
  vpc 9
interface port-channel10
  switchport
  switchport access vlan 20
  spanning-tree port type edge
  vpc 10
interface port-channel11
  switchport
  switchport mode trunk
  spanning-tree port type network
  vpc peer-link
interface port-channel12
  switchport
  switchport mode trunk
  spanning-tree port type edge trunk
  vpc 12
interface port-channel13
  switchport
  switchport mode trunk
  spanning-tree port type edge trunk
  vpc 13
interface Ethernet1/9
  switchport
  switchport access vlan 10
  channel-group 9 mode active
  no shutdown
interface Ethernet1/10
  switchport
  switchport access vlan 20
  channel-group 10 mode active
  no shutdown
interface Ethernet1/11
  switchport
  switchport mode trunk
  channel-group 11 mode active
  no shutdown
interface Ethernet1/12
  switchport
  switchport mode trunk
  channel-group 12 mode active
  no shutdown
interface Ethernet1/13
  switchport
  switchport mode trunk
  channel-group 13 mode active
  no shutdown

インターフェイス Ethernet 1/9 と Ethernet 1/10 は、それぞれ Vlan 10 と Vlan 20 に属します。インターフェイス Ethernet 1/12 と Ethernet 1/13 は、ファイアウォール クラスタのサブインターフェイスに接続されるため、トランク ポートとして設定します。

d. ロード バランシング用ルータ (africa20):

インターフェイスの設定:

vlan 1,10,20
vlan 10
  name Inside
vlan 20
  name Outside
route-map anyany permit 10
  match ip address any 
interface port-channel9
  bfd interval 100 min_rx 100 multiplier 3
  ip address 10.0.255.1/24
interface Ethernet1/9
  bfd interval 100 min_rx 100 multiplier 3
  ip address 10.1.255.9/24
  no shutdown

interface Ethernet1/10
  bfd interval 100 min_rx 100 multiplier 3
interface Ethernet1/11
  bfd interval 100 min_rx 100 multiplier 3
  ip address 10.12.255.1/24
  no shutdown
interface Ethernet1/12
  channel-group 9 mode active
  no shutdown
interface Ethernet1/13
  channel-group 9 mode active
  no shutdown

インターフェイス Ethernet 1/12 と Ethernet 1/13 を Port-Channel にバンドルし、この Port-Channel を使用してファイアウォールとの BGP ネイバー関係を確立します。

BGP の設定:

router bgp 65111
  address-family ipv4 unicast
    redistribute direct route-map anyany
    redistribute static route-map anyany
    maximum-paths 2
  neighbor 10.0.255.10
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.0.255.11
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.0.255.12
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.0.255.13
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.0.255.14
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.0.255.15
    bfd
    remote-as 65000
    address-family ipv4 unicast
  neighbor 10.1.255.1
    bfd
    remote-as 65011
    address-family ipv4 unicast
  neighbor 10.12.255.2
    bfd
    remote-as 65001
    address-family ipv4 unicast

10.0.255.10-10.0.255.15/255.255.255.0 は、ファイアウォールに設定された Inside プールです。プール内の各 IP アドレスが、ルータ上で BGP ネイバーとして設定されていることに注意してください。SITE 1 の africa20 と SITE 2 の asiana は、Inside プールと BGP ネイバー関係を確立します。一方、Site1 の arsenal と Site2 の bakerstreet は、Outside プールと BGP ネイバー関係を確立します。

この例では、africa20 上で asiana と africa22 も BGP ネイバーとして設定されています。

e. クライアント側およびサーバ側のスイッチ (africa22):

インターフェイスの設定:

interface Ethernet1/9
  bfd interval 100 min_rx 100 multiplier 3
  ip address 10.1.255.1/24
  no shutdown
interface Ethernet1/10
  bfd interval 100 min_rx 100 multiplier 3
  ip address 10.2.255.1/24
  no shutdown
interface Ethernet1/11
  switchport
  switchport mode trunk
  spanning-tree port type edge trunk
  no shutdown
interface Ethernet1/12
  switchport
  switchport mode trunk
  spanning-tree port type edge trunk
  no shutdown

トラフィック ジェネレータに接続するインターフェイス Ethernet1/11 と Ethernet1/12 は、トランク ポートとして設定します。

ルート マップを使用した BGP の設定:

ip prefix-list 201 seq 5 permit 20.201.0.0/16 
ip prefix-list 202 seq 5 permit 20.202.0.0/16 
route-map FROM-Site1 permit 10
  match ip address prefix-list 201 
  set weight 40000
route-map FROM-Site1 permit 100
  match ip address prefix-list 202 
route-map FROM-Site2 permit 10
  match ip address prefix-list 202 
  set weight 40000
route-map FROM-Site2 permit 100
  match ip address prefix-list 201 
route-map anyany permit 10
  match ip address any 
router bgp 65011
  address-family ipv4 unicast
    redistribute direct route-map anyany
    redistribute static route-map anyany
    maximum-paths 2
  neighbor 10.1.255.9
    bfd
    remote-as 65111
    address-family ipv4 unicast
      route-map FROM-Site1 in
  neighbor 10.2.255.9
    bfd
    remote-as 65001
    address-family ipv4 unicast
      route-map FROM-Site2 in

ルート マップでは、20.201.0.0/16 は SITE 1 経由、20.202.0.0/16 は SITE 2 経由を優先するように設定します。同様に、brighton では、10.101.0.0/16 は SITE 1 経由、10.102.0.0/16 は SITE 2 経由を優先するように設定します。

BGP ネイバー関係

ファイアウォールとルータの間で確立する BGP ネイバー関係を下図に示します。たとえば、africa20 の両方のネイバー（etihad と allegiant）がダウンした場合は、asiana を経由してサーバ サブネットへ到達する別のルートが優先されます。

ルータ africa20 とファイアウォール allegiant の間の BGP ネイバー関係を詳しく見てみましょう。

4 台すべてのルータが、ファイアウォール クラスタ上で BGP ネイバーとして設定されています。以下に示すように、FMC で確認できます。

allegiant の CLI にログインして、BGP ネイバーを表示します。以下のスクリーンショットでは、ルータ africa20 (10.0.255.1) が強調表示されています。

次に africa20 の CLI にログインして、その BGP ネイバーを表示します。以下のスクリーンショットでは、ファイアウォール allegiant (10.0.255.11) が強調表示されています。

トラフィック フロー

クラスタを通過するトラフィックは、トラフィック ジェネレータ ツール Cyberflood で生成します。ファイアウォール ユニットの 1 台である etihad を通過するフローを以下に示します。

生成されたトラフィックは、クライアント側の africa22 に流入します。ルータ africa22 は、BGP で学習したルートに基づき、トラフィックを africa20 にルーティングします。続いて、BGP ルートに基づくロード バランシングにより、トラフィックが etihad に送られます。トラフィックはファイアウォールで検査された後、arsenal にルーティングされます。ルータ arsenal はトラフィックを brighton にルーティングし、そこからサーバ側の Cyberflood に戻ります。

耐障害性テスト

ここからは、個別インターフェイス モードのクラスタがさまざまな障害シナリオにどのように対応するかを確認し、クラスタのステートフルな冗長性を検証します。

注: これらのテスト シナリオは、ファイアウォール上の CLI コマンドを使用して実行しましたが、ほとんどの出力はクラスタのヘルス モニタリング ダッシュボードでもグラフィカルに確認できます。クラスタのヘルス モニタリング ダッシュボードの動画は、こちらをご覧ください - クラスタ ヘルス モニタ

クラスタで実施した耐障害性テストは次のとおりです。

• ファイアウォール ノードの障害
• 機能が低下したノードの管理
• サイトの障害

ファイアウォール ノードの障害

このテストでは、まず「cluster disable」コマンドでノードを無効にする、正常な手順による離脱を実行します。次に、ファイアウォールのデータ インターフェイスに障害を発生させ、予期しない障害によるノードの停止を再現します。

a. 正常な手順によるノードの離脱

SITE 1 のファイアウォール ユニット allegiant で「cluster disable」コマンドを実行し、ノードを停止します。手順は次のとおりです。

1. いずれかのユニットで「show cluster info」コマンドを実行し、クラスタの健全性を確認します。以下は、etihad でコマンドを実行した結果です。

出力から、etihad がコントロールノードで、残りのユニットがデータノードであることがわかります。また、クラスタのインターフェイス モードとして「Individual」が表示されています。

2. トラフィック ジェネレータ Cyberflood で、クラスタを通過するトラフィック フローを開始します。

Cyberflood の以下のスクリーンショットでは、すべての接続が確立されていることがわかります。

以下は、「cluster exec show conn」コマンドを実行した CLI 出力です。fp4245-2、すなわち allegiant で確立された、宛先ポート 10565 および 1885 の強調表示された接続に注目してください。

📘

注

割り当てられたフラグは、特定のフローに対するノードの接続ロールを表します。以下の表を参照してください。

接続のロール	フラグ
接続オーナー	UIO
ディレクタ	Y
バックアップオーナー	Y（ディレクタがバックアップオーナーを兼ねる場合） y（ディレクタがバックアップオーナーではない場合）
フォワーダ	z

上記で強調表示されたフローには「UIO」フラグが付いています。これは、ファイアウォール fp4245-2、すなわち allegiant がその接続の接続オーナーであることを示します。

3. allegiant で「cluster disable」コマンドを実行します。「show cluster info」コマンドの出力で、このユニットのクラスタリングが無効になったことを確認します。

次にコントロールノード etihad で「show cluster info」コマンドを実行すると、fp4245-2 (allegiant) がクラスタから削除されたことを確認できます。

4. 「cluster exec show conn」コマンドを実行すると、allegiant で確立されていた接続が、他のユニットにシームレスに移行したことがわかります。手順 2 で確認した宛先ポート 10565 および 1885 の接続を見て検証します。

上記のスクリーンショットでは、接続が fp4245-1 (etihad) に移行したことがわかります。
この時点で、Cyberflood に接続エラーは表示されていません。

5. allegiant で「cluster enable」コマンドを実行し、クラスタを再び有効にします。クラスタの状態を確認すると、ノードが DATA_NODE_APP_SYNC 状態になっていることがわかります。

同期が完了すると、DATA_NODE 状態に移行します。

Cyberflood でも、ファイアウォールがクラスタに再参加した際に、接続が切断されていないことを確認できます。

これで、最初のテストである、正常な手順によるノードの離脱の確認は完了です。

b. 予期しない障害によるノードの停止

2 番目のノード障害テストでは、EEM スクリプトを使用して、SITE 1 のファイアウォール ノード allegiant のデータ インターフェイスと CCL インターフェイスをすべてダウンさせます。EEM スクリプトを確認しましょう。

「echo allegiant-down」スクリプトは allegiant のすべてのデータ インターフェイスと CCL インターフェイスをダウンさせ、「echo alligiant-up」スクリプトはそれらのインターフェイスを復旧します。
手順は次のとおりです。

1. 「show cluster info」コマンドで、4 ノードすべてがクラスタ内で稼働していることを確認します。
2. Cyberflood からクラスタを通過するトラフィックを生成します。

強調表示された、宛先ポート 58898 および 11323 の接続に注目してください。

3. airlines37、sudan、および angola で「echo allegiant-down」スクリプトを実行します。「show cluster info」コマンドで、allegiant (fp-4245-2) がクラスタのメンバーではなくなったことを確認できます。

強調表示された宛先ポート 58898 および 11323 の接続は、allegiant から etihad に移行しています。

Cyberflood でも接続の状態を確認し、すべて稼働していることがわかります。

4. airlines37、sudan、および angola で「echo allegiant-up」スクリプトを実行し、allegiant のデータ インターフェイスと CCL インターフェイスをすべて復旧します。「show cluster info」コマンドで、allegiant (fp-4245-2) がクラスタに再参加したことを確認できます。

Cyberflood で確認できる接続も、引き続き安定しています。

機能が低下したノード

ノードの 1 台（ここでも allegiant）で、ディスクに大容量のファイルを作成してディスク容量が枯渇した状況をシミュレーションし、ノードを停止させます。

手順は次のとおりです。

1. 「show cluster info」コマンドを実行して、クラスタの状態を確認します。
2. Cyberflood からクラスタへのトラフィックを開始します。allegiant 上の、宛先ポート 35727 および 42045 の接続に注目してください。

3. allegiant でディスク容量のシミュレーション コマンドを実行します。

以下に示すように、ノードがクラスタから除外されます。

ポート 35727 および 42045 の接続は etihad に移行します。

4. ファイルを削除すると allegiant のディスク領域が解放され、正常な状態に戻り、クラスタに再参加できるようになります。

サイトの障害

このテストでは、いずれかのサイト（この例では SITE 2）で EEM スクリプトを実行し、そのサイト内のファイアウォール、スイッチ、およびルータのすべてのインターフェイスに障害を発生させて、サイトを停止します。

EEM スクリプトは次のとおりです。

サイトを停止するスクリプト:

前述のすべてのデバイスで「echo shut」スクリプトを実行すると、SITE 2 のすべてのインターフェイスがダウンします。
サイトを復旧するスクリプト:

同じデバイス群で「echo noshut」スクリプトを実行すると、SITE 2 のすべてのインターフェイスが復旧します。
手順は次のとおりです。

1. ファイアウォール クラスタの状態を確認します。
2. Cyberflood からトラフィックを生成します。
3. frontier (f4245-3) と spirit (f4245-4) で確立された接続が強調表示されています。frontier の接続の宛先ポートは 21744、spirit の接続の宛先ポートは 56176 です。

4. bakersteet、qatar、asiana、vistara、および airlines37 で「echo shut」スクリプトを実行し、SITE 2 への接続を持つインターフェイスをシャットダウンします。その結果、ファイアウォール frontier と spirit がクラスタから削除されます。

これらのファイアウォールの接続は、SITE 1 の etihad と allegiant にシームレスに移行します。ポート 21744 および 56176 の接続は allegiant に移行します。

Cyberflood では、接続が引き続き稼働しています。

5. noshut スクリプトを実行し、それまでシャットダウンしていた SITE 2 のすべてのインターフェイスを復旧します。ノード frontier と spirit が順番にクラスタに再参加します。

📘

注

今後のリリースでは、複数のノードが同時にクラスタに参加できる並列参加機能が、ASA クラスタに追加される予定です。

最初にノード spirit (f4245-4) がクラスタに参加しました。

ノード frontier (f4245-3) は、DATA_NODE_APP_SYNC への移行中です。

ノード frontier (f4245-3) が DATA_NODE 状態に移行し、クラスタ内のすべてのノードが稼働状態になりました。

Cyberflood の状態から、切断エラーがなく、すべての接続が稼働していることがわかります。

まとめ

本書では、個別インターフェイス モードで導入する Cisco Secure Firewall クラスタリングのリファレンス アーキテクチャについて、設計原則、具体的な設定、および運用面を包括的に説明しました。

正常な手順による個別ノードの離脱、予期しない個別ノードの障害、ノードの機能低下、およびサイト全体の停止といった耐障害性テストにより、Cisco Secure Firewall クラスタリング ソリューションの強力な高可用性とディザスタ リカバリの機能を実証しました。シミュレーションしたすべての障害シナリオで、クラスタはステートフルな接続を維持し、トラフィック フローを継続できました。これにより、地理的に離れた拠点間でも、セキュリティの適用とネットワーク サービスを中断せずに提供できることを確認しました。このアーキテクチャは、重要なネットワーク インフラストラクチャに適した、高い耐障害性と拡張性を備えたソリューションです。

言語: English | 日本語