본문 바로가기
NETWORK

VPN 연결 상태에서 Public DNS로 Internal ALB에 접근 가능한 이유

by Rainbound-IT 2025. 12. 30.
반응형

— DNS 해석과 네트워크 라우팅은 완전히 다른 계층이다

많은 사람들이 이렇게 생각한다.

“Internal ALB는 VPC 내부 리소스인데,

DNS를 1.1.1.1 같은 Public DNS로 쓰면 접근이 안 되는 거 아닌가?”

결론부터 말하면

👉 DNS가 퍼블릭이든 내부든 상관없이,

VPN으로 네트워크 경로만 열려 있으면 Internal ALB 접근은 가능하다.

이유는 간단하다.

DNS는 ‘주소를 알려줄 뿐’이고, 실제로 접근 가능 여부는 전부 네트워크 라우팅이 결정한다.

아래에서 그 과정을 단계별로 뜯어보자.


1. VPN 연결이 만들어내는 진짜 변화는 “DNS”가 아니다

VPN에 연결하면 가장 중요한 변화는 이것이다.

  • 내 PC에 새 네트워크 인터페이스(VPN 인터페이스) 가 생긴다
  • 라우팅 테이블에 이런 규칙이 추가된다
10.0.0.0/16 → VPN 인터페이스

즉,

“이제부터 10.0.0.0/16(= AWS VPC)로 가는 패킷은 인터넷 말고 VPN으로 보내라”

이게 전부다.

DNS 설정이 뭐든 간에,

패킷이 갈 수 있는 ‘길’이 열렸다는 게 핵심이다.


2. Public DNS(1.1.1.1)는 Internal ALB를 어떻게 해석할까?

이제 브라우저에서 이런 요청을 한다고 해보자.

<https://internal-api.company.com>

(1) DNS 질의 발생

PC는 설정된 DNS 서버(예: 1.1.1.1)로 질의한다.

internal-api.company.com → ?

(2) Public DNS의 역할은 딱 여기까지

Public DNS는 이렇게 응답한다.

  • CNAME → internal-xxx.ap-northeast-2.elb.amazonaws.com
  • 또는 최종적으로 사설 IP (10.x.x.x)

중요한 포인트:

Public DNS는 “이 IP가 내부인지 외부인지 신경 쓰지 않는다.”

그냥 레코드에 적힌 값을 그대로 반환할 뿐이다.

즉,

  • 10.0.3.15 같은 사설 IP가 나와도
  • DNS는 아무 문제 없이 정상 응답한다

3. 결정적인 순간: DNS 이후에 벌어지는 일

DNS 해석이 끝나면, 이제 OS는 이렇게 생각한다.

“좋아, 목적지는 10.0.3.15구나.

그럼 이 IP로 TCP 연결을 시도해보자.”

이때 운명을 가르는 건 라우팅 테이블이다.

VPN이 없는 경우

10.0.3.15 → 기본 게이트웨이(인터넷) → ❌ 도달 불가

VPN이 있는 경우

10.0.3.15 → VPN 인터페이스 → AWS VPC →Internal ALB

👉 여기서 처음으로 “아, VPN이 있어서 되네”가 성립한다

DNS는 이미 끝난 일이고,

실제 접근 가능 여부는 이 라우팅에서 결정된다.


4. Internal ALB 입장에서 보면 무슨 일이 일어날까?

Internal ALB는 이런 상황을 보고 있다.

  • 출발지 IP: VPN 클라이언트 대역 (예: 10.100.0.10)
  • 목적지 IP: ALB의 사설 IP
  • 요청 포트: 443

ALB는 단순히 이렇게 판단한다.

“이건 VPC 내부에서 들어온 정상 트래픽이네?”

그래서:

  • 보안그룹에서 VPN 대역이 허용돼 있고
  • 리스너/타겟 그룹이 정상이라면

👉 아무 문제 없이 요청을 처리한다

ALB는

  • “DNS가 어디서 해석됐는지”
  • “Public DNS를 썼는지”

전혀 모른다. 알 수도 없고, 신경도 안 쓴다.


5. 이 구조가 가능한 이유를 한 문장으로 정리하면

DNS는 “이름 → IP”만 담당하고, Internal / External을 구분하는 건 오직 네트워크 라우팅이다.

그래서 아래 조합도 가능하다.

 

요소  상태
DNS 1.1.1.1 (Public)
ALB Internal
접근 가능
조건 VPN 라우팅 + 보안그룹 OK

6. 많은 사람들이 헷갈리는 지점들

❌ “Internal ALB는 Public DNS로는 해석 안 된다”

→ 틀림

✔ 해석은 된다. 접속이 안 될 뿐 (VPN 없으면)

❌ “DNS가 퍼블릭이면 내부 리소스 접근은 불가”

→ 틀림

✔ DNS와 네트워크 접근성은 완전히 다른 문제

❌ “이건 우연히 되는 구조다”

→ 틀림

하이브리드 / 멀티클라우드 환경에서 의도적으로 쓰이는 구조


7. 그럼에도 실무에서 Split DNS를 쓰는 이유

이 구조가 가능하다고 해서 항상 좋은 건 아니다.

실무에서는 보통:

  • 내부 도메인은 내부 DNS
  • 외부 도메인은 외부 DNS

Split-horizon DNS를 쓴다.

이유는:

  • 보안 (내부 주소 노출 방지)
  • 장애 분석 용이성
  • VPN 미연결 상태에서의 오동작 방지

하지만 원리적으로는

Public DNS + VPN 라우팅만으로도 Internal ALB 접근은 충분히 가능하다.

반응형

댓글