ネットワークのポリシーテストとは？FW・ACLの許可/拒否・戻り通信・ログの確認手順

FWポリシーテストは、設定の存在ではなく、定義した送信元から実通信を発生させ、許可・拒否、戻り通信、セッション、NAT、ログが期待どおりかを確認する試験です。

本文では通信一覧から5ステップで試験し、HTTP/HTTPS・SSH・DNS・ICMPの操作、拒否試験、ヒットカウンター、パケットキャプチャ、証跡の完了条件を整理します。

この記事はネットワークエンジニアの仕事内容の各論です。工程の全体像から確認したい場合はそちらへ。

FWポリシーテストは設定投入だけで終わらせないのはなぜ？

設定が存在しても、適用方向、ルール順、NAT、戻り経路、アプリケーションの待受が誤っていれば通信は成立しません。実際の送信元から許可・拒否通信を発生させ、セッション、ログ、戻り通信、既存通信への影響まで確認して完了とします。

けんと＠設計構築チャンネル

FWのポリシーテストを読む前に、送信元、宛先、プロトコル、ポート、適用方向を構成図上で固定します。通信条件が曖昧なままルールだけ見ても、許可・拒否を正しく判断できません。

投入前に「通信要件と既存ポリシーを保存」を行い、拒否と既存設定の干渉をレビューします。例としてHTTPSならcurl、SSHなら接続、DNSならdigやnslookupを使い、ポートだけでなく実アプリの要求・応答を確認します。 この条件を手順書と試験表にも引き継ぎます。

投入後は該当するshowコマンドの出力やパケットキャプチャだけで完了にせず、実通信、カウンター、ログのいずれかで裏付けます。UDPは応答または受信側キャプチャがなければ到達を断定しにくい。 戻せる設定差分と中止条件も同時に用意します。

FWポリシーテストの実施はどの順序で進める？

送信元・宛先・プロトコル・ポートと期待結果を固定し、待受確認、許可試験、拒否試験、戻り通信・NAT、FWログ・カウンター、既存通信への回帰試験の順で進めます。各試験へ時刻と該当ルールを対応付けます。

送信元・宛先・プロトコル・ポート・方向を固定したうえで、日時・対象・実行した内容・結果を一組で残します。操作、期待結果、FWログ、サーバーログ、戻り、NAT、時刻を試験表に記載する。 作業者が変わっても、どこまで確認済みかを証跡から判断できます。

けんと＠設計構築チャンネル

FWポリシーの変更前後は、適用インターフェース、ルールの順序、hit count、戻り通信を同じ条件で比べます。設定差分だけでなく実際に通ったルールまで確認してください。

(出典：Service Name and Transport Protocol Port Number Registry（IANA）)

STEP1｜送信元・宛先・プロトコル・ポートをどう確認する？

STEP1では、試験する通信を送信元IP、宛先IP、プロトコル、ポート、方向、NAT前後のアドレスへ分解します。FW ルール名、試験端末、サーバー側の待受状態も同じ行へ記載し、どのポリシーを通る想定かを試験前に固定します。

試験前に、送信元IP、宛先IP、IPプロトコル、TCP/UDPポート、通信方向、NAT前後アドレスを1行の試験条件へ固定します。『Web疎通』だけでは、DNS、HTTP、HTTPS、戻り通信のどこを試したか残らないためです。

STEP2｜実際のアプリケーション通信を発生させるには？

TCP/443ならブラウザ表示だけでなくcurl -vkで接続・TLS・HTTP応答を分け、UDP/53ならdigと受信側キャプチャで到達を確認します。単純なポート open確認ではアプリケーション処理と戻り通信まで証明できません。

通信条件は？

通信条件の確認基準：UDPは応答または受信側キャプチャがなければ到達を断定しにくい。

ルール順序・適用インターフェース・NAT前後をレビューしたら、日時・対象・確認した内容・結果を一組で残します。変更後の差分や再発時の比較基準として使える記録になります。

けんと＠設計構築チャンネル

FWポリシーの試験には、許可通信だけでなく拒否通信も入れます。DNSやNTPなどの管理通信が巻き込まれていないかを見ると、業務通信以外の影響も拾えます。

実アプリではどんな通信が発生する？

実アプリ通信：ステートフルFWではセッションと戻り通信を確認する。

許可・拒否・戻り通信の試験を実行したら、日時・対象・実行した内容・結果を一組で残します。第三者は同じ入力と期待値を使って結果を追試できます。

curl -vk https://192.0.2.10/
nc -vz 192.0.2.10 443
nslookup example.com 192.0.2.53
dig @192.0.2.53 example.com
show access-lists
show logging

TCP・UDP・ICMPで確認すること

TCP・UDP・ICMP：UDPは応答または受信側キャプチャがなければ到達を断定しにくい。

カウンター・セッション・ログ・サーバー応答を照合について、実施条件・結果・採否理由を記録します。口頭説明に頼らず、次のレビューで同じ条件を照合できます。

STEP3｜許可通信と拒否通信の両方を試験するには？

許可試験はアプリケーション応答、セッション、ルールヒット、サーバーログがそろうこと、拒否試験は対象ルールで拒否され、別の許可通信へ影響しないことを合格条件にします。境界値として隣接サブネット、別ポート、逆方向も試すと、広すぎるルールを検出できます。

