리눅스 방화벽 테스트 방법을 현장에서 쓰려면

얼마 전 웹서버 이전 작업에서 443 포트가 열려 있다는 보고를 받았는데, 실제 외부 접속은 계속 실패했다. 서버 안에서 접속해 본 결과만으로 방화벽을 통과했다고 판단한 게 원인이었다. 리눅스 방화벽 테스트 방법은 서버의 서비스 상태, 서버 안의 규칙, 외부에서 들어오는 경로를 나눠 확인해야 헷갈리지 않는다.

먼저 서비스가 포트를 듣고 있는지 확인한다

방화벽을 보기 전에 서버에서 sudo ss -lntup을 실행한다. LISTEN 항목에 대상 포트가 없다면 방화벽을 열어도 접속되지 않는다. 웹서비스가 443 포트를 쓴다면 해당 프로세스가 443에서 대기하는지 확인한다. 127.0.0.1에만 묶여 있으면 서버 내부 접속은 되지만 외부 접속은 안 된다. 외부 요청을 받아야 하는 서비스라면 공인 IP나 0.0.0.0 또는 적절한 IPv6 주소에서 대기해야 한다.

여기서 한 가지 더 본다. 애플리케이션이 죽어서 포트가 닫힌 것인지, 정상 실행 중인데 다른 포트에서 대기하는 것인지다. 프로세스 설정과 실제 LISTEN 결과가 다르면 서비스 설정부터 고쳐야 한다. 방화벽 규칙을 계속 추가하면 원인만 가려진다.

서버 방화벽 규칙은 적용된 상태로 읽는다

리눅스 배포판과 운영 방식에 따라 확인 명령이 다르다. nftables를 직접 쓴다면 sudo nft list ruleset, UFW를 쓴다면 sudo ufw status verbose, firewalld를 쓴다면 sudo firewall-cmd --list-all을 확인한다. firewalld는 현재 활성 구역과 네트워크 인터페이스의 연결도 함께 봐야 한다. 다른 구역에 포트를 허용해 놓으면 실제 트래픽에는 적용되지 않는다.

규칙을 읽을 때는 포트 번호만 찾지 않는다. 입력 방향인지, TCP와 UDP 중 어느 프로토콜인지, 허용할 출발지 IP 범위가 맞는지, 앞선 차단 규칙에 걸리지 않는지 순서대로 본다. 정책이 기본 차단이라면 허용 규칙이 빠진 것이고, 기본 허용이라면 별도 차단 규칙을 찾아야 한다. IPv4 규칙만 맞춰 놓고 IPv6 경로로 접속하는 경우도 자주 놓친다.

원격으로 작업 중이라면 현재 SSH 세션을 유지한 채 규칙을 바꾼다. 특히 기본 정책을 변경할 때는 관리용 포트의 허용 규칙이 먼저 적용됐는지 확인한다. 현장에서는 방화벽보다 복구할 접속 경로를 잃는 사고가 더 오래 간다.

외부 장비에서 접속을 시도해 경로를 확인한다

서버 안에서 자기 공인 IP로 접속하는 시험은 충분하지 않다. 같은 네트워크의 다른 장비나 별도 회선에서 nc -vz -w 3 서버공인IP 443을 실행한다. 성공하면 적어도 해당 위치에서 TCP 연결은 성립한 것이다. 연결 거부가 나오면 목적지까지 도달했지만 포트를 받아 줄 서비스가 없거나 거부하는 경우를 의심한다. 시간이 지나도 응답이 없다면 중간 경로의 차단, 서버 규칙, 잘못된 IP를 차례로 확인한다. 다만 응답 형태만으로 원인을 단정하지는 않는다.

여러 포트를 한 번에 점검해야 할 때는 외부 장비에서 nmap -Pn -p 22,443 서버공인IP처럼 범위를 좁혀 검사할 수 있다. 공개 서버에 검사를 반복하거나 넓은 포트 범위를 무작정 훑을 필요는 없다. 필요한 포트와 시험 출발지 IP를 기록해 두면 나중에 로그와 대조하기 쉽다.

클라우드 서버라면 서버 방화벽 밖에도 보안 그룹, 네트워크 방화벽, 로드 밸런서, 공급자의 상위 차단 정책이 있을 수 있다. 외부 연결이 실패하는데 서버 규칙이 정상이라면 이 경로를 확인한다. 반대로 서버에서 바로 접속은 되는데 서비스 주소로 들어올 때만 실패한다면 로드 밸런서의 연결 대상과 상태 점검 설정도 봐야 한다.

패킷이 어디까지 왔는지 보고 원인을 좁힌다

접속 결과가 애매하면 서버에서 sudo tcpdump -ni any 'tcp port 443'을 켜고 외부 장비에서 다시 연결한다. SYN 패킷이 전혀 보이지 않으면 서버 앞단의 경로, 공인 IP 연결, 상위 방화벽을 확인할 차례다. SYN은 들어오는데 응답이 없으면 서버 방화벽이나 커널 처리 경로를 본다. SYN에 대한 RST가 나가면 해당 주소와 포트에서 대기하는 서비스가 없는 경우가 흔하다. SYN과 SYN-ACK가 오가는데 클라이언트가 끝내 연결하지 못한다면 반환 경로도 살핀다.

UDP는 TCP처럼 연결 성공 여부를 단순하게 표시하기 어렵다. UDP 서비스를 점검할 때는 시험 요청을 보내면서 서버의 패킷 수신과 애플리케이션 로그를 같이 확인한다. 요청이 들어왔는지, 서비스가 응답을 만들었는지, 응답이 밖으로 나갔는지를 나눠 봐야 한다.

실무에서는 포트를 열기 전에 필요한 출발지와 포트를 적고, 변경 후에는 다른 네트워크에서 접속을 시험한다. 규칙과 접속 결과를 남겨 두면 다음 이전 작업이나 장애 때 같은 지점을 다시 추측할 필요가 없다. 싼 서버를 쓰더라도 이 확인 순서만 지키면 방화벽 문제를 훨씬 빨리 좁힐 수 있다.