1. 초기 요구사항

1. Initial Requirements

배경

Background

기존 VM(test-vm)은 default 네트워크에서 External IP와 포트를 열어두고 기능 테스트를 마친 서버였습니다. 기능적으로는 검증이 끝났지만, 보안이 취약한 상태로 운영할 수는 없었죠. 이제 프로젝트 전용 Private VPC로 네트워크를 이전하고 보안을 강화한 실제 프로덕션 환경이 필요한 상황이었습니다.

The existing VM (test-vm) in the default network had completed functional testing with open External IP and ports. While functionality was verified, it couldn't remain in production with weak security. It was time to migrate to a project-isolated Private VPC and set up a proper production environment with enhanced security.

처음에는 작업의 목표가 뚜렷하지 않았습니다. 막연하게 "이런 게 필요하겠지"라고 생각만 했었죠:

Initially, the goals weren't clear. I just vaguely thought "I probably need something like this":

• 기존 VM의 이미지를 복사
• Copy the image from existing VM
• Private VPC에 새 VM 생성
• Create new VM in Private VPC
• 기존 instance-group과 내부 통신
• Internal communication with existing instance-group
• Internal LB + External LB 구성
• Configure Internal LB + External LB

간단해 보였지만... 현실은 녹록지 않았습니다.

It seemed simple... but reality had other plans.

test-vm (default 네트워크, us-central1-f)
  → 이미지 생성 (test-vm-image)
  → 새 VM 생성 (production-vm, Private VPC, 500GB 표준 디스크)

test-vm (default network, us-central1-f)
  → Create image (test-vm-image)
  → Create new VM (production-vm, Private VPC, 500GB standard disk)

인스턴스 템플릿 생성 → MIG 생성 (production-mig)
  → 자동으로 인스턴스 1개 생성 (production-mig-xxxx)

Create instance template → Create MIG (production-mig)
  → Auto-created 1 instance (production-mig-xxxx)

문제 발견

Problems Found

• 단일 VM만 사용할 예정인데 MIG가 불필요
• MIG는 자동 확장/복구용인데 요구사항에 맞지 않음

• MIG unnecessary when only using a single VM
• MIG is for auto-scaling/recovery which doesn't fit requirements

생성 과정

Creation Process

Internal Backend Service (app-internal-backend)
  → MIG 연결
  → Forwarding Rule (10.x.x.x:80)

Internal Backend Service (app-internal-backend)
  → Connect MIG
  → Forwarding Rule (10.x.x.x:80)

문제 발견

Problems Found

• Private VPC 내부 통신은 방화벽 규칙(vpc-allow-internal-all)으로 이미 허용됨
• 10.0.0.0/8 대역 내 모든 TCP/UDP 포트 통신 가능
• 단일 VM이므로 내부 IP로 직접 통신하면 됨
• Internal LB는 여러 VM 간 트래픽 분산용인데 불필요

• Private VPC internal communication already allowed via firewall rules (vpc-allow-internal-all)
• All TCP/UDP ports accessible within 10.0.0.0/8 range
• Single VM can communicate directly via internal IP
• Internal LB for multi-VM traffic distribution is unnecessary

생성 과정

Creation Process

Health Check (app-health-check, TCP 80)
  → Backend Service (app-external-backend)
  → Unmanaged Instance Group (app-external-ig)
  → URL Map (app-external-lb)
  → HTTP Proxy (app-http-proxy)
  → Forwarding Rule (xxx.xxx.xxx.xxx:80)

문제 1: Health Check 실패

Problem 1: Health Check Failure

• 헬스 체크가 80 포트 확인 → 리버스 프록시는 443 포트만 외부 바인딩
• 해결: 헬스 체크를 443 포트로 변경 (app-health-check-443)

• Health check on port 80 → Reverse proxy only binds port 443 externally
• Solution: Changed health check to port 443 (app-health-check-443)

문제 2: HTTPS 추가 시도

Problem 2: HTTPS Addition Attempt

HTTPS Proxy 생성 시도
  → 기존 SSL 인증서 사용 시도