許可と拒否で確認すること

許可と拒否の確認基準：許可試験と拒否試験を対にする。

記録には実施時刻と取得元を入れ、次の作業者が結果を追跡できるようにします。

STEP4｜戻り通信・セッション・NAT変換をどう確認する？

ステートフルFWでは、許可通信のセッションが作成され、戻りパケットが同じセッションへ一致することを確認します。NATがある場合は変換前後のIP・ポート、サーバーログで見える送信元、復路が同じ装置を通るかを照合します。

戻り通信とステートの確認

許可通信のセッションが作成され、戻りパケットが同じ状態情報へ一致するかを確認します。非対称経路、NAT変換の不一致、セッションタイムアウトがあると戻りだけ失敗するため、往路と復路を別々の観測点で追います。

NATで確認すること

NAT：NAT前後、ルールヒット、サーバーログを時刻でひも付ける。

STEP5｜FWログ・カウンター・パケットキャプチャをどう確認する？

試験時刻、5タプル、ルール名を固定し、該当ルールのヒットカウンターと許可・拒否ログを確認します。必要な場合だけFW内外で短時間キャプチャし、どの観測点まで同じ通信が到達したかを比較します。

想定と違っても、その場でclearや設定変更はしません。 この順序なら、作業前後で同じ条件を比較できます。

HTTP・SSH・DNS・ICMPの試験コマンドの具体例は？

HTTP/HTTPSは curl、SSHは Test-NetConnection または nc、DNSは dig/nslookup、ICMPは ping を使い分けます。成功・失敗だけでなく、実行時刻、送信元IP、応答コード、タイムアウト、FW ルールのヒットカウントを同時に保存します。

試験結果と証跡へ何を記載する？

証跡には試験項番、実行時刻、送信元・宛先、プロトコル/ポート、操作、期待値、実結果、FW ルール、NAT変換、サーバーログ、判定者を記載します。画像だけでなくテキストログも残し、機器・端末・サーバーの時刻を同期させます。

証跡として残すもの

証跡：NAT前後、ルールヒット、サーバーログを時刻でひも付ける。

口頭説明だけにせず、構成・操作・出力を対応付けてレビュー可能にします。

ポート疎通だけでは確認できないことは？

ポート疎通だけでは、TLS certificate、HTTP status、認証、アプリケーションエラー、戻り通信、NAT後のサーバーログまでは確認できません。TCP接続が成功しても業務処理が失敗するため、実アプリケーションの要求と応答コードまで試験します。

関連する仕組みをどの順序で確認する？

• ネットワークのポリシーテストとは？FW・ACLの試験手順
• CiscoのミラーポートとWiresharkで通信障害を切り分ける方法

試験漏れを防ぐには何をチェックする？

試験漏れを防ぐには、許可・拒否、TCP・UDP・ICMP、戻り通信、NAT前後、実アプリケーション、ルールのヒットカウンター、ログ、既存通信への回帰影響を確認します。各試験に送信元・宛先・プロトコル・ポートと期待結果を持たせてください。

試験漏れを防ぐ確認

試験漏れ：許可試験と拒否試験を対にする。

実通信・ログ・戻り通信まで確認して完了とするには？

ポートが開いたという結果だけでは完了にできません。実際のアプリケーション通信、戻り通信、セッションとNAT変換、該当ルールのカウンター、許可・拒否ログまで照合し、期待した通信だけが通ることを確認して完了とします。

試験結果の一行に何を書くか

実案件では試験端末、送信元IP、宛先、プロトコル/ポート、操作、期待結果、FWログ、サーバーログ、証跡を一行にします。タイムアウトを拒否と即断せず、サーバー未起動や復路不備を切り分けます。大量試験はログ容量と監視通知への影響も事前調整します。

例えば、HTTPSならcurl、SSHなら接続、DNSならdigやnslookupを使い、ポートだけでなく実アプリの要求・応答を確認します。 このとき「curl -vk https://192.0.2.10/」と「nc -vz 192.0.2.10 443」を闇雲に取るのではなく、どの仮説を確認する出力かを手順書に書きます。対象と時刻がないログは、後から正常・異常を判断できません。

レビューでは、ポートが開いていればアプリケーションも正常だという断定や、本番環境での無許可テストを通さないようにします。そのうえで、代わりに何のコマンド出力で確認するかまで決めておきます。 変更の一部が正常でも業務通信全体が成立するとは限らないため、層の異なる証跡を組み合わせます。

また、HTTP・DNS・SSH・ICMPごとの実通信コマンドと確認観点を表にする。 この観点を設計書、設定レビュー、試験仕様、作業手順の各成果物へ通して反映します。個人の経験に閉じず、第三者が同じ順序で再現できる状態にすることが、設計構築案件の品質につながります。

この内容は、設計構築チャンネルの動画でも解説しています。

まとめ

FWポリシーテストは、設定の存在ではなく、許可・拒否・戻り・NAT・ログ・既存通信への影響が要件どおりかを実通信で確認します。試験項番と5タプル、時刻、ルール、期待結果、実結果を対応付けて完了判定してください。

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針