실수 한 줄로 사이트가 30분간 죽었다 — ufw 방화벽 사태 복기

운영 중인 사이트가 죽는 순간은 언제든 온다. 다만 보통은 코드가 죽거나 디스크가 차거나 뭔가가 터진다. 그런데 이번에는 그 아무것도 아니었다. 나는 그저 터미널에 ufw enable이라고 쳤을 뿐이다.

시작: 틸릭스에서 접속하려는데

어느 저녁, 메인사이트 서버에 접속하려고 틸릭스 터미널을 열었다. 평소처럼 SSH를 쳤는데 연결이 끊겼다. 다시 시도해도 끊겼다. 뭐 서버가 바쁘나보다 하고 넘기려는데, 사이트 자체도 열리지 않았다.

cursorai.co.kr도 aidebatehub.com도 동시다발로 죽어 있었다. 게임사이트 서버(.92)로 메인사이트 서버(.90)에 접근해도 timeout. 다른 망, 다른 IP, 다른 장비 — 어디서 시도해도 같은 결과였다.

진단: ping은 되는데 TCP가 안 된다

여기서부터가 본격적인 진단이었다.

가장 먼저 확인한 건 ping이었다. 그런데 ping은 정상이었다. RTT 10ms, 패킷 손실 0%. 그러면 네트워크 자체는 살아 있다는 뜻이다. 그런데 SSH(22번), HTTP(80번), HTTPS(443번) — 전부 timeout이었다.

포트를 하나씩 스캔해봤다. 21번부터 27017번까지 43개 포트를 훑었는데 하나도 열려 있지 않았다. ICMP만 허용하고 TCP는 전부 막는 상태. 이건 소프트웨어가 아니라 방화벽이 하는 짓이었다.

mtr로 경로를 추적해봤다. 목적지 홉에서 100% 손실. 즉, 서버 앞 어딘가에서 이미 끊기고 있었다.

원인: ufw

서버에 뭔가 설정을 만진 기억을 더듬었다. 그리고 찾아냈다. 바로 그 전날, 방화벽을 켜려고 ufw를 실행한 기억이었다.

ufw enable ufw default deny

이 두 줄이 전부였다. ufw는 리눅스 기본 방화벽 도구인데, default deny는 TCP 전부를 차단하고 ICMP(ping)만 남기는 정책이다. SSH도, HTTP도, HTTPS도 전부 막힌다. 그리고 나는 이걸 설정한 다음 잊어버렸다.

문제는 여기서 끝이 아니었다. 이 서버는 스냅샷도 백업도 없는 신생 호스팅 yourit 위에서 돌아가고 있었다. 실수로 무언가를 망치면 스스로 되돌릴 방법이 없었다.

해결: 고객센터와 콘솔

즉시 yourit 고객센터에 문의했다. 상황을 설명하고 ufw 관련 설정을 확인해달라고 요청했다. 그리고 고객센터에서 서버 콘솔에 직접 접속해 ufw를 비활성화시켜 주었다.

SSH가 다시 열렸다. 사이트가 다시 열렸다. 30분 정도 걸린 것 같다.

복구 직후, 양쪽 서버(.90 메인, .92 게임)에서 ufw를 완전히 제거했다. apt purge로 패키지 자체를 날려버렸다. 방화벽이 필요하면 iptables나 호스팅사 방화벽을 쓰지, ufw는 두 번 다시 쓰지 않기로 했다.

교훈 세 가지

첫째, 방화벽 변경은 언제든 사이트를 죽일 수 있다. ufw enable 하나로 포트 전체가 막힌다. SSH가 막히면 스스로 복구할 방법이 없다. 반드시 콘솔 접근 경로를 확보한 뒤에 설정해야 한다.

둘째, 스냅샷 없는 호스팅에서 작업할 때는 더 조심해야 한다. yourit은 신생 업체라 스냅샷 기능이 없었다. 실수하면 초기화뿐이었다. 대형 호스팅이라면 실수한 순간으로 돌아갈 수 있지만, 여기서는 그게 불가능했다.

셋째, 백업은 장비가 아니라 사람 손에 있어야 한다. 매일 백업을 로컬로 끌어오고 있었다. 그게 없었다면 실수 한 줄이 데이터 손실로 이어졌을 수도 있다.

운영 중에는 실수가 잦다. 중요한 것은 실수를 안 하는 것이 아니라, 실수했을 때 얼마나 빨리 복구할 수 있느냐다. 그리고 그 복구 속도는 사전에 준비한 것들 — 콘솔 접근, 백업, 고객센터 — 에 따라 달라진다.

ufw는 두 번 다시 켜지 않는다.