ufw를 켰더니 이제 SSH가 연결이 안 됩니다. 서버가 날아간 건가요?

아니요. 서버는 멀쩡히 돌아가고 있습니다—그저 안에서 문을 잠근 것뿐입니다. 데이터는 온전합니다. 패널의 웹 콘솔을 열고(SSH 없이 들어갑니다) `sudo ufw disable`를 실행하면 다시 안으로 들어옵니다. 재설치할 필요 없습니다.

ufw를 켜니 왜 SSH가 끊겼나요?

ufw는 기본적으로 들어오는 모든 트래픽을 거부합니다. SSH 포트를 먼저 허용하지 않고 켜면 자신의 세션이 끊깁니다. 스스로를 가두는 가장 흔한 방식입니다. 항상 `ufw enable` 전에 `ufw allow `.

SSH로 아예 들어갈 수 없으면 ufw를 어떻게 고치나요?

패널의 대역 외(out-of-band) 웹 콘솔(시리얼 콘솔)을 쓰세요—SSH도, 애초에 네트워크 스택도 거치지 않아서 방화벽 규칙이 막을 수 없습니다. 로그인한 뒤 `sudo ufw disable`(가장 빠름), 또는 특정 규칙을 고치려면 `sudo ufw allow `.

NAT VPS에서는 ufw에 어떤 포트를 허용하나요?

외부 포트가 아니라 22를 허용하세요. NAT 요금제에서는 20266 같은 높은 포트로 접속하지만, 그것은 VM 내부의 포트 22로 포워딩됩니다. ufw는 VM 내부에서 돌며 22만 봅니다. 20266을 허용해도 소용없습니다—22를 허용하세요.

`ufw reset`이 `ufw disable`보다 안전한가요?

`disable`은 방화벽만 끄고 규칙은 보존합니다—가장 빠른 복귀 경로입니다. `reset`은 모든 규칙을 기본값으로 지웁니다. 복구에는 `disable`을 쓰고, 그다음 규칙을 신중히 다시 추가하세요. `reset`은 규칙 세트가 지워버리고 싶은 엉망일 때만.

ufw 때문에 내 VPS에서 잠겼다면? 재설치 없이 다시 들어가기

처음으로 자기 서버를 굴리는 사람에게는 일종의 통과의례가 있습니다. 방화벽을 세우기로 하고, ufw 명령 몇 줄을 치고, enable을 누른다—그러면 터미널이 조용해집니다. SSH가 사라졌습니다. 뭔가를 부순 것도, 해킹당한 것도 아닙니다. 그저 자신을 밖에 둔 채 문을 잠갔을 뿐입니다.

이건 실력 있는 관리자에게도 일어납니다. 지난주 바로 저희 고객 한 분에게 일어났고, 그래서 이렇게 적습니다. 좋은 소식: 1분도 안 걸려 완전히 복구되고, 재설치도 파일 하나 잃을 일도 없습니다. 방법은 이렇습니다.

방화벽 벽 뒤에 봉인된 서버, 돌아오는 길로서 빛나는 콘솔 창

실제로 무엇이 잘못됐나

ufw(Uncomplicated Firewall)는 기본적으로 들어오는 모든 것을 거부합니다. ufw enable을 실행하는 순간, 명시적으로 허용하지 않은 것은 전부 떨궈집니다—지금 당신이 앉아 있는 그 SSH 세션까지 포함해서요. SSH 포트를 먼저 ufw allow 하는 걸 잊었다면, 규칙이 발효되는 순간 자신의 연결을 끊은 셈입니다.

이게 전형입니다. 사람을 잡는 유형이 두 개 더 있습니다:

엉뚱한 포트를 허용했다. 오타이거나, 서비스 포트(가령 8080)를 허용하고 22를 잊었다.
22를 허용했지만 목록 위쪽에 그것을 가리는 deny 규칙을 뒀다. ufw는 순서에 민감합니다.

어느 쪽이든 서버 자체는 멀쩡합니다—돌아가고, 디스크는 온전하고, 앱도 벽 뒤에서 여전히 웅웅거립니다. 순전히 네트워크 접근의 문제입니다. 바로 그래서 고치기가 쉽습니다.

