ファイアウォール Hillstone StoneOS デバッグ トラブルシューティング ガイド
1.デバッグパケットキャプチャ命令
⇒ デバッグおよびパケットキャプチャを行う前に必ずデバイスの CPU を確認してください。現在の CPU が高すぎる場合 (参考値: ≥50%)、パケット キャプチャは慎重に続行してください。デバッグは低ピーク時間帯に実行することをお勧めします。現在のデバイスの CPU 値が低く、ビジネスが低い場合は、デバイスの CPU 固有のコマンド SG-6000# show cpudetail (履歴 CPU を含む) を確認してください。
⇒ デバッグ パケット キャプチャ後、デバイスの CPU やその他の動作条件への影響を防ぐために、デバイス上で有効になっているすべてのデバッグを必ず閉じてください。
① コマンドラインから：SG-6000# undebug all。
② コマンドラインから: 長押しまたは「Esc」キーを 2 回押す 「すべてのモジュールのデバッグ機能が無効になっています」というプロンプトは、有効になっているすべてのデバッグが閉じられたことを意味します。
StoneOS データ パケット (DP) デバッグ >
IP sec デバッグ >
その他の種類のデバッグ >
システム デバッグ機能は、ユーザーがエラーを診断して特定するのに役立ちます。セキュリティ ゲートウェイのさまざまなプロトコルと機能には、基本的に対応するデバッグ機能があります。デフォルトでは、すべてのプロトコルと機能のシステム デバッグはオフになっています。ユーザーは、デバイスのコマンド ラインを介してのみシステム デバッグ機能を構成できます。
デバッグ操作には一定のリスクがあり、特にデバイスのトラフィックが多い場合にデバッグをオンにすると CPU の負荷が高くなるため、注意して操作してください。Shanshi エンジニアの指導の下で操作してください。ユーザーが直接デバッグを使用することはお勧めできません。
この記事では、StoneOS はデフォルトでファイアウォールを指します。
2. 共通のデバッグ パケット キャプチャ プロセス
(1) データ パケット (DP) デバッグ パケット キャプチャ プロセス
a. デバッグ パケット キャプチャの前に、まず StoneOS データ パケット (非レイヤー 2) の基本的な転送プロセスを理解することをお勧めします。
図注 1: StoneOS データ パケットの基本的な転送フローチャート (非レイヤー 2)
b. StoneOS データ パケット (非レイヤー 2) の基本的な転送プロセスは次のとおりです:
データ パケットの論理受信インターフェイス (一般的なタグなしインターフェイスまたはサブインターフェイスである可能性があります) を識別します。これにより、データ パケットの送信元セキュリティ ドメインが決まります。
StoneOS はデータ パケットの合法性チェックを実行します。ソースセキュリティドメインに攻撃防御機能が設定されている場合、システムはこのステップで攻撃防御機能もチェックします。
セッションクエリ。パケットが確立されたセッションに属している場合は、ステップ 4 ～ 10 をスキップして、ステップ 11 に直接進みます。
宛先 NAT (DNAT) 操作。一致する DNAT ルールが見つかった場合、パケットには DNAT マークが付けられます。ルート クエリには DNAT によって変換された IP アドレスが必要なため、DNAT 操作が最初に実行されます。
*システムが静的な 1 対 1 BNAT ルールで構成されている場合は、一致する BNAT ルールが最初に検索されます。データ パケットが BNAT ルールに一致すると、BNAT 設定に従って処理され、通常の DNAT ルールは検索されなくなります。
ルーティングクエリ。StoneOS のルーティング クエリ シーケンスは、前から後ろに、ポリシー ルーティング (PBR) > 送信元インターフェイス ルーティング (SIBR) > 送信元ルーティング (SBR) > 宛先ルーティング (DBR) > ISP ルーティングです。
この時点で、システムはデータ パケットの論理送信インターフェイスと宛先セキュリティ ドメインを取得します。
ソース NAT (SNAT) 操作。一致する SNAT ルールが見つかった場合、パケットには SNAT マークが付けられます。*システムが静的な 1 対 1 BNAT ルールで構成されている場合は、一致する BNAT ルールが最初に検索されます。データ パケットが BNAT ルールに一致すると、BNAT 設定に従って処理され、通常の DNAT ルールは検索されなくなります。
ネクストホップ VR クエリ。ネクスト ホップが VR の場合は、指定されたネクスト ホップ VR が VR の最大数を超えているかどうかを引き続き確認します (システムの現在のバージョンでは、データ パケットが最大 3 つの VR しか通過できません)。超えない場合は 4 を返し、次のホップが VR でない場合は、ポリシー クエリの次のステップに進みます。
セキュリティポリシーのクエリ。システムは、送信元セキュリティ ドメイン、宛先セキュリティ ドメイン、送信元 IP アドレスとポート番号、宛先 IP アドレスとポート番号、およびデータ パケットのプロトコルに基づいてポリシー ルールを検索します。一致するポリシー ルールが見つからない場合、パケットは破棄されます。一致するポリシー ルールが見つかった場合、パケットはルールで指定された動作に従って処理されます。 · 許可: データ パケットの通過を許可します
。
· 拒否: 通過するデータ パケットを拒否します。
· トンネル: データ パケットを指定されたトンネルに転送します。
・トンネルから来たかどうか（Fromtunnel）：指定したトンネルからデータパケットが来たかどうかを確認し、トンネルから来た場合は通過を許可し、そうでない場合は破棄します。
· Web 認証 (WebAuth): 適格なトラフィックに対して Web 認証を実行します。
型認識が初めて適用されます。システムは、ポリシー ルールで構成されたポート番号とサービスに基づいてアプリケーション タイプを識別しようとします。
セッションが確立されました。
必要に応じて、2 番目のアプリケーション タイプの識別を実行します。アプリケーションの種類も、パケットの内容とトラフィックの動作に基づいて正確に識別されます。
アプリケーション層の動作制御。決定されたアプリケーション タイプに応じて、システムはここで設定されたプロファイルおよび ALG 機能を実行します。
NAT タグなど、セッションに記録された情報に基づいて、対応する処理操作を実行します。
パケットを出力インターフェイスに転送します。
c. 例を挙げます。
図 2: StoneOS の実際のデバッグ パケット転送プロセス (1)
図 3: StoneOS の実際のデバッグ パケット転送プロセス (2)
トップ⇑
d. デバッグ操作手順
[以下の赤太字部分は一般的なデバッグ操作手順(必須)]
SG-6000# show cpudetail //デバイスの現在のCPUステータスを確認します（高すぎる場合、デバッグは推奨されません）
SG-6000(config)#logging debug on //打开デバッグログ
SG-6000(config)# ロギングデバッグをバッファに記録 // ログをバッファに記録
SG-6000(config)# nologging debug to console //ログをコンソールに記録しません
SG-6000# debug dp filter src-ip xxxx src-port xx dst-ip xxxx dst-port xx proto xxx //デバッグ フィルタ条件を設定します source IP 送信元ポート 宛先 IP 宛先ポート プロトコル (1 つ以上を選択できます)デバッグフィルターとして)
注: デバッグ フィルタ条件の説明に関して、デバッグ中に双方向データ パケットを表示する必要がある場合、つまり前後のデータ パケットの転送を行う場合は、2 つのデバッグ フィルタ条件を設定する必要があります。たとえば、一般的な状況では、最初の送信元と宛先のアドレスとポートは、データ パケットの送信方向です。2 番目の送信元と宛先のアドレスとポートは、逆に書かれてリバース パケット (リターン パケット) を形成します。もちろん、特殊な状況では、実際のパケットを参照してください。環境。
例 1: ICMP プロトコル ping パケットのキャプチャ SG-6000# debug dp filter src-ip 192.168.1.1 dst-ip 192.168.100.233 proto icmp //コンテンツの制限を送信元および宛先アドレス、プロトコルでキャプチャ 例 2: IP アドレス メッセージのみをキャプチャ SG
- 6000# デバッグ dp フィルター dst-ip 192.168.100.233 )
SG-6000# show dp filter または show dp-filter // 設定されているデバッグ フィルタ条件を表示します（デバッグ フィルタ条件の設定ミスによるパケット キャプチャ エラーを防ぐため、フィルタ条件を設定した後、設定されているフィルタ条件を確認することをお勧めします）
SG-6000# undebug dp filter id xx //設定されたデバッグフィルター条件をクリア
SG-6000# debug dp Basic //データ パケットの基本的な処理フローを表示するデバッグ スイッチ (必ず最初のフィルタリング コマンドを最初に実行してください。そうしないと、すべてのデータ パケットをデバッグすると CPU がハイになるかスタックする可能性があります)
SG-6000# debug dp snoop //StoneOS データ層転送の基本情報を表示します (この機能は、TCP ヘッダーの SYN/ACK/FIN/RST やその他のフラグ、シリアル番号、層などのデータ パケット ヘッダー内の情報を確認できます) 2 MACアドレス等はお待ちください。）
SG-6000# debug dp drop //StoneOS データ レイヤー ドロップに関する基本情報を表示します
SG-6000# debug dp error //StoneOS エラー パケットを表示
SG-6000# debug self //StoneOS 自身のデータ パケット転送ステータスを表示します
SG-6000# show debug //有効なデバッグ機能を表示します（デバッグ機能の設定ミスによるパケットキャプチャエラーを防ぐため、デバッグ機能を設定した後に有効なデバッグ機能を表示することをお勧めします）
SG-6000# clearloggingdebug //デバッグキャッシュをクリアします
デバッグ キャッシュをクリアした後、障害のあるノードにすぐにアクセスします。これによりデータ フローがトリガーされ、ファイアウォールが対応するデータ パケット転送情報をキャプチャできるようになります (ファイアウォールが対応するデータ パケットをキャプチャできない場合、たとえば「情報: パケットが存在しません」というプロンプトが表示される場合)ログメッセージ」というメッセージは、該当するトラフィックがファイアウォールに到達していないか、デバッグフィルターの条件や機能スイッチが間違っている可能性があります。実際の状況を参照して確認してください)
SG-6000# showloggingdebug //デバッグ出力情報、つまり StoneOS パケット転送ステータスを表示します。
SG-6000# showloggingdebug | {include|begin|begin2|exclude|redirect} Packet/Drop/RST/err など //ターゲット情報はパイプ文字「|」でフィルタリングできます（「SG-」など）。 6000#showloggingdebug | includePacket」を使用すると、データパケットの転送ステータスを直接表示できます。
注: 対応するデバッグ出力情報を記録する必要がある場合は、「ロギング」機能を持つコマンド ソフトウェアを使用してください (詳細については、ソフトウェアの説明書を参照してください)。
SG-6000# undebug all //パケットキャプチャが完了したら、デバッグ機能をオフにします（長押しまたは「Esc」キーを2回押します）
注: デバッグを使用する場合は、デバイスの CPU 使用率とキャプチャされたパケットのデータ量に注意してください。フィルタリング条件がないとデバッグは実行できません。
e. 一般的なデバッグ障害デバッグ情報の例 (StoneOS データ パケット)
① 「一致するポリシーはありません、デフォルト =拒否="
一致するポリシーはありません。ポリシーの設定が正常かどうかを確認する必要があります。
" ポリシー ID xx が一致します: =拒否＝
拒否ポリシーに一致した場合は、ポリシーの設定が正常か確認する必要があります。
②「ポリシーxxは一致します、 =アウトトンネル=
ドロップされました: ポリシー/ポリシーが拒否されましたが見つかりません。中止!!" は
ポリシーと一致しますが、間違ったトンネルを使用します。check-id が有効になっているかどうかを確認する必要があります。
③「flow0 のトンネル ID (0) が無効です。
ドロップされました: セッションの作成に失敗しました」は、
IP sec 設定を確認する必要があります。一般的な理由は、トンネル インターフェイスが IP sec インスタンスにバインドされているときに設定されたゲートウェイが、設定されたゲートウェイと矛盾していることです。ルーティング構成内 (または、一方が構成され、もう一方が未構成)。
④「toselfサービスが登録されていません」
ファイアウォール自体に送信すべきでないパケットがドロップされるため、設定が正常か（DNATがうまく一致していないなど）確認が必要です。
⑤ 「キャッシュの挿入に失敗し
ました 次のセッションのインストールに失敗しました」
セッションの競合により、セッションの作成が失敗します。競合があるかどうかを確認するには、既存のセッション フローをクエリすることをお勧めします。一般的な理由には、作成されるセッションの flow0 とセッションの flow1 が含まれます。既存のセッションとゾーンも同じですが、同時に競合が発生します。
⑥「Dropped: Arp get failed」
ARP 情報の取得に失敗しました。ミラーリングパケットキャプチャなどを組み合わせて、ARP パケットの送受信をさらに確認する必要があります。Arp の取得が失敗した場合、ip:0.0.0.0 が表示されます。同じアプリケーションの異なるポート上のデバイスで受信されたパケットの送信元 MAC が異なることが原因である可能性があります。再度 ARP を要求する必要があり、リバース ルーティングがオフになっています。 [リバース ルーティング テストを有効にする] を試してください。
⑦ 「Dropped: Dst mac is not interface's mac,drop packet」
宛先 MAC はインターフェイスの MAC ではないためドロップされますが、該当するパケットかどうかを確認する必要があります。その場合は、アップリンク デバイスの ARP 学習状況を確認し、必要に応じてローカル側で無料 ARP を有効にして、再度テストする必要があります。
⑧ 「Dropped: Address spoof detected!!
Dropped: No reverse Route, drop the packet」は
文字通り、アドレススプーフィングのドロップパケットが検出されたことを意味し、逆方向経路を問い合わせた際に見つかった戻りパケットの送信インタフェースと順パケットの受信インタフェースで共通です。同じセキュリティ ドメインにない場合は、デバッグ時にそのような情報が表示されます。ルーティング設定が正常かどうかは設定ファイルを確認する必要があります。通常、リバースルーティングをオフにすることは回避できますが、リバースルーティングをオフにすると別の問題が発生する可能性があるため、ユーザーの実際のニーズに応じて最適な提案を行う必要があります。
「リバース ルートを取得します。アウト インターフェイスのゾーンはパケットの i_if のゾーンではありません。パケットをドロップします。ドロップしました。リバース ルートがありません。
パケットをドロップします。」
このデバッグ メッセージは上記と似ています。一般的な理由はほぼ同じであり、次のことが必要です。設定ファイルを確認します。
⑨ 「無効なセッションをヒットし、パケットをドロップします」という
5 つのメッセージが破棄されたセッションにヒットし、破棄されます。これは通常、前のセッションが破棄されてから 3 秒のエージング タイムが経過していないためです。
⑩ 「ドロップ: TCP 1 番目のパケットは RST または FIN であってはなりません」
最初の TCP パケットは RST または FIN パケットであってはなりません。これは、関連するチェックをオフにすることで回避できます。
⑪ 「リソースが不足しています
Dropped: SNAT エラー、ドロップしました」
SNAT リソースが不足しています。SNAT リソースの状態を確認する必要があります。ポート拡張が有効な場合は、プールのリソースが使用されていないか確認する必要があります。 。
⑫ 「ドロップ: dst mac のインターフェイスは src if と同じです。」
宛先 MAC に対応するアウトバウンド インターフェイスがインバウンド インターフェイスと同じです。これは通常、トランスペアレント モード環境で発生します。デバイスは、パケットが送信されるべきではないと考えています。これには、お客様のトポロジに基づいて正常かどうかを確認する必要があります。
⑬「到達不能な埋め込み icmp を受信しました。セッションを無効にします」
デバイスが ICMP 到達不能メッセージを受信し、セッションを切断すると、後続のサービス メッセージがドロップされる可能性がありますが、icmpunreachable-session-keep を設定することで回避できます。
⑭「Dropped: TTL is too small」
TTL が低すぎます。デバイスが受信したパケットの TTL がすでに 1 であるか、ループが発生している可能性があります。トポロジーと完全なデバッグ分析が必要です。
⑮ 「iQoS プロセス: QoS エンジンの最初のパイプ xxx (パイプ名) のエンキュー パックが失敗しました。削除します。」
メッセージは iQoS によってブロックされます。
⑯「block pak for session xxxx (セッション ID) new app-id xxx (アプリケーション名)」
アプリケーション識別機能によりトラフィックの実際のアプリケーションが識別されるため、アプリケーションが変更され、セッション中に拒否ポリシー/デフォルトの拒否アクションが照合されます。再戦すると、パケットがドロップされます。
写真の共有
