firewalld에서 포트를 열었는데 막힌다면, 방화벽이 하나가 아니다
포트를 --add-port로 열었는데도 막힌다면, firewalld 안의 문제이거나 firewalld 밖의 다른 계층이다. firewalld 안부터 정확히 좁힌다.
1) zone이 다르다
firewalld는 zone 단위다. 규칙을 default(public)에 넣었는데 그 인터페이스가 다른 zone(예: internal)에 묶여 있으면 규칙이 적용되지 않는다.
firewall-cmd --get-active-zones # 인터페이스가 어느 zone 인지
firewall-cmd --zone=public --list-all # 그 zone 에 실제 반영된 규칙2) permanent와 reload를 안 맞췄다
--permanent 없이 넣으면 재시작 때 사라지고, --permanent만 넣고 --reload를 안 하면 지금은 반영이 안 된다. 둘 다 필요하다.
3) rich rule이 앞서 막는다
더 구체적인 rich rule의 drop/reject가 일반 포트 허용보다 앞서면 허용을 덮는다. --list-rich-rules로 충돌을 확인한다.
4) firewalld 밖의 계층
여기까지 맞는데도 막히면 방화벽 밖을 본다.
- 클라우드 보안그룹/NACL — 호스트 방화벽을 다 열어도 이게 막으면 그대로 실패한다.
- SELinux 포트 라벨 — 서비스가 표준 아닌 포트를 쓰면
semanage port로 라벨을 줘야 바인딩/수신이 된다. - rp_filter — 비대칭 라우팅에서 리턴 패킷이 조용히 드롭된다.
ss -tlnp # 실제로 그 포트를 듣고 있는지(방화벽 이전 문제)
# 반대편에서: nc -vz <host> <port>순서
실제 listen 확인(ss) → zone → permanent+reload → rich rule → 보안그룹/SELinux/rp_filter. “firewalld를 열었다”는 방화벽 계층 하나를 통과했다는 뜻일 뿐이다.
빠른 진단 체크리스트
ss -tlnp로 그 포트를 실제 듣고 있는지 먼저 본다--get-active-zones로 인터페이스가 어느 zone인지 확인한다- 규칙을 넣은 zone과 인터페이스 zone이 같은지 본다
- --permanent와 --reload를 함께 적용했는지 확인한다
- rich rule의 drop/reject가 포트 허용을 덮는지 본다
- 클라우드 보안그룹·NACL이 막는지 확인한다
- 비표준 포트면 SELinux 포트 라벨(semanage)을 확인한다
- 비대칭 라우팅이면 rp_filter가 리턴 패킷을 드롭한다