
얼마 전 웹서버 이전 뒤에 443 포트가 열려 있다는 연락을 받았습니다. 서버에서는 접속이 됐지만 외부에서는 연결이 끊겼습니다. 이런 경우 방화벽 명령 하나만 보고 판단하면 시간을 허비하기 쉽습니다. 서비스가 실제로 포트를 열었는지, 서버 방화벽이 허용하는지, VPS나 클라우드의 외부 방화벽이 통과시키는지를 순서대로 봐야 합니다.
먼저 어떤 방화벽을 쓰는지 확인합니다
리눅스 방화벽 확인 명령은 운영체제 이름만으로 고르면 안 됩니다. Ubuntu에서도 UFW를 쓰지 않을 수 있고, Rocky Linux에서도 firewalld가 중지된 채 다른 규칙이 적용될 수 있습니다. 우선 sudo ufw status verbose, sudo firewall-cmd --state를 실행해 봅니다. 앞의 명령이 Status: active를 보여주면 UFW가 활성화된 상태입니다. 뒤의 명령이 running을 보여주면 firewalld가 실행 중입니다. 명령이 없거나 비활성이라고 나와도 서버에 방화벽 규칙이 전혀 없다는 뜻은 아닙니다.
그다음 sudo nft list ruleset으로 nftables 규칙을 확인합니다. 규칙이 보이면 체인의 hook, policy, 허용·차단 조건을 함께 읽어야 합니다. 레거시 iptables를 쓰는 서버라면 sudo iptables -S와 sudo ip6tables -S도 확인합니다. 이 명령들은 기본 filter 테이블을 보여주므로 포트 전달이나 주소 변환이 의심되면 sudo iptables -t nat -S까지 봅니다. 도구마다 같은 커널 방화벽을 다른 방식으로 표시할 수 있어, 출력된 규칙을 단순히 더해서 해석하면 안 됩니다.
UFW와 firewalld에서는 적용 범위를 봅니다
UFW를 쓴다면 sudo ufw status numbered로 허용·거부 규칙과 순서를 봅니다. sudo ufw status verbose에는 기본 정책도 나옵니다. 예를 들어 443/tcp 허용 규칙이 있어도 IPv6 접속을 받는 서버라면 IPv6 쪽 규칙도 확인해야 합니다. 80과 443을 모두 쓰는 사이트에서는 두 포트를 따로 봅니다. 22/tcp는 관리자 접속 경로이므로 변경 전에 현재 SSH 접속에 쓰는 포트부터 확인하는 편이 안전합니다.
firewalld는 영역별로 규칙을 적용합니다. sudo firewall-cmd --get-active-zones로 네트워크 인터페이스가 속한 영역을 찾고, sudo firewall-cmd --zone=영역이름 --list-all로 그 영역의 서비스와 포트를 확인합니다. 기본 영역의 규칙만 보면 실제 외부 인터페이스에 적용된 규칙을 놓칠 수 있습니다. sudo firewall-cmd --permanent --zone=영역이름 --list-all은 재시작 후에도 남을 설정을 보여줍니다. 현재 적용 중인 규칙과 영구 설정이 다른 경우도 있으니 둘 다 비교해야 합니다.
열린 포트와 외부 접속을 따로 검증합니다
방화벽에서 허용한 포트에 서비스가 떠 있지 않으면 접속은 실패합니다. sudo ss -lntup으로 수신 중인 TCP·UDP 소켓과 프로세스를 확인합니다. 웹서버가 127.0.0.1의 443 포트에서만 듣고 있다면 서버 내부에서는 접속돼도 외부에서는 받을 수 없습니다. 반대로 0.0.0.0의 443 포트에서 듣는다고 해서 외부 접속까지 보장되는 것도 아닙니다. 주소, 포트, 프로토콜을 각각 맞춰 봐야 합니다.
다른 네트워크의 장비에서 nc -vz 서버_IP 443으로 연결을 시험하면 서버 내부 검사보다 한 단계 더 확인할 수 있습니다. 연결이 거부되면 해당 주소와 포트에서 서비스를 받지 않는 상황을 먼저 의심하고, 시간이 지나도 응답이 없으면 서버 방화벽이나 앞단의 차단 규칙을 살핍니다. 다만 두 증상만으로 원인을 확정할 수는 없습니다. VPS·클라우드라면 서비스 업체의 인바운드 규칙, 공인 주소 연결 상태, 로드밸런서 설정도 함께 확인해야 합니다. 호스팅 업체가 별도 방화벽을 제공하는 경우도 같습니다.
컨테이너와 변경 작업에서 자주 놓치는 지점
Docker로 서비스를 띄웠다면 docker ps에서 포트 게시 상태를 확인합니다. 컨테이너 내부의 80 포트를 호스트의 8080 포트로 게시했다면 외부에서 검사할 포트는 8080입니다. Docker가 만든 포트 전달 규칙은 UFW의 일반적인 허용·거부 목록만 봐서는 예상과 다르게 동작할 수 있습니다. 컨테이너 포트가 외부에 노출되는지 실제 다른 장비에서 확인해야 합니다.
규칙을 바꿀 때는 현재 SSH 세션을 유지한 채 새 세션으로 재접속을 시험합니다. firewalld에서 임시로 바꾼 규칙은 재시작 뒤 사라질 수 있고, 영구 설정만 바꾼 규칙은 다시 불러오기 전까지 적용되지 않을 수 있습니다. 저는 장애가 나면 먼저 ss로 서비스의 수신 주소를 보고, 적용 중인 방화벽 규칙과 외부 접속 결과를 대조합니다. 이 순서가 포트를 무작정 여는 것보다 원인을 빨리 좁혀 줍니다.