Attempted HTTPS Proxy creation
  → Tried using existing SSL certificate

근본적 문제

Fundamental Problem

• VM 내부에서 이미 SSL 자동 발급을 처리 중
• GCP HTTP(S) LB는 자체 SSL 인증서 필요
• SSL 이중 처리 불가: LB에서 SSL 종료하면 VM 내부 SSL 처리와 충돌

• VM already handles auto SSL certificate issuance internally
• GCP HTTP(S) LB requires its own SSL certificate
• Cannot have dual SSL handling: SSL termination at LB conflicts with VM's internal SSL processing

개념

Concept

• SSL Passthrough: LB가 암호화된 트래픽을 복호화하지 않고 그대로 전달
• VM 내부에서 SSL 처리 가능

• SSL Passthrough: LB forwards encrypted traffic without decryption
• VM handles SSL processing internally

생성 과정

Creation Process

고정 IP 생성 (app-external-ip, xxx.xxx.xxx.xxx)
  → TCP Backend Service (app-tcp-backend)
  → TCP Proxy (app-tcp-proxy)
  → Forwarding Rules (80, 443 포트)
  → DNS: api.example.com → xxx.xxx.xxx.xxx

Create static IP (app-external-ip, xxx.xxx.xxx.xxx)
  → TCP Backend Service (app-tcp-backend)
  → TCP Proxy (app-tcp-proxy)
  → Forwarding Rules (ports 80, 443)
  → DNS: api.example.com → xxx.xxx.xxx.xxx

문제 1: 리버스 프록시 80 포트 미바인딩

Problem 1: Reverse Proxy Port 80 Not Bound

reverse-proxy   80/tcp, 0.0.0.0:443->443/tcp

• 80 포트가 컨테이너 내부만 열림
• 해결: docker-compose에서 "80:80" 추가

• Port 80 only open inside container
• Solution: Added "80:80" in docker-compose

문제 2: 404 Page Not Found

Problem 2: 404 Page Not Found

• 리버스 프록시가 요청은 받았지만 라우팅 규칙 없음
• api.example.com 도메인에 대한 라우터 설정 필요

• Reverse proxy received request but no routing rules
• Router configuration needed for api.example.com domain

SSL 인증서 자동 발급(ACME HTTP-01 Challenge) 동작 방식

How Auto SSL Certificate Issuance (ACME HTTP-01 Challenge) Works

1. 리버스 프록시가 인증 기관에 인증서 요청
2. 인증 기관: "api.example.com/.well-known/acme-challenge/TOKEN 에 파일 올려"
3. 리버스 프록시: 해당 경로에 파일 생성
4. 인증 기관: api.example.com → DNS 조회 → xxx.xxx.xxx.xxx (TCP LB IP)
5. 인증 기관: xxx.xxx.xxx.xxx:80 으로 HTTP 요청
6. TCP LB: 요청을 VM(10.x.x.x)으로 전달
7. 리버스 프록시: 파일 응답
8. 인증 기관: 인증 성공 → 인증서 발급

1. Reverse proxy requests certificate from CA
2. CA: "Upload file to api.example.com/.well-known/acme-challenge/TOKEN"
3. Reverse proxy: Creates file at that path
4. CA: api.example.com → DNS lookup → xxx.xxx.xxx.xxx (TCP LB IP)
5. CA: HTTP request to xxx.xxx.xxx.xxx:80
6. TCP LB: Forwards request to VM (10.x.x.x)
7. Reverse proxy: Responds with file
8. CA: Verification success → Issue certificate

실제 문제

The Actual Problem

DNS: api.example.com → xxx.xxx.xxx.xxx (TCP LB)
인증 기관 → TCP LB → VM

DNS: api.example.com → xxx.xxx.xxx.xxx (TCP LB)
CA → TCP LB → VM

하지만:

However:

• TCP LB는 프록시 프로토콜 사용
• 인증 기관이 보는 IP: TCP LB IP
• 리버스 프록시가 보는 클라이언트 IP: TCP LB의 내부 IP
• 도메인 검증 실패 가능성 또는 네트워크 지연/타임아웃

