
얼마 전 접속 장애가 난 서버를 보니 웹서버는 정상인데 방화벽에서 새 포트만 막고 있었습니다. 이런 경우 방화벽을 끄면 금방 열리긴 합니다. 다만 운영 서버라면 먼저 어느 장치가 막는지 확인해야 합니다. 호스트 방화벽을 꺼도 클라우드 보안그룹에서 차단 중이면 결과는 같고, 반대로 웹서버가 열지 않아야 할 포트까지 외부에 드러날 수 있습니다.
끄기 전에 차단 위치부터 확인한다
먼저 서버 안에서 서비스가 실제로 포트를 열었는지 봅니다. sudo ss -lntp 명령으로 대기 중인 TCP 포트와 프로세스를 확인할 수 있습니다. 여기서 원하는 포트가 없다면 방화벽보다 서비스 설정을 먼저 봐야 합니다. 외부에서 접속이 안 되는데 서버 안에서는 연결된다면 그때 호스트 방화벽과 클라우드 보안그룹을 차례로 확인합니다.
방화벽 관리 도구도 확인해야 합니다. sudo ufw status, sudo firewall-cmd --state, sudo systemctl status nftables 가운데 설치된 도구의 결과를 봅니다. 명령이 없다는 메시지는 그 도구를 쓰지 않는다는 뜻일 뿐, 필터 규칙이 전혀 없다는 뜻은 아닙니다. sudo nft list ruleset으로 커널에 적용된 규칙도 확인할 수 있습니다. 서버에 따라 Docker 같은 서비스가 별도 규칙을 만들기도 합니다.
원격으로 작업한다면 현재 SSH 세션을 유지하고, 가능하면 새 터미널에서 한 번 더 접속해 둡니다. 콘솔 접속 수단이 있는지도 확인합니다. 방화벽을 끄는 명령 자체보다 이후에 규칙을 다시 켤 때 SSH 포트를 빠뜨려 접속이 끊기는 사고가 더 흔합니다.
우분투에서 UFW를 끄는 방법
우분투에서 UFW를 사용 중이라면 sudo ufw status verbose로 현재 상태와 규칙을 먼저 봅니다. sudo ufw disable을 실행하면 UFW가 비활성화됩니다. 이어서 sudo ufw status를 실행해 inactive 표시를 확인합니다. 이 명령은 규칙을 하나씩 지우는 작업이 아니므로, 나중에 sudo ufw enable로 다시 켤 때 기존 규칙이 적용되는지 확인해야 합니다.
예를 들어 새 웹 서비스가 8080번 포트에서 대기 중인데 UFW 때문에 연결이 안 된다면, 방화벽 전체를 끄기보다 해당 포트만 여는 편이 낫습니다. sudo ufw allow 8080/tcp로 허용하고 다른 네트워크에서 접속을 시험합니다. SSH가 기본 포트가 아니라면 재활성화 전에 현재 SSH 포트가 허용돼 있는지 반드시 확인합니다. sudo ufw status numbered로 규칙 목록을 다시 보는 데 몇 초면 충분합니다.
Rocky Linux와 RHEL 계열에서 firewalld 끄기
firewalld를 쓰는 서버에서는 sudo firewall-cmd --state로 실행 여부를 확인합니다. 지금 중지하려면 sudo systemctl stop firewalld, 재부팅 후에도 자동으로 시작하지 않게 하려면 sudo systemctl disable firewalld를 실행합니다. stop은 현재 상태를 바꾸고 disable은 부팅 설정을 바꿉니다. 두 명령의 역할이 다르므로 한쪽만 실행하고 영구히 꺼졌다고 생각하면 안 됩니다.
확인은 sudo systemctl is-active firewalld와 sudo systemctl is-enabled firewalld로 합니다. 다시 사용할 때는 sudo systemctl enable --now firewalld를 실행합니다. 다만 재시작 전에 현재 SSH 포트와 필요한 서비스가 허용돼 있는지 확인해야 합니다. firewalld에는 즉시 적용되는 설정과 재시작 후에도 남는 설정이 따로 있습니다. 임시로 연 포트가 재시작 뒤 닫히는 이유가 대개 여기에 있습니다.
특정 포트만 문제라면 활성 영역을 sudo firewall-cmd --get-active-zones로 확인한 뒤 해당 영역에 허용 규칙을 추가하는 편이 안전합니다. 예를 들어 기본 영역에 8080번 TCP 포트를 영구 허용하려면 sudo firewall-cmd --permanent --add-port=8080/tcp를 실행하고 sudo firewall-cmd --reload로 반영합니다. 인터페이스가 다른 영역에 속했다면 그 영역을 명시해야 합니다.
방화벽을 껐는데도 접속되지 않는 경우
VPS와 클라우드 서버에는 서버 안의 방화벽 말고도 보안그룹, 네트워크 ACL, 제공 업체의 방화벽이 있을 수 있습니다. 호스트 방화벽을 껐는데 외부 접속이 그대로 막힌다면 이 설정과 서비스의 대기 주소를 확인합니다. 서비스가 127.0.0.1에서만 대기하면 외부 방화벽을 열어도 접속할 수 없습니다. 반대로 0.0.0.0이나 IPv6 전체 주소에서 대기한다면 예상보다 넓은 범위에 노출될 수 있습니다.
nftables 규칙을 직접 관리하는 서버라면 sudo nft list ruleset으로 현재 규칙을 확인합니다. sudo nft flush ruleset은 전체 규칙을 지우므로 운영 서버에서 단순 진단용으로 실행하기에는 범위가 큽니다. UFW나 firewalld가 규칙을 관리 중인 서버에서 직접 비우면 관리 도구의 상태와 실제 규칙이 어긋날 수도 있습니다. 어느 서비스가 규칙을 만드는지 확인한 뒤 그 서비스의 설정을 수정하는 편이 낫습니다.
저는 장애를 볼 때 포트 대기 상태, 호스트 규칙, 외부 네트워크 규칙 순서로 확인합니다. 이 순서면 방화벽을 끄지 않고도 막힌 위치를 찾는 경우가 많습니다. 잠깐 꺼서 원인을 확인했다면 필요한 포트만 허용하고 다시 켠 뒤, 다른 네트워크에서 접속까지 확인해야 작업이 끝납니다.
