AWS Client VPN 연결됐지만 인터넷 안 됨: 라우트 점검

AWS Client VPN 에 연결됐는데 인터넷이 안 되나요? 클라이언트 라우트, 엔드포인트 승인, 서브넷 이그레스, DNS 순서로 확인하세요.

AWS Client VPN 엔드포인트에는 연결됐고 프라이빗 서브넷은 응답하는데, 공개 페이지는 모두 시간 초과로 끝납니다. 이 조합은 문제를 관리되는 쪽의 세 객체 중 하나로 좁힙니다. 클라이언트가 설치하는 라우트, 엔드포인트의 라우트와 그 승인 규칙, 또는 연결된 서브넷의 다음 홉입니다. 클라이언트 쪽에서 보이는 증상이 각각 다르기 때문에 이 순서로 확인합니다. 이 문서는 VPC 에 연결된 관리형 엔드포인트를 다루며, EC2 인스턴스의 OpenVPN 서버나 Cloud WAN 또는 Transit Gateway 연결은 다루지 않습니다.

클라이언트가 실제로 무엇을 라우팅하는지부터 봅니다

연결됨 상태가 증명하는 것은 TLS 세션과 클라이언트에 부여된 CIDR 뿐입니다. 터널이 올라와 있는 동안 공개 주소가 어디로 가는지 운영체제에 물어봅니다. Linux 에서는 ip route get 1.1.1.1 가 터널 인터페이스를 지목해야 하고, macOS 에서는 netstat -rn -f inet | head -5 가 기본 항목을 보여 주며, Windows 에서는 Find-NetRoute -RemoteIPAddress 1.1.1.1 가 선택된 인터페이스와 다음 홉을 출력합니다.

다음으로 분할 터널 플래그를 읽습니다. 엔드포인트가 게시한 라우트만이 클라이언트가 터널로 보내는 유일한 목적지인지 이 플래그가 결정합니다.

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

SplitTunnel 가 true 이면 공개 목적지는 엔드포인트가 그를 덮는 라우트를 게시할 때만 터널을 쓰므로, 0.0.0.0/0 가 없으면 그 트래픽은 로컬 인터페이스에 남습니다. false 이면 클라이언트가 트래픽을 가로채지만 엔드포인트가 여전히 라우팅하고 승인해야 하며, 그렇지 않으면 패킷은 터널로 들어가 그대로 멈춥니다. 두 설정 중 하나를 바꾼 뒤에는 클라이언트를 다시 연결하세요. 라우트와 DNS 서버는 연결 시점에 전달되므로 실행 중인 클라이언트가 옛 집합을 유지할 수 있습니다.

엔드포인트 라우트와 승인 규칙을 따로 읽습니다

둘은 별개의 객체이고, 하나를 만든다고 다른 하나가 만들어지지 않습니다. 엔드포인트 라우트를 나열하고 대상이 연결된 서브넷인 기본 라우트를 찾으세요.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

각 라우트에는 대상 서브넷이 정확히 하나씩 있으므로, 세 연결에는 각각 대응하는 기본 라우트가 필요합니다. AWS 는 이 커버리지 요구를 문서화하며, 빠졌을 때의 실무적 증상은 한 서브넷에서는 작업되고 다른 서브넷에서는 멈추는 형태라서 라우트 누락이 아니라 간헐적 장애로 읽힙니다. 공식 Client VPN 시나리오 문서 가 이 라우트가 속한 퍼블릭 서브넷 구성을 설명합니다.

승인은 두 번째 객체입니다. 공개 목적지를 덮는 규칙이 없으면 터널은 패킷을 실어 나르지만 서비스가 버리므로, 프라이빗 리소스는 계속 동작하고 인터넷만 안 됩니다.

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR 에 대한 규칙은 0.0.0.0/0 에 대해 아무것도 말하지 않습니다. 완전한 터널에 빠진 조각을 채우는 일은 연결된 서브넷마다 라우트 하나와 나중에 감사할 수 있는 승인 규칙 하나를 뜻합니다.

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all 는 엔드포인트의 모든 클라이언트에 목적지를 부여하므로, 터널이 완전해야 하는 동안에만 유지하세요. 묶을 그룹이 있다면 디렉터리 그룹에 묶은 규칙이 더 낫습니다.

