ASA の packet-tracer は狭い問いに答えます。このパケットがこの tuple でここに入るとき、許可されるのか、どこへ行くのか。遠端が何かを受け取るかどうかは答えません。よくある誤りは、トンネル内を流れるアプリケーションを試したいのに、外側の IKE tuple を与えてしまうことです。まず tuple を直し、フェーズを読み、次にシミュレータが見えないすべてについて実際の証拠を集めます。

以下の手順は、ACL、NAT ルール、tunnel-group のコンテキストが手元にあることを前提とします。それらがなければ、出力は確認できないポリシーを述べているだけです。

ステップ 1: 内側のフローを平易な言葉で書く

何かを入力する前にアプリケーションを記述します。内側のホストが遠隔ゲートウェイの向こうのサーバーへ SSH を開く場合、それは特定の送信元ポートを持つ 一つの内側 TCP フローです。ACL と VPN フィルターが評価するのはそのフローであり、入力すべきなのもそのフローです。

それを一文として書き、次にフィールドごとに翻訳します:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

ステップ 2: イングレスと方向を選ぶ

イングレスはパケットが到着するインターフェースであり、出ていくインターフェースではありません。接続を開始する LAN ホストなら inside インターフェースです。同じセッションの戻りパケットなら outside インターフェースであり、tuple は反転します。宛先を送信元として入力するのは、説得力はあるが無関係な ALLOW を得る二番目に多い方法です。

ポートにも方向があります。開始された要求ではサービスポートが宛先フィールドに入り、クライアントの一時ポートが送信元フィールドに入ります。TCP 宛先 500 のモデルは 500 で待ち受ける TCP アプリケーションを表し、コマンドにその数字が現れるからといって IKE のテストにはなりません。

ステップ 3: フェーズを順番に読む

出力の各フェーズは所有者を持つ判断です。ルート検索、ACL、NAT、そして VPN またはトンネルの選択です。出力された順に読み、設計と食い違う最初のフェーズで止まります。

NAT は人を戸惑わせます。変換後の送信元が、トンネル用のトラフィックを選ぶ crypto ACL の外に出ると、フローは許可されても決してカプセル化されません。トレースは変換後のアドレスを表示するので、元のアドレスではなくトンネルの対象トラフィックと比較します。

ステップ 4: どのバイパスを選んだか確認する

detailed 形式はチェックを飛ばすオプションを受け付け、Cisco は ACL、VPN フィルター、uRPF、IPsec スプーフのチェックを対象とする bypass-checks オプションを文書化しています。それらを飛ばして得た ALLOW は、ルートと NAT が機能するという意味であり、ポリシーが実際のパケットを許可するという意味ではありません。結果の隣にオプションを記録します。

ポリシーの答えが必要なら、バイパスなしで実行します。ルーティングの問いを切り分けるなら、バイパスありで実行し、結果をルーティングの答えとしてラベル付けします。

ステップ 5: 実際のやり取りでギャップを埋める

シミュレートされた許可は ASA で止まります。遠隔ゲートウェイが復号したか、サーバーが接続を受け入れたか、応答が戻ったかは別々の観察です。エンドポイントのカウンターを使うか、承認された経路での限定的なキャプチャ。

一部の trace と replay のオプションはパケットを送信したり状態を保持したりします。すべての変種を読み取り専用の検索として扱うのではなく、お使いのリリースと承認された診断手順について文書化された動作に従ってください。

トレースがまだ教えてくれないこと

一つのメモに、tuple、一致した NAT ルール、フローを運ぶべきトンネルまたはポリシー、方向に固有の観察という四つを残します。それらがなければ、後任のエンジニアはローカルのポリシー判断を、確立されたコントロールプレーンや稼働中のサービスから切り分けられません。最初の失敗の後に成功が続いても、その間にトンネルが上がった証拠にはなりません。フェーズと状態変化を記録します。

内側の tuple から始め、設計と矛盾する最初のフェーズで止まり、それから初めてエンドポイントの証拠に手を伸ばします。トレースはポリシーの神託であり、配達証明ではありません。

関連記事