SELinuxが原因で通信できない時の切り分け手順【Firewall正常でも要注意】

Linuxサーバーで「ポートはLISTENしている」「Firewallも開いている」 にもかかわらず通信できない場合、原因として非常に多いのが SELinux です。

本記事では、SELinuxが通信を遮断する仕組みから、 ログを使った切り分け、正しい対処方法までを実務目線で解説します。

SELinuxとは何か（通信との関係）

SELinux（Security-Enhanced Linux）は、 プロセスとリソースのアクセスを制御する強制アクセス制御（MAC）機構です。

重要なのは、SELinuxは

• ポートが開いていても
• iptables / firewalld が許可されていても

ポリシーに反すれば通信を拒否する点です。

SELinuxが原因の時に起きる典型症状

• 外部から接続できない
• アプリ間通信だけ失敗する
• localhostでは接続できる
• 再起動しても直らない

NW機器やFirewallの設定変更では改善しません。

まず確認すべきSELinuxの状態

① SELinux有効かどうか

getenforce

• Enforcing：強制有効
• Permissive：警告のみ
• Disabled：無効

② 一時的に無効化して切り分け

setenforce 0

これで通信できるようになれば、 SELinuxが原因であることが確定します。

※ 恒久対策として無効化するのは非推奨

SELinuxログで原因を特定する

① AVCログの確認

ausearch -m AVC -ts recent

または

grep AVC /var/log/audit/audit.log

通信拒否は AVC denied として記録されます。

よくある通信拒否パターン

① httpdが外部通信できない

Webサーバーから外部APIへ接続する場合、 デフォルトでは拒否されます。

対処：

setsebool -P httpd_can_network_connect on

② 非標準ポートが使えない

SELinuxはポート番号にもラベルを持ちます。

semanage port -l | grep http

追加例：

semanage port -a -t http_port_t -p tcp 8081

③ カスタムアプリの通信が遮断される

独自バイナリやカスタムサービスは、 適切なコンテキストが付与されていないことが多いです。

コンテキストの確認と修正

① 現在のコンテキスト確認

ls -Z /path/to/binary

② 正しいコンテキストに修正

chcon -t bin_t /path/to/binary

※ 恒久的には semanage fcontext を使用

audit2allowでポリシーを生成する

一時的・検証用途での対処方法です。

grep AVC /var/log/audit/audit.log | audit2allow -M mypolicy
semodule -i mypolicy.pp

※ 安易な使用はセキュリティ低下につながります

SELinuxを無効化すべきではない理由

• 攻撃耐性が大きく低下
• 本番環境で非推奨
• 将来の事故要因になる

「切り分けのために一時無効」はOKですが、 恒久対策は必ずポリシー調整にしましょう。

通信トラブル時の切り分けチェックリスト

• getenforceで状態確認
• setenforce 0で影響確認
• AVCログ確認
• ポートラベル確認
• Boolean設定確認

まとめ

SELinuxが原因の通信障害は、 NW・FW・アプリがすべて正常に見えるため、 発見が遅れがちです。

「通信できないが設定は正しい」と感じたら、 必ずSELinuxログを確認してください。

正しい切り分けができれば、無効化せず安全に解決できます。