• TCP LB uses proxy protocol
• IP seen by CA: TCP LB IP
• Client IP seen by reverse proxy: TCP LB's internal IP
• Possible domain verification failure or network latency/timeout

추가 문제:

Additional Problems:

• TCP LB 헬스 체크가 443 포트만 확인
• 인증 기관은 80 포트로 검증 시도
• 타이밍 이슈 발생 가능

• TCP LB health check only checks port 443
• CA attempts verification on port 80
• Possible timing issues

구성

Configuration

1. VM 외부 IP를 고정 IP로 승격
   - 임시 IP → 고정 IP (vm-static-ip)

2. DNS 직접 연결
   - api.example.com → VM 고정 IP (VM 직접)

3. VM 내부에서 직접 인증서 발급
   - 인증 기관 → api.example.com → VM IP
   - 리버스 프록시가 HTTP-01 Challenge 직접 처리
   - 인증서 자동 발급 성공

1. Promoted VM external IP to static IP
   - Ephemeral IP → Static IP (vm-static-ip)

2. Direct DNS connection
   - api.example.com → VM static IP (direct to VM)

3. Certificate issuance directly from VM
   - CA → api.example.com → VM IP
   - Reverse proxy handles HTTP-01 Challenge directly
   - Auto certificate issuance successful

왜 이게 작동하는가

Why This Works

SSL 인증서 검증 흐름:
1. DNS: api.example.com → VM 고정 IP (VM 직접)
2. 인증 기관 → VM IP:80 (중간 프록시 없음)
3. 리버스 프록시가 직접 응답
4. 인증서 발급 성공 ✅

SSL Certificate Verification Flow:
1. DNS: api.example.com → VM static IP (direct to VM)
2. CA → VM IP:80 (no intermediate proxy)
3. Reverse proxy responds directly
4. Certificate issuance successful ✅

요구사항

Requirements

• production-vm의 3000 포트는 내부 서버에서만 접근 가능해야 함
• 허용 대상: 내부 개발 서버들 (dev-server-1, dev-server-2)

• Port 3000 on production-vm should only be accessible from internal servers
• Allowed: Internal development servers (dev-server-1, dev-server-2)

문제 상황

Problem Situation

• 초기에는 80, 443 포트를 전체 공개(0.0.0.0/0)로 설정
• 3000 포트도 외부에서 접근 가능한 상태였음
• 특정 서버만 허용하려 했으나 외부 IP가 없는 문제 발견

• Initially, ports 80, 443 were publicly open (0.0.0.0/0)
• Port 3000 was also accessible from outside
• Tried to allow only specific servers but discovered no external IP issue

외부 통신 vs 내부 통신

External vs Internal Communication

외부 통신 (External IP 사용) - 문제 발생:

External Communication (Using External IP) - Problem:

dev-server-1 (내부 IP만 존재)
  → NAT Gateway (IP 변환)
  → 인터넷
  → production-vm (External IP)

문제점:
- 소스 IP가 NAT Gateway IP로 변경됨
- 특정 서버만 허용하는 방화벽 규칙 적용 불가

dev-server-1 (internal IP only)
  → NAT Gateway (IP translation)
  → Internet
  → production-vm (External IP)

Problems:
- Source IP changes to NAT Gateway IP
- Cannot apply firewall rules for specific servers

내부 통신 (Internal IP 사용) - 해결:

Internal Communication (Using Internal IP) - Solution:

dev-server-1 (10.x.x.2)
  → Private VPC 내부
  → production-vm (10.x.x.5)

장점:
- 소스 IP가 그대로 유지됨
- 방화벽 규칙으로 특정 IP만 허용 가능
- 외부 인터넷을 거치지 않아 더 안전하고 빠름

dev-server-1 (10.x.x.2)
  → Inside Private VPC
  → production-vm (10.x.x.5)

Advantages:
- Source IP preserved
- Firewall rules can allow specific IPs
- Safer and faster without going through external internet

해결 과정

Resolution Process

1. 서버 내부 IP 확인

1. Check Server Internal IPs

