AWS Client VPN DNS: 서브넷이 아니라 VPC 리졸버를 쓰세요

엔드포인트가 10.0.8.0/24 에 있으니 리졸버는 10.0.8.2 여야 한다. 가장 자주 듣는 추론이고 두 번 틀렸다. Route 53 Resolver 는 VPC 의 기본 IPv4 범위에 둘을 더한 주소에서 응답하며, 10.0.0.0/16 인 VPC 라면 엔드포인트가 어느 서브넷을 쓰든 10.0.0.2 이다. 두 번째 오류는 더 조용하다. 엔드포인트에 올바른 주소를 넣어도 클라이언트 운영체제가 그 주소에 무언가를 묻는다는 뜻은 아니다. 두 오류는 같은 증상을 낳는다. 이름 해석이 어떤 클라이언트에서는 되고 다른 클라이언트에서는 실패한다.

오해는 서브넷 연결에서 시작된다

연결은 클라이언트 연결용 탄력적 네트워크 인터페이스가 어디에 있는지에 관한 것이지 어떤 리졸버 주소가 존재하는지에 관한 것이 아니다. 엔드포인트의 서브넷은 클라이언트에 VPC 안의 주소를 주며, 각각이 자기 리졸버를 따로 갖는 것은 아니다.

두 개념을 분리하면 계산은 더 이상 불가사의하지 않고, 문제 해결은 클라이언트로 옮겨간다. 이런 사례 대부분이 실제로 그곳에서 끝난다.

VPC 기본 범위에서 주소를 계산하라

VPC 의 기본 IPv4 CIDR 을 가져와 네트워크 주소에 둘을 더한다. 10.0.0.0/16 은 10.0.0.2, 172.31.0.0/16 은 172.31.0.2 이 되고, 보조 범위가 있는 VPC 도 리졸버를 기본 범위에 둔다. 그 VPC 안의 10.0.8.0/24 서브넷으로는 움직이지 않는다. 엔드포인트를 건드리기 전에 VPC ID 옆에 주소를 적어 두라. 이 숫자는 연결이 아니라 VPC 의 속성이기 때문이다.

VPC 는 링크 로컬 주소 169.254.169.253 에서도 응답한다. 이 주소는 VPC 내부에서는 닿지만, 터널 반대편의 노트북에게 일반적으로 라우팅되는 목적지는 아니다.

따라서 유효한 리졸버 주소는 두 개이고, 둘 다 서브넷에 둘을 더한 값이 아니다.

엔드포인트 설정이 하는 일과 하지 않는 일

Client VPN 엔드포인트에는 DNS 서버 항목이 있고, 콘솔이 VPC 리졸버 옵션을 제공하는 곳에서는 같은 개념을 채워 넣는다. 이 값을 설정하면 연결을 맺을 때 서비스가 클라이언트에 넘기는 값이 바뀐다. 관리되지 않는 OpenVPN 클라이언트가 그 값으로 무엇을 하는지는 바뀌지 않는다. 클라이언트가 결국 운영체제에 적용해야 하기 때문이다. «내 Mac 에서는 되는데 Linux 상자에서는 안 된다» 는 이 틈에서 나온다.

Linux 에서는 리졸버 통합을 연결 관리자가 소유하며 사용자가 아니다. /etc/resolv.conf 을 손으로 고치면 그 주소가 한 세션 동안만 동작함을 증명하고 재연결에서 사라진다. 고쳐 둔 사례가 다음 날 아침 다시 돌아오는 이유다.

연결한 뒤에는 엔드포인트 설정 페이지가 아니라 클라이언트의 활성 리졸버를 확인하라.

스플릿 터널링이 올바른 리졸버를 무력화할 수 있다

스플릿 터널링에서는 터널로 밀어 넣은 경로만 쓰인다. 리졸버 주소가 어떤 경로에도 덮이지 않으면 질의는 로컬 인터페이스로 나가고 집 공유기가 응답한다. 엔드포인트의 주소는 여전히 맞고 조회는 여전히 실패한다. 리졸버용 경로를 추가한 뒤 다시 시험하라.

겹치는 로컬 범위는 같은 결과를 더 고약한 방식으로 낸다. 질의에 응답이 오지만 엉뚱한 서버에서 온다.

Amazon DNS 주소를 위해 보안 그룹을 열지 말라

조회가 시간 초과될 때의 충동은 리졸버 주소로 UDP 53 을 허용하는 규칙을 더하는 것이다. AWS 는 보안 그룹과 네트워크 ACL 이 Amazon DNS 트래픽을 직접 만든 DNS 인스턴스로 가는 트래픽처럼 걸러내지 않는다고 문서화한다. 그 규칙을 열어도 VPC 리졸버에는 아무 변화가 없고 이유 없이 경계만 넓힌다. 직접 운영하는 리졸버는 다른 사례이며 정말로 자기 규칙이 필요하다.

설계에 둘 다 있다면 어떤 규칙을 고치기 전에 클라이언트가 실제로 어느 쪽을 향하는지 확인하라.

경로를 검증한 다음 다른 것을 측정하라

공개 이름을 해석하고, VPC 에 연결된 프라이빗 호스팅 영역에 등록된 사설 이름을 해석하고, 그 사이에 클라이언트의 활성 리졸버를 읽어라. 이 순서가 «리졸버 주소가 틀렸다» 를 «영역이 연결되지 않았다» 와 «클라이언트가 설정을 무시했다» 에서 갈라낸다. 각각 고치는 방법이 다르고, 어느 것도 처리량 문제가 아니다.

성공한 조회는 지속적인 전송 속도에 대해 아무것도 말해 주지 않는다. 보고할 때는 이 두 이야기를 분리해 두라.