AWS Client VPN 간헐적 접속: 연결된 각 서브넷을 점검하세요

한 사용자는 연결해 내부 앱을 열고 응답을 받습니다. 같은 엔드포인트에 있는 동료는 같은 Wi-Fi의 똑같은 노트북에서 시간 초과를 받습니다. 이 패턴은 연결된 서브넷이 둘 이상인 client VPN 엔드포인트의 특징이며, 경로가 동등하지 않습니다. 콘솔에서 바깥으로 차례로 확인합니다. 탭 두 개가 나머지 조사의 가치를 결정하기 때문입니다. 클라이언트 구성에는 이를 설명하는 것이 없습니다.

엔드포인트에서 시작해 연결을 나열하세요

VPC 콘솔에서 Client VPN endpoints를 열고 엔드포인트를 선택한 뒤 Associations 탭을 읽습니다. 각 연결은 가용 영역의 서브넷이며, 연결이 만들어질 때 서비스가 고른 서브넷에 클라이언트가 착지합니다. 서브넷 ID와 각 연결이 실제로 사용하는 라우팅 테이블을 적어 두세요. 그 두 목록이 곧 하려는 비교입니다.

엔드포인트에 연결이 하나만 보인다면 이 가설은 틀렸고 클라이언트가 더 나은 용의자입니다.

엔드포인트 라우팅 테이블을 각 연결과 비교하세요

같은 엔드포인트에서 Route table 탭을 엽니다. 거기의 모든 대상 CIDR에는 타깃이 있고, client VPN에서는 타깃이 게이트웨이가 아니라 연결입니다. AWS는 연결된 각 서브넷에 대상 항목을 요구하므로, 그중 하나만 겨냥한 경로는 접근을 세션이 착지한 위치에 의존하게 만듭니다. 실제로 중요한 대상을 확인한 다음 그 승인 규칙을 확인하세요. 경로는 길을 제공하고 규칙은 누가 쓸 수 있는지 결정합니다.

두 계층을 모두 표로 만들면 결함을 놓치기 어렵습니다.

대부분의 티켓에서 두 번째 행이 문제의 전부입니다. 엔드포인트 경로가 있으니 아무도 더 보지 않고, 패킷은 한 홉 뒤 VPC 안에서 죽습니다.

각 서브넷을 실제 적용되는 라우팅 테이블까지 따라가세요

라우팅 테이블 연결이 명시되지 않은 서브넷은 VPC의 기본 테이블을 상속합니다. 실제로 유효한 테이블을 읽고, 이름이 맞아 보이는 테이블을 읽지 마세요. 또한 행의 레이블이 아니라 대상과 타깃을 비교하세요.

AWS의 간헐적 접근 안내서는 이를 연결 전반의 경로 커버리지로 설명하며, 그것이 올바른 모델입니다. 엔드포인트는 패킷을 서브넷까지 전달하고, 그 서브넷의 테이블은 여전히 애플리케이션 네트워크가 어디에 있는지 알아야 합니다.

누락된 행을 그것을 소유한 테이블에서 고치세요. 작동하는 서브넷에서 라우팅 테이블 전체를 복사하면 이 서브넷에 전혀 의도되지 않았던 인터넷, 어플라이언스, 격리 선택까지 복사되며, 그 맞바꿈은 보통 처음의 장애보다 나쁩니다.

승인 규칙을 확인하고, 그다음 돌아오는 경로

승인 규칙은 대상별, 그룹별로 존재하며 경로와 별도로 평가됩니다. 어디에나 경로가 있지만 사용자 그룹에 대한 규칙이 없는 대상은 건강해 보이는 라우팅 테이블을 가진 블랙홀처럼 동작합니다.

돌아오는 경로도 같은 주의를 받을 자격이 있습니다. peering 연결에는 앱 VPC에서 클라이언트 CIDR로 되돌아가는 경로, 양쪽 끝에서 트래픽을 허용하는 보안 그룹 규칙, 그리고 그것을 버리지 않는 네트워크 ACL이 필요합니다. 한 방향 도달성, 즉 ping은 되고 TCP 핸드셰이크는 안 되는 경우는 보통 VPN이 아니라 ACL이나 보안 그룹을 가리킵니다.

엔드포인트 자체의 보안 그룹은 연결의 탄력적 네트워크 인터페이스에 있으므로, 클라이언트 CIDR에서 앱 포트를 허용하는 규칙은 인스턴스뿐 아니라 연결에도 붙여야 합니다.

한 번의 운 좋은 요청이 아니라 재연결로 검증하세요

분할 터널에서는 연결이 수립될 때 엔드포인트 경로가 푸시됩니다, 그래서 바뀐 경로 집합은 연결을 유지하는 클라이언트에 절대 도달하지 않습니다. 지원되는 클라이언트로 연결을 끊고 다시 연결한 뒤, 새 경로가 기기에 있는지 확인하세요.

마지막으로 연결 로그를 클라이언트가 받은 주소와 연관 짓고, 연결을 둘 이상 맞힐 만큼 충분히 테스트를 반복하세요. 수정 후 한 번의 성공은 한 경로가 작동함을 증명할 뿐이고, 티켓은 다른 경로에 관한 것이었습니다.