[OpenStack] OpenStack Floating IP 연결 문제 해결: 보안 그룹 디버깅

목차

• 1. 왜 Floating IP는 붙었는데 접속이 안 될까요?
• 2. 개념부터 정리: Security Group과 Floating IP의 관계
• 3. 먼저 확인할 체크리스트: 문제를 좁히는 순서
• 4. 실전 구현: CLI로 보안 그룹 디버깅하기
• 4-1. Floating IP 연결 상태 확인
• 4-2. 인스턴스 포트와 보안 그룹 확인
• 4-3. 보안 그룹 규칙 점검
• 4-4. 인스턴스 내부에서도 확인
• 5. 자주 만나는 OpenStack 네트워크 오류 패턴
• 5-1. default 보안 그룹만 붙어 있는 경우
• 5-2. IPv4 규칙은 있는데 잘못된 원격 대역으로 제한한 경우
• 5-3. Egress 규칙 누락
• 5-4. 인스턴스 내부 default route 문제
• 5-5. SSH 데몬 미기동 또는 이미지 자체 문제
• 6. 제가 쓰는 추천 점검 순서: 최소 삽질 루틴
• 7. 검증: 수정 후 무엇을 확인해야 할까?
• 8. ⚠️ 운영 환경에서 특히 주의할 점
• 9. 정리 및 FAQ
• 자주 묻는 질문

[OpenStack] Floating IP 연결 문제 해결: 보안 그룹 디버깅

OpenStack Floating IP 연결 문제 때문에 VM(가상 머신)은 멀쩡히 떠 있는데 외부에서 SSH 하나 안 붙는 상황, 한 번쯤 겪어보셨을 겁니다. 저도 처음엔 라우터(router)나 네임스페이스(namespace)부터 의심했었는데, 막상 까보면 보안 그룹(Security Group, 가상 방화벽 정책)이 원인이었던 경우가 꽤 많았습니다. 특히 인스턴스 생성은 잘 되고 Floating IP 할당도 정상인데 ping은 안 되고 SSH도 timeout 나면, 이거 진짜 사람 멘탈 흔들리거든요. 오늘은 제가 홈랩과 테스트 환경에서 실제로 자주 확인하는 흐름 기준으로, OpenStack Floating IP 연결 문제를 어떻게 좁혀 가는지 정리해보겠습니다.

이 글은 단순히 명령어만 던지는 글은 아닙니다. 왜 막히는지, 어디서 확인해야 하는지, 그리고 보안 그룹 디버깅을 어떤 순서로 해야 삽질을 줄일 수 있는지에 집중해보겠습니다. 이전 글에서 다뤘던 Neutron(뉴트론, OpenStack 네트워크 서비스) 기본 구조를 알고 계시면 더 이해가 빠르고요, 다음 글에서는 router namespace 추적도 따로 다뤄볼 예정입니다.

OpenStack 네트워크에서 인스턴스, 포트, 라우터, Floating IP, 보안 그룹이 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

1. 왜 Floating IP는 붙었는데 접속이 안 될까요?

쉽게 말해 Floating IP는 공인 접근용 주소를 내부 인스턴스에 매핑하는 기능입니다. 그런데 주소만 연결됐다고 바로 통신이 되는 건 아닙니다. 실제 트래픽은 중간에 여러 단계를 통과하거든요.

• Floating IP가 인스턴스 포트(port)에 제대로 연결돼 있어야 합니다.
• 라우터가 외부 네트워크(external network)와 내부 서브넷(subnet)을 이어줘야 합니다.
• 인스턴스 내부 OS 방화벽도 열려 있어야 합니다.
• 그리고 가장 자주 놓치는 게 보안 그룹(Security Group)입니다.

여기서 중요한 포인트! OpenStack 보안 그룹은 AWS 보안 그룹과 비슷하게 가상 NIC(네트워크 인터페이스) 앞단에서 동작하는 방화벽 개념으로 이해하면 편합니다. 즉, VM 안의 sshd가 떠 있어도 보안 그룹에서 막으면 외부에서는 그냥 응답이 없는 것처럼 보입니다.

2. 개념부터 정리: Security Group과 Floating IP의 관계

저도 처음엔 헷갈렸는데, Floating IP는 주소 매핑이고 Security Group은 트래픽 허용 정책입니다. 둘은 역할이 완전히 다릅니다. 쉽게 말해 집 주소는 알고 있는데 현관문이 잠겨 있는 상태라고 보시면 됩니다.

