ファイアウォールのポート開放確認は、「設定を見たら終わり」ではありません。
実務では 設定は正しいのに通信できない、あるいは 一部の環境だけ接続できない といったケースが頻発します。
その原因の多くは、
といった 切り分け不足 にあります。
本記事では、ポート開放確認を「考え方 → 設定確認 → 通信確認 → 切り分け」の順で、誤解が起きにくい形に整理して解説します。
ポート開放の確認とは、単に「ファイアウォールで許可されているか」を見ることではありません。
最低限、次の 2点が同時に満たされている必要があります。
どちらか一方が欠けていると、通信は成立しません。
さらに実務では、以下のような 追加レイヤ も確認対象になります。
調査を始める前に、以下を明確にしてください。
| 項目 | 内容 |
|---|---|
| ポート番号 | 例:80 / 443 / 22 / 3306 |
| プロトコル | TCP か UDP |
| 通信方向 | 外部→内部(Inbound)か 内部→外部(Outbound) |
| 接続元 | 同一LAN / 社内 / インターネット |
特に Inbound と Outbound の混同 は非常に多く、確認対象を誤る原因になります。
ファイアウォール以前に、アプリケーションが起動していなければ通信はできません。
sudo ss -lntp # TCP
sudo ss -lnup # UDP
netstat -ano
LISTEN 状態になっているかここで問題があれば、ファイアウォールを見ても意味がありません。
GUI確認も可能ですが、実務では PowerShell のほうが正確です。
Get-NetFirewallRule -Direction Inbound -Enabled True |
Get-NetFirewallPortFilter |
Where-Object {
$_.LocalPort -eq "80" -and $_.Protocol -eq "TCP"
}
併せて以下も確認します。
# runtime(現在有効)
firewall-cmd --list-all
# permanent(再起動後も有効)
firewall-cmd --permanent --list-all
# ポート単体確認
firewall-cmd --query-port=80/tcp
firewall-cmd --permanent --query-port=80/tcp
※ runtime と permanent の違いを見落とすと、「再起動後に繋がらない」原因になります。
ufw status verbose
nc -vz サーバーIP ポート番号
結果の正しい解釈
「refused」は“届いている”証拠であり、切り分け上は重要な情報です。
nmap -p 80,443 xxx.xxx.xxx.xxx
| 表示 | 意味 |
|---|---|
| open | ポート開放・待ち受けあり |
| closed | 到達しているが開いていない |
| filtered | FW/ACL等で遮断されている可能性 |
ルーター配下のサーバーでは、次の 2段階確認 が必須です。
さらに注意点として、LAN内から自分のグローバルIPに接続できない場合があります
(NATループバック非対応)。
外部確認は 別回線(スマホ回線等)から行うのが確実です。
クラウドでは OS ファイアウォールとは別に、クラウド側のネットワーク制御が存在します。
OSで開いていても、ここが閉じていれば通信できません。
この場合、「開いているのに繋がらない」状態になります。
待ち受けアドレスと、実際の接続経路が一致しているかを必ず確認してください。
この順序を守ることで、無駄な調査を大幅に減らせます。
以上、ファイアウォールのポート開放の確認についてでした。
最後までお読みいただき、ありがとうございました。