gcloud compute instances describe dev-server-1 \
  --format="value(networkInterfaces[0].networkIP)" \
  --zone=asia-northeast3-a
# 결과: 10.x.x.2

gcloud compute instances describe dev-server-2 \
  --format="value(networkInterfaces[0].networkIP)" \
  --zone=asia-northeast3-a
# 결과: 10.x.x.4

gcloud compute instances describe dev-server-1 \
  --format="value(networkInterfaces[0].networkIP)" \
  --zone=asia-northeast3-a
# Result: 10.x.x.2

gcloud compute instances describe dev-server-2 \
  --format="value(networkInterfaces[0].networkIP)" \
  --zone=asia-northeast3-a
# Result: 10.x.x.4

2. 3000 포트 전용 방화벽 규칙 생성

2. Create Firewall Rule for Port 3000

gcloud compute firewall-rules create allow-3000-from-dev \
  --direction=INGRESS \
  --priority=1000 \
  --network=private-vpc \
  --action=ALLOW \
  --rules=tcp:3000 \
  --source-ranges=10.x.x.2/32,10.x.x.4/32 \
  --target-tags=production

3. VM에 타겟 태그 추가

3. Add Target Tag to VM

gcloud compute instances add-tags production-vm \
  --tags=production \
  --zone=asia-northeast3-a

4. 기존 공개 방화벽 규칙 삭제

4. Delete Existing Public Firewall Rules

gcloud compute firewall-rules delete vpc-allow-http --quiet
gcloud compute firewall-rules delete vpc-allow-https --quiet

9. 각 LB가 실패한 이유 요약

9. Summary: Why Each LB Failed

10. 최종 아키텍처

10. Final Architecture

현재 구성

Current Configuration

인터넷
  ↓
api.example.com (DNS)
  ↓
VM 고정 외부 IP
  ↓
리버스 프록시 (80, 443 포트)
  ↓ (라우팅)
app-api (3000 포트)

Internet
  ↓
api.example.com (DNS)
  ↓
VM Static External IP
  ↓
Reverse Proxy (ports 80, 443)
  ↓ (routing)
app-api (port 3000)

방화벽 구성

Firewall Configuration

vpc-allow-ssh-iap: IAP 터널 → 22
vpc-allow-internal-all: 10.0.0.0/8 → 모든 포트
allow-3000-from-dev: 10.x.x.2/32, 10.x.x.4/32 → 3000 (특정 서버만)
allow-http-https: 0.0.0.0/0 → 80, 443 (외부 웹 트래픽)
allow-lb-health-check: LB 헬스체크 → 3000

vpc-allow-ssh-iap: IAP tunnel → 22
vpc-allow-internal-all: 10.0.0.0/8 → all ports
allow-3000-from-dev: 10.x.x.2/32, 10.x.x.4/32 → 3000 (specific servers only)
allow-http-https: 0.0.0.0/0 → 80, 443 (external web traffic)
allow-lb-health-check: LB health check → 3000

장점

Advantages

• 단순함: 불필요한 프록시 계층 없음
• 비용 절감: LB 비용 없음
• SSL 인증서 자동 발급: 리버스 프록시가 직접 인증서 발급
• 고정 IP: VM 재시작해도 IP 유지

• Simplicity: No unnecessary proxy layers
• Cost savings: No LB costs
• Auto SSL certificate issuance: Reverse proxy handles certificate directly
• Static IP: IP persists even after VM restart

단점

Disadvantages

• 단일 장애점: VM 다운 시 서비스 중단
• DDoS 보호 부족: Cloud Armor 사용 불가
• 확장성 제한: 트래픽 증가 시 수평 확장 어려움

• Single point of failure: Service interruption when VM goes down
• Lack of DDoS protection: Cannot use Cloud Armor
• Limited scalability: Difficult to scale horizontally with traffic increase

11. 교훈

11. Lessons Learned

결론: 단일 VM + 리버스 프록시 환경에서는 VM 외부 IP 직접 사용이 최선입니다!

Conclusion: For a single VM + reverse proxy environment, direct VM external IP is the best approach!