구성 요소	역할	문제 발생 시 증상
Floating IP	외부 IP를 내부 포트에 매핑	연결 대상 자체를 못 찾음
Router	내부망과 외부망 라우팅	외부 통신 경로 없음
Security Group	포트 단위 Ingress/Egress 제어	ping/SSH/HTTP가 timeout 또는 drop
Guest OS Firewall	인스턴스 내부 방화벽	OpenStack 설정은 정상인데 접속 실패

특히 Ingress(인그레스, 외부에서 들어오는 트래픽) 규칙이 빠져 있으면 SSH 22/tcp나 ICMP가 막힙니다. 반대로 Egress(이그레스, 외부로 나가는 트래픽)가 과하게 제한되어 있으면 응답 패킷이 못 나가서 통신이 이상하게 보일 수도 있습니다. OpenStack 네트워크 오류를 볼 때는 반드시 양방향 관점으로 봐야 합니다.

3. 먼저 확인할 체크리스트: 문제를 좁히는 순서

제가 직접 해보니 무작정 명령어부터 많이 치는 것보다, 확인 순서를 고정하는 게 훨씬 낫더라고요. 아래 순서대로 보면 대부분 원인을 빨리 찾습니다.

1. 인스턴스에 Floating IP가 정말 연결됐는지 확인합니다.
2. 해당 인스턴스 포트에 어떤 보안 그룹이 붙어 있는지 봅니다.
3. 보안 그룹 규칙에 SSH, ICMP, 필요한 서비스 포트가 있는지 확인합니다.
4. 인스턴스 내부에서 IP 주소와 default route가 정상인지 확인합니다.
5. Guest OS firewall(예: firewalld, ufw, iptables/nftables)도 봅니다.
6. 그래도 안 되면 라우터, 네트워크 네임스페이스, 포트 상태까지 내려갑니다.

이 순서를 지키면 OpenStack Floating IP 연결 문제를 네트워크 전체 장애로 오해하는 일을 꽤 줄일 수 있습니다.

4. 실전 구현: CLI로 보안 그룹 디버깅하기

이제 실제로 많이 쓰는 OpenStack CLI 기준으로 확인해보겠습니다. 환경마다 alias나 RC 파일은 다를 수 있으니, 먼저 인증 환경을 로드해 주세요.

4-1. Floating IP 연결 상태 확인

source admin-openrc

openstack server list
openstack floating ip list
openstack server show <SERVER_NAME_OR_ID>

여기서 제가 제일 먼저 보는 건 두 가지입니다. 하나는 Floating IP가 어느 포트에 연결됐는지, 다른 하나는 서버에 private IP와 mapped IP가 어떻게 보이는지입니다. 간혹 Floating IP는 생성됐는데 실제로 port association(포트 연결)이 안 된 경우도 있습니다.

openstack floating ip show <FLOATING_IP>

출력에서 확인할 포인트는 다음과 같습니다.

• Port 값이 비어 있지 않은지
• Fixed IP Address가 대상 인스턴스 IP와 일치하는지
• Status가 DOWN처럼 이상하지 않은지

4-2. 인스턴스 포트와 보안 그룹 확인

openstack port list --server <SERVER_NAME_OR_ID>
openstack port show <PORT_ID>

여기서 security_group_ids를 확인합니다. 생각보다 흔한 실수가, 인스턴스는 맞는데 기대한 보안 그룹이 아니라 default만 붙어 있는 경우입니다. 저도 예전에 Terraform 수정하다가 보안 그룹 연결이 빠져서 한참 헤맨 적이 있었네요. 이런 건 CLI로 보면 바로 드러납니다.

인스턴스 포트에 어떤 보안 그룹이 연결되고, 그 규칙이 Floating IP 트래픽에 어떻게 적용되는지 설명하는 구성 이미지입니다.

4-3. 보안 그룹 규칙 점검

openstack security group list
openstack security group show <SECURITY_GROUP_ID_OR_NAME>

SSH 접속 기준으로는 보통 아래 규칙이 필요합니다.

openstack security group rule create --protocol tcp --dst-port 22 <SECURITY_GROUP_ID>
openstack security group rule create --protocol icmp <SECURITY_GROUP_ID>

운영 환경이라면 0.0.0.0/0 전체 허용보다는 remote IP prefix(원격 IP 대역 제한)를 걸어두는 게 좋습니다.

openstack security group rule create \
  --protocol tcp \
  --dst-port 22 \
  --remote-ip 203.0.113.10/32 \
  <SECURITY_GROUP_ID>

