TCP接続障害を引き起こすFTDクラスタの非対称のトラブルシューティング
お問い合わせ内容
次の1つ以上の症状が現れる可能性があります。
FTDクラスタを通過するアプリケーションの断続的な接続障害。
接続試行中にTCP 3ウェイハンドシェイクが失敗する。
クライアントはSYNパケットを送信しますが、予期されるSYN-ACK応答を受信しません。
クライアントは最初のSYNの後にRSTパケットを送信します。
環境
- 最初にSecure Firewall Threat Defense(SFTD)7.4で確認されました。他のバージョンも該当する可能性があります
- クラスタの設定
- ネットワークパス内のロードバランサ
トポロジ
解決策
問題の根本原因を特定するには、次の時点で同時キャプチャを実行する必要があります。
FW1内部インターフェイス（reinject-hideあり）
FW1外部インターフェイス（reinject-hideあり）
FW1クラスタインターフェイス(CCL)
FW2内部インターフェイス（reinject-hideあり）
FW2外部インターフェイス（reinject-hideあり）
FW2クラスタインターフェイス(CCL)
クライアント（または可能な限りクライアントの近く）
サーバ（または可能な限りサーバの近く）
キャプチャの設定方法の詳細については、次の項目を確認してください。
クライアントおよびサーバとともに両方のファイアウォールで取得されたキャプチャから、次のトポロジが明らかになります。
1. クライアントがTCP SYNを送信します。 パケットはロードバランサ(LB)に到着し、FW1に送信されます。
2. FW1はTCP SYNパケットを受信し、フローオーナーになります。
3. FW1は、特別な(clu add)クラスタメッセージを送信して、フロー所有者についてディレクタ(FW2)に通知します。
4. FW1は宛先サーバにTCP SYNを転送します。
注：手順3と4は特定の順序で行われません。
5. サーバはSYN/ACKで応答します。 この場合、ポートチャネルのロードバランシングアルゴリズムにより、SYN/ACKがFW2に向けて送信されるため、非対称フローが存在します。
6. clu addメッセージの前に、FW2にSYN/ACKが到着します。 これは競合状態であり、純粋に環境です（CCLでの遅延など）。 FW2はフローの所有者が誰かを知らないため、SYN/ACKはドロップされます。
7. TCP RSTがサーバに送信されます。
8. clu addメッセージがFW2に到着します。
9. クライアントはTCP SYNパケットを再送信します。 TCP SYNパケットが宛先サーバに転送されます。
10. LBで、特定のフローのTCP接続がタイムアウトします。
11. サーバはSYN/ACK（TCP再送信）で応答します。 SYN/ACKパケットがFW2に到着します。 今回は、FW2はclu addメッセージを受け取ってCCL経由でSYN/ACKがフロー所有者に転送されるため、フロー所有者を認識しています。 SYN/ACKがクライアントに送信されます。
12. LBはこのフローを認識せず、SYN/ACKをドロップします。 そのため、SYN/ACKがクライアントに到達することはありません。
13. LB 1つ以上のTCP RSTパケット。
パケットキャプチャ分析
トレース分析によるファイアウォールキャプチャ
これらの出力では、キャプチャはCCLおよびサーバ側インターフェイスのファイアウォールから収集されています。
・ CCLでは、キャプチャはUDP 4193ポートで行われます。
・ データインターフェイスで、reinject-hideオプションを使用して、キャプチャがエンドポイント間のTCPトラフィックを照合します。 これは、パケットが実際に到着した場所を確認するためです。
・ IPアドレス192.0.2.65 =クライアント
・ IPアドレス192.0.2.6 =サーバ
ステップ1:SYN/ACKを取得するファイアウォールデバイスでこのコマンドを使用して、clu addメッセージがいつ着信したかを確認します。 CLI出力では、メッセージは「Add flow」と表示されます。
firepower# show capture CCL decode
3 packets captured
1: 08:14:20.630521 127.2.1.1.51475 > 127.2.2.1.4193: udp 820
クラスタASPメッセージ：送信者： 1、受信者： 0
フローの追加：オーナー1、ダイレクタ0、バックアップ0、
ifc_in INSIDE(7020a7)、ifc_out INSIDE(7020a7)
TCP送信元192.0.2.65/37468, dest 192.0.2.6/80
ステップ2:SYN/ACKパケットをトレースし、タイムスタンプとトレース結果に注目します。
firepower# show capture CAPI packet-number 1 trace
13 packets captured
1: 08:14:20.628690 802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2524735158:2524735158(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611712900 970937593,nop,wscale 7>
フェーズ： 1
タイプ：CAPTURE
Subtype:
結果： ALLOW
経過時間：1708 ns
Config:
関連情報
MAC Access list
フェーズ： 2
タイプ：ACCESS-LIST
Subtype:
結果： ALLOW
経過時間：1708 ns
Config:
Implicit Rule
関連情報
MAC Access list
フェーズ： 3
タイプ：INPUT-ROUTE-LOOKUP
サブタイプ：出力インターフェイスの解決
結果： ALLOW
経過時間：13664 ns
Config:
関連情報
出力ifc INSIDE(vrfid:0)を使用してネクストホップ192.168.200.140が見つかりました
フェーズ： 4
タイプ：CLUSTER-EVENT
Subtype:
結果： ALLOW
経過時間：16104 ns
Config:
関連情報
入力インターフェイス： 'INSIDE'
フローの種類：フローなし
私(0)はオーナーになろうとしています
フェーズ： 5
タイプ： OBJECT_GROUP_SEARCH
Subtype:
結果： ALLOW
経過時間：19520 ns
Config:
関連情報
Source object-group match count（ソースオブジェクトグループ一致数）:0
送信元NSG一致数：0
宛先NSG一致数：0
テーブル参照カウントの分類： 1
参照カウントの合計： 1
重複するキーペアの数： 0
テーブル一致数の分類： 4
フェーズ：6
タイプ：ACCESS-LIST
Subtype:
結果： ALLOW
経過時間：366 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268436480
access-list CSM_FW_ACL_ remark rule-id 268436480: ACCESS POLICY: msafeiro_empty – デフォルト
access-list CSM_FW_ACL_ remark rule-id 268436480:L4 RULE：デフォルトアクションルール
関連情報
このパケットはSnortに送信され、判定に達すると追加の処理が行われます
フェーズ：7
タイプ： CONN-SETTINGS
Subtype:
結果： ALLOW
経過時間：366 ns
Config:
クラスマップTCP
match access-list tcp（アクセスリストtcpに一致）
policy-map global_policy
クラスTCP
set connection conn-max 0 embryonic-conn-max 0 random-sequence-number disable syn-cookie-mss 1380」を発行します。
service-policy global_policy global
関連情報
フェーズ：8
タイプ：NAT
サブタイプ：セッションごと
結果： ALLOW
経過時間：366 ns
Config:
関連情報
フェーズ： 9
タイプ：IP-OPTIONS
Subtype:
結果： ALLOW
経過時間：366 ns
Config:
関連情報
結果：
入力インターフェイス：INSIDE(vrfid:0)
入力ステータス：アップ
input-line-status:up（入力回線ステータス：アップ）
出力インターフェイス：INSIDE(vrfid:0)
output-status：アップ
output-line-status：アップ
アクション：ドロップ
所要時間：54168 ns
ドロップ理由：(tcp-not-syn)最初のTCPパケットがSYNでない、ドロップ場所：frame snp_sp:7459 flow (NA)/NA
キー ポイント
・ Add flowメッセージは08:14:20.630521に到達しましたが、SYN/ACKは約2ミリ秒早い08:14:20.628690でした。 これがレースコンディションです。
・ SYN/ACKパケットがファイアウォールによって「tcp-not-syn」ASP理由でドロップされます。 フェーズ4では、ファイアウォールが既知のフロー所有者の存在を特定しようとしたが、見つからなかったことに注目してください。 それでフローのオーナーになろうとした。
次の出力は、ファイアウォールがフローを認識している場合のSYN/ACKのトレースを示しています。
firepower# show capture CAPI packet-number 3 trace
13 packets captured
3: 08:14:21.629560 802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2540375172:2540375172(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611713901 970938595,nop,wscale 7>
フェーズ： 1
タイプ：CAPTURE
Subtype:
結果： ALLOW
経過時間：1708 ns
Config:
関連情報
MAC Access list
フェーズ： 2
タイプ：ACCESS-LIST
Subtype:
結果： ALLOW
経過時間：1708 ns
Config:
Implicit Rule
関連情報
MAC Access list
フェーズ： 3
タイプ：CLUSTER-EVENT
Subtype:
結果： ALLOW
経過時間：3416 ns
Config:
関連情報
入力インターフェイス： 'INSIDE'
フロータイプ：STUB
I (0)にはフローがあり、有効な所有者(1)があります。
フェーズ： 4
タイプ：CAPTURE
Subtype:
結果： ALLOW
経過時間：7808 ns
Config:
関連情報
MAC Access list
結果：
入力インターフェイス：INSIDE(vrfid:0)
入力ステータス：アップ
input-line-status:up（入力回線ステータス：アップ）
アクション：許可
所要時間：14640 ns
1 packet shown
firepower#
重要な点はフェーズ3にあります。 ファイアウォールは、クラスタユニット1がフロー所有者であることを認識します。 show cluster infoコマンドを使用して、ユニット0とユニット1のデバイスを確認できます。
Q.断続的なTCP接続の問題が発生するのはなぜですか。
A.これは競合状態であるため、ランダムに発生します。 状況に応じて競合状態を視覚化できます。
Q.この競合状態を回避するために可能なソリューションは何ですか。
A.
解決策1:TCP SYN Cookieメカニズムを利用するために、TCPシーケンス番号のランダム化を有効にします。 この場合、通信は次のように構成されます。
解決策2:ネットワーク内の非対称を排除する。 まず、非対称性の理由を特定する必要があります。 これには、特に、ポートチャネルのロードバランシングアルゴリズムの調整、ポートチャネルケーブルの別の順序での再配線が必要になる場合があります。
原因
根本原因は、FTDクラスタ導入内のクラスタの非対称が原因で発生する競合状態です。 サーバからのSYN-ACKパケットは、最初のSYNパケットを処理したノードとは異なるFTDクラスタノードで処理されているため、適切なTCPセッションの確立ができません。
関連コンテンツ
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
09-Apr-2026
|
初版 |
フィードバック