はじめに
ネットワークサービスに接続できない場合、サービスの状態、リスニングソケット、ローカルリクエスト、ファイアウォールルール、そして最終的なアクセスの順に、レイヤーごとにパスを確認してください。これにより、サービスが起動していないにもかかわらずファイアウォールのポートを開放してしまうといった無駄な作業を防ぐことができます。
この実験では、TCP ポート 8088 でリッスンしている小さな HTTP サービスがありますが、firewalld がそのポートを許可していません。サービスパスを調査し、不足している永続的なファイアウォールルールを追加します。
サービスの状態を確認する
このステップでは、ファイアウォールルールを確認する前に、アプリケーションサービスが実行されていることを確認します。
プロジェクトディレクトリに移動し、ワークスペースを作成します。
cd /home/labex/project
mkdir -p firewall-path
サービスの状態を確認します。
systemctl is-active rhce-http-demo.service | tee firewall-path/service-state.txt
サービスの実行コマンドを読み取ります。
systemctl show rhce-http-demo.service -p ExecStart | tee firewall-path/exec-start.txt
サービスはアクティブであるため、次の疑問は、期待されるポートでリッスンしているかどうかです。
リスニングソケットを調査する
このステップでは、ホストが TCP ポート 8088 でリッスンしていることを確認します。
ポート 8088 のリスニング TCP ソケットを表示します。
sudo ss -ltnp 'sport = :8088' | tee firewall-path/socket.txt
ループバック経由でサービスをテストします。
curl -s http://127.0.0.1:8088/ | tee firewall-path/loopback-response.txt
サービスはローカルで応答しているため、アプリケーション自体は正常に動作しています。
不足しているファイアウォールルールを見つける
このステップでは、firewalld でサービスポートを確認します。ローカルソケットが存在するからといって、ファイアウォールがそのポートを自動的に許可しているとは限りません。
デフォルトゾーンで開放されているポートを一覧表示します。
sudo firewall-cmd --list-ports | tee firewall-path/ports-before.txt
ポート 8088/tcp を照会します。
sudo firewall-cmd --query-port=8088/tcp | tee firewall-path/query-before.txt || true
クエリの結果は no となるはずであり、これは firewalld にルールが不足していることを意味します。
サービスポートを開放する
このステップでは、永続的な firewalld ルールを追加し、ファイアウォールをリロードします。
永続的なポートルールを追加します。
sudo firewall-cmd --add-port=8088/tcp --permanent
firewalld をリロードします。
sudo firewall-cmd --reload
再度ポートを照会します。
sudo firewall-cmd --query-port=8088/tcp | tee firewall-path/query-after.txt
これでファイアウォールがサービスポートを許可するようになりました。
完全なサービスパスを検証する
このステップでは、サービス、ソケット、ファイアウォールルール、および応答をまとめて検証します。
サービスの状態を確認します。
systemctl is-active rhce-http-demo.service
ファイアウォールのポートリストを表示します。
sudo firewall-cmd --list-ports | tee firewall-path/ports-after.txt
再度サービスにリクエストを送信します。
curl -s http://127.0.0.1:8088/ | tee firewall-path/final-response.txt
アプリケーションパスが完成しました：サービスはアクティブ、ソケットはリスニング状態、ファイアウォールルールは存在し、HTTP 応答も正常に機能しています。
まとめ
サービスパスをレイヤーごとに確認しました：サービスの状態、リスニングソケット、ローカル HTTP 応答、不足していた firewalld ポートの特定、永続的なファイアウォールの修正、そして最終的な応答の検証を行いました。
