DNS는 AWS 클라이언트 VPN 엔드포인트와 어떻게 작동하나요?

해결 방법

**참고:**AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하는 경우 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

새 클라이언트 VPN 엔드포인트를 생성할 때 DNS 서버 IP 주소를 지정합니다. AWS Management Console, create-client-vpn-endpoint AWS CLI 명령이나 CreateClientVpnEndpoint API를 생성해 “DNS 서버 IP 주소” 파라미터에 IP 주소를 지정합니다. 또는 기존 클라이언트 VPN 엔드포인트를 수정하세요. AWS Management Console, modify-client-vpn-endpoint AWS CLI 명령이나 ModifyClientVpnEndpoint API를 사용해 “DNS 서버 IP 주소”를 수정하세요.

“DNS 서버 IP 주소” 파라미터 구성

가용성을 높게 유지하기 위해서는 DNS 서버를 2개 지정하는 것이 좋습니다. 기본 DNS 서버에 연결이 되지 않을 때 최종 사용자 장치에서 쿼리를 보조 DNS 서버로 다시 보냅니다.

참고: 기본 DNS 서버가 SERVFAIL로 응답할 경우에는 DNS 요청을 보조 DNS 서버로 다시 전송하지 않습니다.

최종 사용자가 클라이언트 VPN 엔드포인트에 연결한 후 지정된 DNS 서버에도 연결할 수 있는지 확인합니다. DNS 서버에 연결이 안되는 경우 DNS 요청이 실패해 연결 문제가 발생할 수 있습니다.

“DNS 서버 IP 주소” 파라미터는 선택 사항입니다. DNS 서버가 지정되어 있지 않으면 최종 사용자 장치에 구성된 DNS IP 주소를 사용해 DNS 쿼리를 해결합니다.

클라이언트 VPN DNS 서버가 AmazonProvidedDNS나 Amazon Route 53 Resolver 인바운드 엔드포인트인 경우 다음 지침을 따르세요.

• Virtual Private Cloud(VPC)와 연결된 Route 53 프라이빗 호스팅 영역의 리소스 레코드를 확인할 수 있습니다.
• “프라이빗 DNS”가 활성화되면 VPN 인터페이스 지정 과정에서 액세스할 수 있는 Amazon RDS 공용 호스트 이름이 프라이빗 IP 주소로 확인됩니다. 이는 VPC 인터페이스 엔드포인트에서 액세스할 수 있는 AWS 서비스 엔드포인트 이름의 경우에도 마찬가지입니다.
  참고: 연결된 VPC에 “DNS 확인” 및 “DNS 호스트 이름”이 활성화되어 있는지 확인하세요.

클라이언트 VPN 엔드포인트에서는 소스 NAT를 사용해 연결된 VPC의 리소스에 연결합니다.

클라이언트 장치가 클라이언트 VPN 터널을 만들면 “DNS 서버 IP 주소” 파라미터가 전체 터널이나 분할 터널에 적용됩니다.

• 전체 터널: 클라이언트 장치가 터널을 만든 후, 최종 사용자 장치의 라우팅 테이블에 VPN 터널을 통과하는 모든 트래픽의 경로가 추가됩니다. 그러면 DNS 트래픽을 포함한 모든 트래픽이 클라이언트 VPN 터널을 통해 라우팅됩니다. 연결된 VPC에 DNS 서버로 가는 경로가 없는 경우 조회가 실패합니다.
• 분할 터널: 클라이언트 VPN 터널이 생성되면 최종 사용자 장치의 라우팅 테이블에 클라이언트 VPN 라우팅 테이블의 경로가 추가됩니다. 연결된 VPC를 통해 DNS 서버에 연결할 수 있으면 클라이언트 VPN 라우팅 테이블에 DNS 서버 IP 주소의 경로를 추가합니다.

다음은 일반적인 DNS 예제입니다. 이는 Windows와 Linux 환경에 모두 적용됩니다. Linux 환경의 경우, 최종 사용자의 호스트 시스템에서 일반 네트워킹 설정을 사용하는 경우에만 예제가 해당됩니다.

시나리오 1: 전체 터널, “DNS 서버 IP 주소” 파라미터는 꺼진 상태

예제 1 구성:

• 최종 사용자 클라이언트 IPv4 CIDR = 192.168.0.0/16.
• 클라이언트 VPN 엔드포인트 VPC의 CIDR = 10.123.0.0/16.
• 로컬 DNS 서버 IP 주소 = 192.168.1.1.
• “DNS 서버 IP 주소” 파라미터는 꺼진 상태 DNS 서버 IP 주소가 지정되지 않음

“DNS 서버 IP 주소” 파라미터가 꺼져 있기 때문에 최종 사용자의 호스트 컴퓨터가 로컬 DNS 서버를 사용해 DNS 쿼리를 해결합니다.

이 클라이언트 VPN은 전체 터널 모드로 구성되어 있습니다. VPN(utun1을 통한 목적지 0/1)을 통해 트래픽을 모두 전송하기 위해 가상 어댑터를 가리키는 경로가 추가됩니다. 그러나 “DNS 서버 IP 주소” 파라미터가 구성되지 않은 상태이기 때문에 DNS 트래픽이 VPN을 통해 이동할 수 없습니다. 클라이언트와 DNS 서버 간의 DNS 트래픽이 로컬로 유지됩니다. 클라이언트 컴퓨터에 DNS 해결 프로그램에 연결하는 로컬 DNS 서버 주소(dest. 192.168.1.1/32 over en0)의 기본 고정 경로가 이미 있습니다. 도메인 이름이 해당 IP 주소로 확인되면, 애플리케이션 트래픽이 VPN 터널을 통해 확인된 IP 주소로 이동합니다.