여기서 중요한 포인트! Ping이 안 된다고 해서 무조건 네트워크 전체가 죽은 건 아닙니다. ICMP 규칙이 없어서 ping만 실패하고, SSH는 되는 경우도 있고 그 반대도 있습니다. 그래서 테스트는 항상 protocol별로 따로 봐야 합니다.

4-4. 인스턴스 내부에서도 확인

보안 그룹만 열어놓고 끝이 아니더라고요. 게스트 OS 쪽도 같이 봐야 합니다.

ip addr
ip route
ss -tulpn | grep :22
sudo systemctl status sshd
sudo firewall-cmd --list-all
sudo ufw status

배포판에 따라 `sshd` 서비스명이나 방화벽 도구는 다를 수 있습니다. 핵심은 서비스가 실제로 떠 있는지, 그리고 OS 방화벽이 22/tcp를 막고 있지 않은지입니다.

5. 자주 만나는 OpenStack 네트워크 오류 패턴

이 섹션은 진짜 실전용입니다. 제가 실제로 써보니까 아래 패턴들이 반복해서 나오더라고요. OpenStack 쪽 문제처럼 보여도 원인은 의외로 단순한 경우가 많습니다.

5-1. default 보안 그룹만 붙어 있는 경우

가장 흔합니다. 인스턴스 생성할 때 별도 보안 그룹 지정이 빠지면 default만 달리는데, 이 default 정책이 환경에 따라 거의 비어 있거나 내부 통신 위주일 수 있습니다. 그러면 Floating IP 오류처럼 보이지만 사실은 허용 규칙 부재입니다.

5-2. IPv4 규칙은 있는데 잘못된 원격 대역으로 제한한 경우

예를 들어 사무실 공인 IP만 허용해뒀는데, VPN을 안 켜고 집에서 접속하면 당연히 안 됩니다. 근데 현장에서는 이걸 잊고 라우터 문제부터 의심하게 되거든요. 저도 몇 번 당했습니다 ㅎㅎ

5-3. Egress 규칙 누락

대부분 Ingress만 보는데, 보안 정책을 엄격하게 운영하는 환경에서는 Egress도 제한합니다. 이 경우 SYN은 들어왔는데 응답이 못 나가서 연결이 묘하게 실패할 수 있습니다.

5-4. 인스턴스 내부 default route 문제

DHCP가 꼬였거나 cloud-init 설정이 예상과 다르면, VM 내부 게이트웨이 경로가 어긋나기도 합니다. 그러면 보안 그룹을 아무리 열어도 답이 안 나옵니다.

5-5. SSH 데몬 미기동 또는 이미지 자체 문제

간단하지만 놓치기 쉽습니다. 이미지 빌드 과정에서 `sshd` 설정이 바뀌었거나, cloud-init 키 주입이 실패해서 인증 단계에서 막힐 수도 있습니다. 그래서 네트워크 계층과 서비스 계층을 같이 봐야 합니다.

6. 제가 쓰는 추천 점검 순서: 최소 삽질 루틴

혹시 이런 경험 있으신가요? 원인이 여러 군데일 수 있으니 한 번에 다 건드리다가 더 꼬이는 상황이요. 저는 그래서 아래 루틴으로 고정해두고 봅니다.

1. `openstack floating ip show`로 실제 연결 포트를 확인합니다.
2. `openstack port show`로 보안 그룹 부착 상태를 확인합니다.
3. `openstack security group show`로 SSH/ICMP 규칙 유무를 봅니다.
4. 필요하면 임시로 테스트 규칙을 넣고 재시도합니다.
5. 안 되면 VM 콘솔 접속으로 내부 IP, route, sshd 상태를 봅니다.
6. 마지막으로 라우터와 네트워크 노드 쪽을 의심합니다.

이 루틴의 장점은, 원인을 주소 매핑 문제, 정책 문제, 게스트 OS 문제로 나눠서 볼 수 있다는 점입니다. 문제를 범주화하면 훨씬 덜 흔들립니다.

Floating IP 확인부터 보안 그룹, 인스턴스 내부 점검까지 이어지는 트러블슈팅 순서를 시각적으로 정리한 이미지입니다.

7. 검증: 수정 후 무엇을 확인해야 할까?

보안 그룹 수정 후에는 단순히 “붙었다”에서 끝내지 말고, 최소한 아래는 검증해보는 게 좋습니다.