나쁜 수: 재설치

첫 충동은 흔히 "그럼 서버를 리셋하고 처음부터 하자"입니다. 하지 마세요—이 경우엔 아닙니다. 재설치는 멀쩡한 SSH를 되찾자고 전부를 지웁니다. 정작 SSH를 막고 있는 건 10초면 되돌리는 방화벽 명령 하나입니다. 현관문을 잠갔다고 집을 태워버리는 격입니다.

재설치가 옳은 건 백지를 원할 때입니다. ufw 잠김에는 소 잡는 칼입니다.

좋은 수: 웹 콘솔

쓸 만한 VPS라면 대역 외 콘솔을 줍니다—SSH도, 애초에 네트워크 스택도 거치지 않고 머신에 들어가는 길입니다. EQVPS에서는 서버 페이지의 Console 버튼이 그것입니다. 시리얼 콘솔이라 텍스트뿐이고, 모니터와 키보드처럼 VM에 곧바로 연결됩니다. 네트워크 트래픽이 아니므로 방화벽 규칙은 여기에 힘을 못 씁니다.

클릭하고, root 자격 증명으로 로그인하세요(수중에 없으면 패널에서 비밀번호를 드러내세요)—그러면 방화벽이 있든 없든 당신은 머신 안입니다.

이제 피해를 되돌립시다. 가장 빠른 길:

sudo ufw disable

이것은 방화벽을 끄되 규칙은 보존합니다. 그래서 실수를 바로잡은 뒤 다시 켤 수 있습니다. SSH는 즉시 돌아옵니다.

방화벽을 통째로 내리기 싫다면, 빠뜨린 포트만 여세요:

sudo ufw allow 22
sudo ufw status numbered

status numbered는 볼 만합니다: 규칙의 순서를 보여줍니다—"22를 허용했는데도 막힌다" 부류가 여기 숨어 있습니다. allow 위에 deny가 앉아 있으면 sudo ufw delete <번호>로 지우세요.

거의 어떤 가이드도 언급하지 않는 NAT의 함정

NAT 요금제라면 여기 함정이 있습니다. SSH에는 20266 같은 높은 포트로 들어가니, 자연스러운 직감은 ufw allow 20266입니다. 이건 아무 일도 하지 않습니다.

NAT에서 그 외부 포트는 VM 내부의 포트 22로 포워딩됩니다. ufw는 VM 내부에서 돌며 언제나 22만 봅니다. 그래서 정말로 필요한 규칙은:

sudo ufw allow 22

20266을 허용하면 여전히 깨진 연결을 바라보며 왜냐고 갸웃거리게 됩니다. 22를 허용하면 안으로 들어옵니다. 어떤 서비스든 같은 논리입니다: 밖에서 접속하는 포워딩된 포트가 아니라, 프로세스가 머신 내부에서 듣고 있는 포트를 허용하세요.

두 번 다시 이러지 않는 법

고치는 데 1분이지만, 아예 필요 없는 편이 낫습니다. 습관 둘:

켜기 전에 SSH 포트를 허용하세요. 항상 이 순서로:

sudo ufw allow 22
sudo ufw enable

거꾸로 하면 다시 콘솔행입니다.

방화벽 규칙을 바꾸는 동안 두 번째 SSH 세션을 열어두세요. 두 번 로그인하세요. 변경은 한 창에서; SSH가 죽어도 다른 창이 살아 있어 고칩니다. 오래된 요령이지만 매번 살려줍니다.

그리고 새 머신을 세우는 중이라면, 저희 새 VPS 보안 체크리스트가 ufw를 올바른 순서로—SSH 키, 그리고 첫 10분에 정말 중요한 몇 가지와 함께—다룹니다.

정리

ufw 잠김은 무서워 보이지만 사실 거의 아무것도 아닙니다. 서버는 한 번도 떠난 적이 없습니다. 필요한 건 어떤 방화벽도 닫지 못하는 문—웹 콘솔—과 명령 하나뿐입니다. ufw disable과 콘솔을 주머니에 넣어두고, 다음번엔 켜기 전에 포트를 허용하세요. 그러면 이 일로 두 번 다시 진땀 흘릴 일은 없습니다.