firewalldとSELinuxの役割の違い【混同しがちな通信制御を完全整理】

Linuxサーバーで通信トラブルが起きた際、 firewalld（iptables）とSELinuxの役割を混同していると、 切り分けに時間がかかり、誤った対処をしてしまいがちです。

本記事では、firewalldとSELinuxの違いを 「何を・どこで・どう制御しているのか」という観点で整理し、 実務で迷わない切り分け思考を身につけます。

結論：firewalldとSELinuxは役割がまったく違う

項目	firewalld	SELinux
制御対象	通信経路	プロセスの権限
判断基準	IP / ポート / プロトコル	ドメイン / コンテキスト
主な役割	通信を通すか止めるか	誰が使ってよいか

両方が許可されて初めて通信が成立します。

firewalldが制御しているもの

firewalld（iptables）はネットワークレイヤの制御です。

• どのIPから
• どのポートに
• どのプロトコルで

通信を通すかを判断します。

例：8080を開放

firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

firewalldは「通信路を開ける」だけです。

SELinuxが制御しているもの

SELinuxはアプリケーションの権限管理です。

• どのプロセスが
• どのリソースに
• どうアクセスできるか

を制御します。

たとえ firewalld が許可していても、 SELinuxが拒否すれば通信は成立しません。

典型的な混同パターン

ケース① ポートは開いているのに通信できない

• firewalld：OK
• SELinux：NG

→ 非標準ポート未登録、Boolean未設定が原因

ケース② localhostでは通信できる

外部通信だけ失敗する場合、 SELinuxの外部通信制御が原因のことが多いです。

切り分けの基本フロー

1. firewalld状態確認
2. ポートLISTEN確認
3. getenforce確認
4. AVCログ確認

一時的な切り分け方法（非推奨だが有効）

SELinuxを一時的に緩める

setenforce 0

これで通信できればSELinuxが原因です。

※ 恒久対策は必ずポリシー調整

よくある誤解

• rootならSELinuxは関係ない → 誤り
• Firewall開けたから大丈夫 → 誤り
• SELinux無効が正解 → 誤り

実務で覚えるべき考え方

通信トラブルでは必ず以下を疑います。

• 経路は開いているか（firewalld）
• 権限は許可されているか（SELinux）

どちらか一方だけ見ても解決しません。

まとめ

firewalldとSELinuxは競合するものではなく補完関係です。

役割を正しく理解すれば、 通信トラブルの切り分け速度は劇的に向上します。