예제 코드 조각:

$ cat /etc/resolv.conf | grep nameservernameserver 192.168.1.1

$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1'0/1                192.168.0.1        UGSc           16        0   utun1
192.168.1.1/32     link#4             UCS             1        0     en0
(...)

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        32    IN    A    176.32.98.166
;; SERVER: 192.168.1.1#53(192.168.1.1)
(...)

예제 2 구성:

• 최종 사용자 클라이언트 IPv4 CIDR = 192.168.0.0/16.
• 클라이언트 VPN 엔드포인트 VPC의 CIDR = 10.123.0.0/16.
• 로컬 DNS 서버 IP 주소가 공용 IP = 8.8.8.8로 설정됨
• “DNS 서버 IP 주소” 파라미터는 꺼진 상태 DNS 서버 IP 주소가 지정되지 않음

이 예제에서 클라이언트는 로컬 DNS 서버 198.168.1.1.를 사용하는 대신 공용 DNS 주소 8.8.8.8를 사용합니다. 8.8.8.8에는 en0을 통해 가는 고정 경로가 없기 때문에 이 트래픽은 클라이언트 VPN 터널을 통과해야 합니다. 클라이언트 VPN 엔드포인트가 인터넷에 액세스할 수 없도록 구성되어 있으면 8.8.8.8에서 공용 DNS에 연결할 수 없습니다. 그러면 요청 쿼리 제한 시간이 초과됩니다.

$ cat /etc/resolv.conf | grep nameservernameserver 8.8.8.8

$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8'0/1                192.168.0.1      UGSc            5        0   utun1

$ dig amazon.com(...)
;; connection timed out; no servers could be reached

시나리오 2: 분할 터널, “DNS 서버 IP 주소” 파라미터는 활성화된 상태

구성 예제:

• 최종 사용자 클라이언트 IPv4 CIDR = 192.168.0.0/16.
• 클라이언트 VPN 엔드포인트 VPC의 CIDR = 10.123.0.0/16.
• “DNS 서버 IP 주소” 파라미터가 활성화된 상태이며 10.10.1.228 및 10.10.0.43으로 설정되어 있습니다. 이 IP 주소는 다른 VPC(10.10.0.0/16)에 있는 Route 53 Resolver의 인바운드 엔드포인트의 IP 주소를 나타냅니다. IP 주소가 VPC가 트랜짓 게이트웨이와 연결된 클라이언트 VPN 엔드포인트와 연결됩니다.
• 연결된 VPC에는 “DNS 호스트 이름”과 “DNS 지원”이 활성화된 상태이며 Route 53 프라이빗 호스팅 영역(예제.local)이 연결되어 있습니다.

이 클라이언트 VPN은 분할 터널 모드로 구성되어 있습니다. 최종 사용자의 호스트 시스템 라우팅 테이블에 클라이언트 VPN 라우팅 테이블의 경로가 추가됩니다.

$ netstat -nr -f inet | grep utun1(...)
10.10/16           192.168.0.1        UGSc            2        0   utun1 # Route 53 Resolver inbound endpoints VPC CIDR
10.123/16          192.168.0.1        UGSc            0        0   utun1 # Client VPN VPC CIDR
(...)

이 예에서는 “DNS 서버 IP 주소” 파라미터가 활성화된 상태입니다. 10.10.1.228 및 10.10.0.43이 DNS 서버로 구성되어 있습니다. 클라이언트가 VPN 터널을 생성하면 DNS 서버 파라미터가 최종 사용자의 호스트 컴퓨터로 푸시됩니다.

$ cat /etc/resolv.conf | grep nameservernameserver 10.10.1.228 # Primary DNS server
nameserver 10.10.0.43 # Secondary DNS server

클라이언트 컴퓨터가 VPN 터널을 통해 클라이언트 VPN VPC로 이동하는 DNS 쿼리를 실행합니다. 그 후, DNS 요청이 트랜짓 게이트웨이를 통해 Route 53 Resolver 엔드포인트로 전달됩니다. 도메인이 IP 주소로 확인되면 애플리케이션 트래픽도 설정된 VPN 터널을 통해 이동합니다. 이때 확인된 대상 IP 주소가 클라이언트 VPN 엔드포인트 라우팅 테이블 경로와 일치해야 합니다.

이 구성을 통해 최종 사용자는 표준 DNS 확인을 사용하는 외부 도메인 이름을 확인할 수 있습니다. 그리고 Route 53 Resolver VPC와 연결된 프라이빗 호스팅 영역의 레코드도 확인합니다. 또 인터페이스 엔드포인트 DNS 이름과 EC2 공용 DNS 호스트 이름도 확인합니다.

$ dig amazon.com;; ANSWER SECTION:
amazon.com.        8    IN    A    176.32.103.205
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION:
test.example.local. 10 IN A 10.123.2.1
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC;; ANSWER SECTION:
ec2.ap-southeast-2.amazonaws.com. 60 IN    A    10.10.0.33
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)

$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC;; ANSWER SECTION:
ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11
;; SERVER: 10.10.1.228#53(10.10.1.228)
(...)