• 관리용 PC에서 `ping` 또는 `ssh`가 즉시 응답하는지
• 인스턴스에서 외부로 `curl` 또는 `ping`이 가능한지
• 필요한 서비스 포트만 열려 있는지
• 너무 넓은 허용 대역이 남아 있지 않은지

ping <FLOATING_IP>
ssh -i ~/.ssh/mykey ubuntu@<FLOATING_IP>
curl -I http://<FLOATING_IP>

드디어 됐다! 이 순간이 은근 기분 좋죠. 다만 여기서 끝내면 안 됩니다. 테스트용으로 열어둔 `0.0.0.0/0` 규칙이 있다면 반드시 운영 기준에 맞게 다시 조여야 합니다.

검증 항목	성공 기준	추가 조치
Ping(ICMP)	응답 수신	운영 정책상 불필요하면 비활성화 검토
SSH 22/tcp	로그인 프롬프트 도달	접근 IP 제한 적용
웹 포트 80/443	HTTP/HTTPS 응답	로드밸런서 사용 여부 점검
Egress 통신	패키지 저장소/외부 API 접근 가능	최소 허용 정책 재정리

보안 그룹 수정 후 SSH 접속 성공, 포트 응답 확인, 네트워크 상태 검증이 완료된 모습을 표현한 결과 이미지입니다.

8. ⚠️ 운영 환경에서 특히 주의할 점

보안 그룹 디버깅 하다 보면 급한 마음에 전체 오픈으로 먼저 뚫고 싶어집니다. 저도 장애 상황에서 그렇게 했던 적이 있습니다. 근데 이건 정말 임시 확인용으로만 쓰셔야 합니다.

• 0.0.0.0/0 전체 허용은 테스트 후 반드시 회수합니다.
• 여러 보안 그룹을 중복 적용했다면 실제 허용 범위를 다시 검토합니다.
• 자동화 도구(Terraform, Heat, Ansible)와 수동 변경이 섞이면 drift(구성 불일치)가 생깁니다.
• 운영 정책상 ICMP 차단이 정상일 수도 있으니 ping 실패만으로 장애 판단하면 안 됩니다.

사실 실무에서는 “왜 안 되지?”보다 “어디까지는 정상인가?”를 구분하는 게 더 중요합니다. 예를 들어 ping은 막혀도 SSH는 정상일 수 있고, SSH는 되는데 애플리케이션 포트만 안 열려 있을 수도 있거든요.

9. 정리 및 FAQ

OpenStack Floating IP 연결 문제는 겉으로 보기엔 복잡해 보여도, 실제로는 Floating IP 연결 여부, 보안 그룹 규칙, 인스턴스 내부 네트워크와 서비스 상태 이 세 축으로 나눠 보면 꽤 빨리 풀립니다. 제가 여러 번 삽질해보니, 가장 먼저 봐야 할 건 역시 보안 그룹이었습니다. 주소는 붙었는데 정책이 막고 있는 경우가 정말 많더라고요.

처음엔 이게 뭔가 싶었는데, 디버깅 순서만 몸에 익으면 OpenStack 네트워크 오류도 덜 무섭습니다. 다음 글에서는 `router`, `qrouter namespace`, `SNAT/DNAT` 흐름까지 조금 더 깊게 들어가보겠습니다. 이전 글 참고하셨다면 오늘 내용이 훨씬 입체적으로 보이실 거예요.

자주 묻는 질문

• Q. Floating IP가 붙어 있는데 ping이 안 됩니다.
  A. ICMP Ingress 규칙이 없을 수 있습니다. 다만 운영 정책상 ping 차단이 정상일 수도 있으니 SSH나 서비스 포트도 함께 확인해보세요.
• Q. SSH만 안 됩니다.
  A. 보안 그룹의 22/tcp 규칙, 원격 IP 제한, 인스턴스 내부 `sshd` 상태를 순서대로 보시면 됩니다.
• Q. 보안 그룹은 맞는데 여전히 안 됩니다.
  A. 인스턴스 내부 route, guest OS firewall, 라우터 연결 상태까지 내려가야 합니다.

OpenStack Floating IP 연결 문제를 해결할 때 확인해야 할 핵심 체크포인트를 한 장으로 요약한 인포그래픽 이미지입니다.

📚 함께 읽으면 좋은 글

• OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략
• OpenStack Designate 마이그레이션: 기존 DNS 연동 전략
• OpenStack Placement 벤치마크: 대규모 자원 할당 성능 분석