ファイアウォールでポートを開放する
RHEL/MiracleLinux系では firewalld が既定のファイアウォールで、外部からの通信を初期状態で多くしゃ断しています。Webサーバを立てても http サービス（80番）を許可しなければ、外からはアクセスできません。firewall-cmd で http や https のサービスを恒久的に許可し、--reload で反映します。設定は「ゾーン」単位で管理され、--permanent を付けないと再起動で消える点に注意します。
Webサーバを起動し、サーバ自身からは curl http://localhost で応答が返るのに、別の端末からはどうしてもアクセスできない。サーバ構築でほぼ誰もが一度はぶつかる場面だ。
設定はどこも間違っていないように見えるのに、なぜ外から届かないのか。その犯人の多くがファイアウォールだ。
ファイアウォールは、ネットワークインターフェースを通ろうとするパケットを監視し、OSの内側へ通すか遮断するかを決める関所のような仕組みである。
RHEL/MiracleLinux系では firewalld というサービスがこの役割を担う。インストール直後の状態では、外部からの通信のほとんどを初期設定でしゃ断するようになっている。
これはセキュリティ上は望ましい初期値で、「必要な通信だけを明示的に許可して開ける」という考え方に基づいている。つまり、つながらないのは故障ではなく、関所がきちんと仕事をしている証でもあるのだ。
🔍 まず関所は開いているか 状態を確認する
まず確かめるべきは、その関所がそもそも稼働しているかだ。firewalld 自体も systemd 管理下のサービスなので、systemctl status firewalld で動いているかを確かめる。Active: が active (running) なら機能している。
次に現在の許可状況を見るには sudo firewall-cmd --list-all を実行する。先頭に public (active) のように現在のゾーン名が表示され、services: の欄に許可済みのサービスが並ぶ。
インストール直後はここに ssh と dhcpv6-client 程度しかなく、http や https は含まれていない。これが、Webが外から見えない理由そのものだ。
firewall-cmd は設定を扱うコマンドなので管理者権限が必要で、一般ユーザでは sudo を付ける。firewalld が動いていないと FirewallD is not running と表示される。
🛡 なぜ「ゾーン」という単位で考えるのか
firewalld の設定は「ゾーン」という単位で管理される。ゾーンとは、ネットワークの信頼度に応じた設定のまとまりで、各ネットワークインターフェースがいずれかのゾーンに割り当てられる。
firewalld にはあらかじめ public（公衆ネットワーク向けの既定）・home・work・trusted（すべて許可）など複数のゾーンが用意されており、用途に応じて使い分ける。
標準的なサーバでは public ゾーンが使われ、許可ルールもこのゾーンに対して追加していく。
いまどのインターフェースがどのゾーンに属しているかは sudo firewall-cmd --get-active-zones で確認できる。
ゾーンという仕組みがあるおかげで、たとえば社内向けインターフェースと外部向けインターフェースで、許可する通信を別々に管理する、といった使い分けができる。信頼度の違う入口に、違う厳しさの関所を置けるわけだ。
🚪 ポート番号を覚えなくていい add-service
firewalld の便利な点は、ポート番号を直接覚えなくても「サービス名」で許可を指定できることだ。
Webサーバに必要なのはHTTP（80番）とHTTPS（443番）で、これらは http・https というサービス名で登録されている。
HTTPを許可するには sudo firewall-cmd --permanent --zone=public --add-service=http、HTTPSなら同様に --add-service=https を実行する。success と表示されれば登録できている。
--permanent は再起動後も残る恒久設定の指定、--zone=public は対象ゾーンの指定だ。
どんなサービス名が使えるかは sudo firewall-cmd --get-services で一覧でき、ssh・http・https・dns・ftp など主要なものはあらかじめ定義されている。
もちろん sudo firewall-cmd --permanent --add-port=80/tcp のようにポート番号で直接指定することもできる。ただし標準的なサービスはサービス名で開けるほうが分かりやすく、間違いも起きにくくなる。
誤って許可してしまったルールを取り消したいときは、--add-service を --remove-service に置き換えて実行し、同じく --reload で反映する。
🔁 追加したのに効かない permanent と reload の関係
ここが最大の落とし穴だ。--permanent を付けて追加したルールは、設定ファイルに書き込まれただけの状態で、その場では有効にならない。
実際に効かせるには sudo firewall-cmd --reload を実行して読み込ませる必要がある。
逆に --permanent を付けずに add-service すると、その場ですぐ有効になるが、サーバを再起動すると消えてしまう。
つまり「恒久化したいなら --permanent で追加してから --reload」「お試しで即時反映したいだけなら --permanent なし」という関係だ。
本番では恒久化と反映の両方が要るので、--permanent で追加 → --reload、という二段構えが定石になる。reload を忘れたまま「開けたはずなのに繋がらない」と悩むのが、典型的なつまずきだ。
⚠ つまずいたら、まずこれ
反映できたら、もう一度 sudo firewall-cmd --list-all を実行し、services: の欄に http と https が加わっていることを確認する。
あわせて、サービスが実際にそのポートで待ち受けているかは ss コマンドで、外部からの到達は別端末の curl やブラウザで確かめる。
よくある失敗は3つだ。--reload を打ち忘れる。--permanent を付け忘れて再起動で設定が消える。ゾーンを取り違えて別ゾーンに許可を入れてしまう。
さらにクラウド（AWS や Azure など）で公開する場合は、サーバ内の firewalld を開けても、その手前にあるクラウド側のネットワークファイアウォール（セキュリティグループなど）が閉じていれば通信は届かないため、両方を開ける必要がある。
実務の鉄則は「本当に必要なポートだけを開ける最小公開」で、不要なサービスは許可しないことが、そのままサーバの安全性につながる。