패킷이 연결된 서브넷을 빠져나가는 곳까지 따라갑니다

엔드포인트 라우트는 AWS 가 그 패킷을 해당 서브넷에 넘긴다는 것을 결정합니다. 그 너머의 다음 홉은 결정하지 않으며, 그것은 서브넷 자체의 VPC 라우트 테이블에 있습니다.

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

쓸 만한 기본 라우트는 퍼블릭 서브넷이면 인터넷 게이트웨이를, 프라이빗이면 NAT 게이트웨이를 가리키고, 상태가 blackhole 이면 대상이 삭제되어 경로가 조용히 죽은 것입니다. 이것은 엔드포인트 라우트 목록과 다른 테이블이고, 하나를 고쳐도 다른 하나는 고쳐지지 않습니다.

이 홉에는 필터가 둘 있습니다. 대상 네트워크 연결에 적용된 보안 그룹이 공개 목적지로 나가는 트래픽을 허용해야 하고, 해당되는 네트워크 ACL 이 요청과 임시 포트의 반환 트래픽을 허용해야 합니다. 연결 보안 그룹이 제한적이면 프라이빗 접근은 되고 공개 접근은 안 되는 흔한 원인이 됩니다.

셋을 동시에 바꾸지 말고 증상에서 첫 계층을 고르세요.

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS 실패와 죽은 라우트를 분리합니다

이름 해석은 전달과 다르게 실패하고, 완전한 터널에서는 이 차이가 중요해집니다. 밀어 넣은 리졸버에 이제 터널을 통해 도달하기 때문입니다. 엔드포인트가 VPC DNS 서버를 지정하면 그 주소에도 다른 목적지와 같은 라우트 커버리지와 승인이 필요합니다. 어느 실패인지 보려면 리졸버에 직접 질의하세요. dig +short example.com @10.0.0.2, 또는 nslookup example.com 10.0.0.2 를 Windows 에서 사용합니다.

숫자 URL 은 응답하고 이름 URL 은 응답하지 않으면 기본 라우트 편집을 멈추고 DNS 를 다루세요. IP 주소로 보낸 요청은 이름 있는 가상 호스트와 그 인증서에 대해 아무것도 증명하지 않으므로, 마지막 확인에는 이름 있는 시험을 하나 남기세요.

시간도 단서가 됩니다. 몇 초 안에 응답이 없는 TCP 연결은 라우팅이나 필터를 가리키고, 이름 조회 안에서 멈춘 요청은 리졸버를 가리킵니다. 리졸버에 닿을 수 없는 상태에서 기본 라우트를 바꾸면 실패 하나가 둘로 늘어나기 쉽습니다.

깨끗하게 되돌린 뒤 이그레스 경로를 확인합니다

두 객체 모두 추가형이므로 되돌리기는 복구가 아니라 삭제입니다.

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

다시 연결한 뒤 트래픽이 어느 경로로 나가는지 확인합니다. 관찰된 공개 주소를 NAT 게이트웨이의 탄력적 IP 주소 또는 사용하려던 인터넷 게이트웨이와 비교하고, 같은 세션에서 프라이빗 리소스가 여전히 응답하는지도 확인합니다.

짧은 목록으로 마무리하고, 마지막 항목은 문서가 아니라 변경의 일부로 다룹니다.

  • 연결된 서브넷마다 0.0.0.0/0 엔드포인트 라우트 하나.
  • 서비스하려는 클라이언트에 대해 0.0.0.0/0 를 덮는 승인 규칙 하나.
  • 연결된 각 서브넷에 blackhole 이 아닌 VPC 기본 라우트.
  • 연결 보안 그룹의 이그레스와 ACL 반환 트래픽.
  • 리졸버 주소를 라우팅하고 승인했으며 이름 있는 요청으로 검증.
  • 라우트와 규칙에 대한 되돌리기 절차 기록.

범위에 대한 한 가지: 이것은 IPv4 경로입니다. 듀얼 스택 클라이언트는 이미 가진 IPv6 연결을 그대로 유지하므로, IPv6 기본 라우트는 이것의 부작용이 아니라 자체 승인이 필요한 별도 결정입니다.

관련 글