Oracle Cloud Free Tier에서 iptables -F 실행 후 SSH 완전 차단 사태 복구 실패 사례

1. 문제 발생 배경

Oracle Cloud Infrastructure(OCI) Free Tier 환경에서 Ubuntu 인스턴스를 운영 중이던 중, 서버 내의 iptables 방화벽 정책을 초기화하기 위해 다음 명령어를 실행했습니다.

sudo iptables -F

이 명령을 실행한 직후, SSH 연결이 끊겼고 다시는 접속이 되지 않았습니다.

2. 당시 질문 흐름

  • Node.js 앱은 정상적으로 0.0.0.0:8080 포트에서 리슨 중
  • UFW(방화벽)는 8080 허용으로 설정됨
  • 오라클 보안 목록(Security List)도 8080 포트 허용으로 설정됨
  • 그러나 외부 curl 및 내부 curl 모두 No route to host 발생
  • iptables 초기화 여부 확인 후 sudo iptables -F 실행 사실 인지

3. ChatGPT가 했던 설명 중 “틀리거나 오해 유발”한 부분

❌ 오해 유발: “Serial Console로 복구 가능”

GPT는 오라클 콘솔에서 Serial Console을 이용한 복구가 가능하다고 안내했지만, Oracle Free Tier에서는 Serial Console 기능이 제공되지 않습니다. 이는 GPT가 일반 유료 계정 기준으로 설명했기 때문이며, Free Tier 사용자에게는 해당되지 않습니다.

❌ 오해 유발: “부트 볼륨 분리하여 다른 인스턴스에 마운트 가능”

GPT는 ‘부트 볼륨을 분리해 다른 인스턴스에 붙여 복구하면 된다’고 했지만, Free Tier VM 인스턴스에서는 부트 볼륨 분리(Detach) 버튼이 아예 비활성화되어 있습니다. 실질적으로 GPT가 제시한 모든 복구 방법이 막혀 있는 상태였습니다.

✅ 정확했던 부분

  • iptables -F 가 SSH 접속을 포함한 모든 인바운드 트래픽을 차단한다는 설명
  • 프리티어에서 Serial Console이 없거나 제한적이라는 점을 뒤늦게 인지하고 인정
  • 결국 “복구 불가 → 인스턴스 삭제 후 재생성”이 유일한 대안임을 정리

4. 최종 결론

Oracle Free Tier에서는 iptables -F 명령 한 줄만으로도 완전히 접속 불가 상태가 될 수 있으며,
이후에는 Serial Console, 부트 볼륨 마운트, NSG 설정 등 어떠한 방법으로도 복구가 불가능합니다.
따라서 해당 상태가 되면 인스턴스를 삭제하고 새로 생성하는 것이 유일한 해법입니다.

5. 방지 전략

# SSH 연결 보장 후 iptables 설정
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -F     # ← 이건 맨 나중에 할 것

또는 UFW를 사용해 다음처럼 안전하게 설정하는 것이 좋습니다.

sudo ufw allow ssh
sudo ufw allow 8080
sudo ufw enable

6. 결론

Oracle Cloud Free Tier는 비용이 들지 않는 대신, 시스템 복구용 접근 수단이 극도로 제한적입니다. iptablesfirewalld 조작 전에는 반드시 SSH 예외를 추가한 후 작업해야 하며, 그렇지 않을 경우 하드 삭제 외에는 방법이 없는 치명적 상황에 처할 수 있습니다.

관련 글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다