network policy testは、FW/ACLの許可通信だけでなく、拒否すべき通信、戻り通信、NAT後のaddress、log、既存通信への影響を確認します。source・destination・protocol・port・direction・期待結果をtest表へ固定してから実施します。
けんと＠設計構築チャンネル
ポリシーテストを読む前に、送信元、宛先、protocol、port、適用方向を構成図上で固定します。通信条件が曖昧なままruleだけ見ても、許可・拒否を正しく判断できません。
ネットワークのポリシーテストでは何を試す？
先に答えると、network policy testは、FW/ACLの許可通信だけでなく、拒否すべき通信、戻り通信、NAT後のaddress、log、既存通信への影響を確認します。source・destination・protocol・port・direction・期待結果をtest表へ固定してから実施します。
試験項目をどう作る？
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| allow | 必要通信が成立 | application応答とpolicy hit |
| deny | 不要通信が拒否 | timeout/RST/ICMPとdeny log |
| return | stateful sessionの戻り | session tableと両方向packet |
| regression | 既存通信を壊していない | 代表serviceの再試験 |
Client 192.0.2.10 --tcp/443--> FW --DNAT?--> Server 10.0.0.10
source/destination/protocol/port/direction/logを対応許可・拒否・戻り通信をどう確認する？
許可・拒否・戻り通信をどう確認する？では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 通信要件からpositive/negative testを作る | 境界値も含める |
| 2 | rule IDとNAT/routeの処理点を確認 | どのaddressで照合するか |
| 3 | applicationで接続し両端logを取得 | pingだけにしない |
| 4 | 既存通信とmonitoringを再確認 | 変更全体の完了判定 |
# Linux client例
curl -vk --connect-timeout 5 https://203.0.113.10/
nc -vz -w 5 203.0.113.10 443
# Cisco ACL counter例
show ip access-lists WEB-INTest ID: FW-ALLOW-01
Expected: TCP 443 established / HTTP 200 / rule 120 hit +1
Actual: TCP established / HTTP 200 / rule 120 hit +1
Result: PASS想定外結果をどう切り分ける？
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| allowがtimeout | route・ARP・NAT・policy・server | 各観測点のcounter/log |
| denyが通る | shadow rule・direction・object | matched rule ID |
| SYN/SYN-ACK後に失敗 | return policy・MTU・TLS/app | captureとserver log |
| 既存通信に影響 | rule order・object範囲 | 即時rollback条件 |
完了条件を何にする？
本番testでは、意図的なdeny試験が監視alertやsecurity incidentを発生させる場合があります。送信元、時間帯、連絡先を事前合意し、負荷testやport scanを無断で実施しません。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ：通信要件をallow・deny・戻り・回帰試験へ分解する
通信要件をallow・deny・戻り・回帰試験へ分解することが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
