VPNが復号した後、どのASAルールがトラフィックを見るのか

まず捨てるべき前提は、暗号ACLがアクセスポリシーだという考えです。そうではありません。Cisco ASAでは、あのリストは「どのパケットが保護に値するか」という狭い問いに答えるだけで、復号されたパケットがファイアウォール背後のサーバーに到達してよいかについては何も語りません。アクセスは後から、インターフェースポリシー、グループポリシーフィルター、あるいはその両方によって、トンネルの作り方に応じて決まります。

暗号ACLは別の問いに答える

暗号ACLは照合リストです。二つのピア間で何を暗号化するかをトンネルに伝え、そこに一致しないパケットはそもそも保護されません。広げても変わるのは保護の範囲だけで、それ以外ではありません。

だからそこにサブネットを足すと、トンネルは上がるのに実際のアプリケーションは失敗し続けることがあります。トンネルが上がるのは一致が生まれたからです。アプリケーションが失敗し続けるのは、あのリストが何も許可しないからです。別の問いには別のリストが答えます。

バイパス設定が実際に飛ばすもの

sysopt connection permit-vpn は、保護されたトラフィックが受信側で本来適用されるインターフェースACLの検査を飛ばせるようにします。VPN導入のための便宜であり、しかもグローバルです。グループポリシーには触れず、ユーザーごとの認可フィルターにも触れません。

前提ではなく実際の値を読み取ります。show running-config all sysopt は明示的に設定したことがなくても設定値を表示するので、多くの混乱はここから始まります。

グローバルな設定なので、失敗している一つのサブネットで手早く試すのは割に合いません。そのファイアウォール上の他のすべてのトンネルが結果を共有します。ロールバック計画を伴う意図的な変更のために取っておきましょう。

復号方向でフィルターを読む

LAN-to-LAN の vpn-filter はインターフェースではなくトンネルの視点で書きます。復号後のパケットはそう見えるので、リモートネットワークが送信元の位置に、ローカルネットワークが宛先の位置に入ります。同じフィルターは暗号化の前に逆方向でもう一度評価され、アドレスの役割が反転します。

まさにその理由で、ポート条件はコピーしたインターフェースACLよりも慎重に扱うべきです。ある宛先ポートを許可するルールは、新しい接続がそのポートを送信元として使う逆方向で意図しない効果を持ちえます。リストを作る前に、どちら側が開始できるか、実際のサービスは何か、閉じたままにすべき相手はどれかを書き留めてください。

どのフィルターが実際に付いているかを確認します。show running-config group-policy と show vpn-sessiondb detail l2l を合わせると、セッションが何を継承したかが分かります。どのポリシーからも参照されていないACLを編集しても何も変わりません。

一つのACLオブジェクトを二つの用途に使い回さない

インターフェースの access-group と vpn-filter は同じ種類のオブジェクトに見えますが、評価される位置もアドレスの向きも異なります。一つのリストを両方に割り当てると、トンネルを直しつつ物理インターフェースを静かに緩める変更を招きます。

別々に保ち、役割に応じた名前を付け、向きの違いが名前で分かるようにします。

新しい接続で、両方向とも検証する

計画的な変更の後、許可されるべき新しい接続と拒否されるべき新しい接続を一つずつ開き、アドレス、向き、ポリシー一致を結果とともに記録します。確立済みのセッションは新しい接続のフィルタリングを何も証明しません。すでに古いルールで通っているからです。

インスペクションも考慮します。ベンダーのドキュメントは、VPNフィルターが検査エンジンが開く二次接続のすべてではなく最初の接続を確認すると述べており、制御チャネルとそれに付随するメディアフローが異なる扱いを受けることがあります。アプリケーションがプロトコルを解釈するなら、単一のポート検査ではなく実際のフローを試してください。

広いバイパスの後に使えるようになったトンネルは、制限が満たされたのではなく取り除かれたことを示します。残す価値のある成果は、次のレビューで指し示せる名前付きの適用点です。