DNS는 AWS Client VPN 엔드포인트와 어떻게 작동합니까?

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

새 클라이언트 VPN 엔드포인트를 생성할 때 DNS 서버 IP 주소를 지정합니다. AWS Management Console, create-client-vpn-endpoint AWS CLI 명령 또는 CreateClientVpnEndpoint API 작업을 생성하여 “DNS 서버 IP 주소” 파라미터에 IP 주소를 지정합니다. 기존 엔드포인트를 변경하려면 콘솔, modify-client-vpn-endpoint 명령 또는 ModifyClientVpnEndpoint API 작업을 사용합니다.

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

고가용성을 위해 두 개의 DNS 서버 IP 주소를 지정합니다. 기본 DNS 서버에 연결할 수 없는 경우 클라이언트는 쿼리를 보조 DNS 서버로 재전송하려고 시도합니다.

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

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

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

클라이언트 VPN DNS 서버가 AmazonProvidedDNS 또는 Amazon Route 53 Resolver 인바운드 엔드포인트인 경우 다음을 고려하십시오.

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

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

터널 유형별 DNS 동작

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

• 전체 터널: 클라이언트가 VPN 터널을 통해 모든 트래픽에 대한 경로를 추가합니다. DNS 쿼리를 포함한 모든 트래픽이 터널을 통해 라우팅됩니다. Amazon VPC에 DNS 서버로의 경로가 없으면 조회에 실패합니다.
• 분할 터널: 클라이언트가 클라이언트 VPN 라우팅 테이블의 경로만 추가합니다. VPN을 통해 DNS 트래픽을 라우팅하려면 DNS 서버 IP 주소에 대한 경로를 클라이언트 VPN 라우팅 테이블에 추가하십시오.

다음 예는 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 서버를 사용하여 도메인 이름을 확인합니다.

이 클라이언트 VPN 엔드포인트는 전체 터널 모드로 구성되어 있습니다. VPN(utun1에서 0/1)을 통해 모든 트래픽을 전송하기 위해 클라이언트는 가상 어댑터를 가리키는 경로를 추가합니다. 하지만 엔드포인트가 DNS 서버 구성을 푸시하지 않기 때문에 DNS 트래픽이 VPN을 통해 전송되지 않습니다. 대신 클라이언트는 로컬 DNS 서버 주소(en0을 통한 192.168.1.1/32)에 대한 고정 경로를 사용합니다. 도메인 이름이 로컬에서 확인되면 애플리케이션 트래픽이 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(8.8.8.8)로 구성되어 있음
• DNS 서버 IP 주소 파라미터가 비활성화되어 있고 DNS 서버 IP 주소가 지정되지 않음

이 예에서 클라이언트는 8.8.8.8의 퍼블릭 DNS 서버를 사용합니다. en0을 통한 8.8.8.8에는 고정 경로가 없기 때문에 DNS 요청은 VPN 터널을 통해 이동합니다. 클라이언트 VPN 엔드포인트가 인터넷에 액세스할 수 없는 경우 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 엔드포인트의 Amazon VPC CIDR: 10.123.0.0/16
• DNS 서버 IP 주소 파라미터가 활성화되어 있고 10.10.1.228 및 10.10.0.43(Route 53 Resolver의 인바운드 엔드포인트)으로 설정됨
• Resolver 엔드포인트가 Transit Gateway에서 연결된 Amazon VPC(10.10.0.0/16)에 있음
• Amazon VPC에 Route 53 프라이빗 호스팅 영역(example.local)이 있음
• DNS 확인 및 DNS 호스트 이름이 활성화됨

이 클라이언트 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 요청이 Transit Gateway를 통해 Route 53 Resolver 인바운드 엔드포인트로 전달됩니다. 도메인 이름이 IP 주소로 확인되면 애플리케이션 트래픽도 VPN 터널을 통해 이동합니다. 이 흐름은 확인된 대상 IP 주소가 클라이언트 VPN 엔드포인트 라우팅 테이블의 경로와 일치하는 한 계속됩니다.

이 구성을 통해 최종 사용자는 표준 DNS 확인을 사용하는 외부 도메인 이름을 확인할 수 있습니다. 또한 Route 53 Resolver 인바운드 엔드포인트를 포함하는 Amazon VPC와 연결된 프라이빗 호스팅 영역의 레코드를 확인할 수 있습니다.

$ 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)
(...)