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

FWやACLの設定後、Webが開いたので試験完了。これだけでは、止めるはずの通信まで通っていないか、失敗が本当にFWの拒否によるものかを確認できません。

ポリシーテストは、決めた通信の許可・拒否が、期待どおりに働くかを確かめる試験です。図では同じPCからHTTPSを許可、SSHを拒否する例を使います。成功画面だけでなく、待受、経路、ログ、戻り通信も一緒に見ていきます。

「誰から誰へ、何を通すか」を先に書く

試験PCは172.27.81.15、サーバーは172.27.92.25です。間のFW1をそれぞれのゲートウェイにし、NATを使わない基本例にします。要求の方向と、TCP443を許可・TCP22を拒否する要件を表へ書きます。

送信元ポートは通常、端末が接続時に選びます。サーバーの待受ポートと同じ値ではないので、実際の試験で選ばれた値を記録します。

実際のFWではzone、適用IF、NAT前後、IPv4／IPv6の条件も加えます。図のIPだけを別の環境へ写して、同じ試験になったと判断しないでください。

拒否対象のサービスも、待ち受けていることを確認する

SSHサーバーが停止していれば、拒否ルールがなくても接続は失敗します。その失敗をFWの正常な拒否と判断すると、ポリシーの不備を見落とします。

サーバー側で待受を確認し、許可された別の試験経路などでサービスが動くことを確かめます。端末のIP・GW、往復の経路、ホスト側のFWも合わせます。

• 試験端末のIP・GW・接続先を確認する。
• サーバーでTCP443・TCP22の待受とホスト側の制御を確認する。
• FWの両方向の経路と、適用ルールの順を確認する。
• 該当ルールのカウンター、セッション、時刻を変更前に記録する。
• 既存セッションの扱いを決め、新規接続として試す。

「接続できない」を、サービス停止、経路不足、対象FWの拒否へ分ける準備です。試験したいFWだけで結果が変わる前提をそろえます。

新規接続を試す場合は、古いセッションの影響も確認します。既存の接続が続いていることと、新しい接続が許可されることは別です。

許可試験は、TCP・TLS・HTTPを順に見る

Test-NetConnectionなどでTCP443へ接続できるかを確認します。そのあとcurlやブラウザーで、証明書とHTTP応答まで調べます。TCPの接続成功だけでは、HTTPSの処理全体は確かめられません。

app.lab.exampleは説明用の名前です。証明書と検証用CAも、この名前に合うものを準備します。--resolveの例では接続先IPを固定するため、DNSの試験を別に行います。

WindowsでTCP接続を確認
Test-NetConnection 172.27.92.25 -Port 443

HTTPSの試験例：名前とIPを固定して接続
curl --connect-timeout 5 --max-time 15 --verbose \
  --resolve app.lab.example:443:172.27.92.25 \
  --cacert lab-ca.pem https://app.lab.example/

curlの-kは証明書検証を省略します。その成功を、証明書も正常だった結果へ読み替えないようにします。

HTTP401や403は、アプリ側が認証や権限で拒否している場合があります。ネットワークが通ったかと、期待する業務応答かを分けて判定してください。

拒否試験は、止めた装置とルールを示す

同じPCからTCP22の新規接続を試し、失敗を確認します。さらにFW1の対象拒否ルールで、時刻、IP、ポートがその試験と一致するログを探します。

必要なら図の取得点AとBで、要求の通過を比べます。Bで見えないことだけでは取得漏れの可能性もあるので、SPANの条件とFWログを合わせます。

ステートフルFWでは、許可した新規接続と返信が同じセッションに一致するかを確認します。単純なステートレスACLでは、戻り側のルールもそのパケットを許可する必要があります。

NATがある場合は、AとBでIPやポートが違うことがあります。変換前後を対応させ、同じIPのフィルターを両側へそのまま使わないようにします。

UDPと証跡は、送ったあとに何が起きたかまで残す

UDPの送信操作がエラーにならなくても、受信した証拠にはなりません。DNSなら回答、ほかのサービスなら応答や受信側ログを確認します。例のDNSサーバーは、図のWebサーバーとは別に準備する対象です。

DNSはUDP53だけでなくTCP53も使います。必要な通信を要件で決め、それぞれの結果を確認します。

検証用DNS 172.27.92.53へ問い合わせる例
nslookup app.lab.example 172.27.92.53
dig @172.27.92.53 app.lab.example A
dig +tcp @172.27.92.53 app.lab.example A

試験ID、条件、時刻、期待値、実結果、装置ログの保存先を一組にします。許可と拒否、戻り通信、既存通信の再確認までそろうと、設定が要件に合ったことを説明できます。

最初はHTTPS許可とSSH拒否の二つから始めてください。成功と失敗を作るだけでなく、その理由をログで確かめる練習になります。

動画・筆者の投稿で補足する

文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。

関連する動画・筆者の投稿：Xで読む

確認に使った公式資料

• curl：サーバー証明書の検証

このテーマを続けて学ぶ

Pingが通らない時の原因調査。NW障害の切り分け方→【実機で確認】リンクアップの見方。Ciscoルータ・Catalyst→Ciscoのミラーポート設定。WIRESHARKでNW通信障害の切り分け→

この記事の執筆・監修者

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

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

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

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

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