AWS Client VPN인가 Site-to-Site인가: 연결을 여는 주체로 판별하기

이것을 결정하는 것은 네 가지 점검이며, 그중 어느 것도 프로토콜의 이름이 아닙니다. 누가 연결을 여는지, AWS가 무엇을 인증하는지, 연결이 네트워크에 어떻게 붙는지, 그리고 어떤 라우팅과 정책이 따라오는지. 이에 순서대로 답하면 제품 선택은 대개 스스로 정해집니다. 설계를 산 뒤에 답하면 문제의 잘못된 절반을 해결하는 터널을 옹호하게 됩니다. 네 가지 중 어느 것도 암호 선택을 요구하지 않으므로, 프로토콜에서 시작하는 설계가 요구사항을 적어 두지 않았다는 신호인 경우가 많습니다.

각 점검은 범주가 아니라 실제로 사용할 엔드포인트와 클라이언트, 주소 체계를 기준으로 수행하십시오. 관리형 VPN 제품은 비슷하게 보이는 OpenVPN과 IPsec 구성 요소와 다릅니다.

첫째, 누가 연결을 여는가

접근이 필요한 대상이 노트북, 휴대폰, 또는 관리자 한 명의 워크스테이션이라면 연결은 원격 장치에서 시작되고 설계는 원격 클라이언트 접근입니다. 접근이 필요한 대상이 라우터 하나 뒤의 기계로 가득한 지사라면 연결은 그 라우터에서 시작되고 설계는 게이트웨이 간 연결입니다. 대부분의 사례를 정리하는 점검이 바로 이것이며, 공급업체의 발표 자료가 이미 대화를 암호 중심으로 짜 놓았을 때 사람들이 건너뛰는 것도 이 점검입니다.

시작하는 구성 요소를 지목할 수 없다면 여기서 멈추십시오. 하나의 터널로 두 사례를 모두 감당하려는 설계는 대개 스스로를 게이트웨이라고 내세우는 클라이언트 세션으로 끝납니다.

둘째, AWS가 무엇을 인증하는가

Client VPN에서는 AWS가 설정된 클라이언트 또는 사용자 신원을 인증합니다. 인증서, 디렉터리, 연동 신원 중 구성에 따릅니다. Site-to-Site VPN에서는 AWS가 게이트웨이 피어 신원을 인증합니다. 그 차이는 겉모습이 아닙니다. 한 모델은 사용자를 추가하고 자격 증명을 철회하며 확장하고, 다른 모델은 하나의 게이트웨이 뒤에 있는 모든 것을 신뢰하며 확장합니다.

게이트웨이 인증은 그 뒤의 모든 직원이나 애플리케이션을 인증하지 않으므로, 터널 자체를 신뢰하더라도 애플리케이션 신원과 리소스 수준 접근은 그대로 두십시오. 라우터가 유효한 피어 신원을 가진 지사를 그 건물의 모든 책상이 승인되었다고 자동으로 읽어서는 안 됩니다.

셋째, 연결이 어떻게 붙는가

Client VPN은 VPC 서브넷 연결 또는 지원되는 직접 Transit Gateway 연결을 통해 붙습니다. Site-to-Site VPN은 AWS VPN 대상, 흔히 가상 사설 게이트웨이나 Transit Gateway에 붙습니다. Client VPN 아키텍처 안내서는 Transit Gateway 옵션을 문서화하며, 그 존재가 노트북 세션을 지사 게이트웨이로 바꾸지도, 위에서 설명한 클라이언트 인증과 권한 부여를 없애지도 않습니다.

경로를 설계하기 전에 계정과 리전이 실제로 지원하는 연결을 확인하고, 그다음 그 연결의 소유자가 누구인지 확인하십시오. 문서에는 있지만 구성할 수 없는 네트워크에 놓인 옵션은 옵션이 아닙니다.

넷째, 어떤 라우팅과 정책이 따라오는가

Client VPN은 허용한 대상 네트워크에 대한 클라이언트 연결 관리와 권한 부여 규칙을 제공합니다. 연결된 사용자에게는 여전히 의도한 엔드포인트 경로, 이를 허용하는 권한 부여 규칙, 그리고 리소스 자체가 요구하는 접근이 필요합니다. Site-to-Site VPN은 고객 게이트웨이가 나타내는 네트워크 사이를 설계에 따라 지원되는 정적 경로나 BGP로 라우팅하므로, 지사 라우터 뒤의 개별 기계마다 클라이언트 로그인이 필요하지는 않습니다.

어느 방향으로도 범주에서 지원되지 않는 동작을 추론하지 마십시오. 원격 접근 VPN이 반환 트래픽을 나르지 못하거나 게이트웨이 구성을 지원하지 못한다는 것은 보편적인 사실이 아니며, IPsec이 NAT 때문에 자동으로 차단되는 것도 아닙니다. AWS는 NAT 통과와 고객 게이트웨이 요구사항을 문서화하며, 실제 제약은 지원되는 게이트웨이 구성입니다. 클라이언트 방향으로 시작되는 연결을 요구하거나 한 세션 뒤로 LAN을 전달하기 전에 엔드포인트의 제한을 확인하십시오. 같은 주의가 주소 체계에도 적용됩니다. IPv4에서 동작하는 엔드포인트가 IPv6 경로를 뜻하지는 않으므로, 클라이언트나 게이트웨이가 실제로 협상할 체계를 확인하십시오.

Site-to-Site VPN은 연결마다 터널 두 개를 주지만, 그 이중화는 당연히 여길 기능이 아니라 설계 작업입니다. 고객 게이트웨이 운영, 경로 장애 조치, 시험 범위를 모두 계획해야 합니다. 노트북 세션 하나를 추상적인 VPN 서버와 비교하는 것은 둘 중 어느 것도 증명하지 못합니다.

두 설계가 만나는 지점

두 서비스는 배타적이지 않으며 흔한 운영 형태는 둘을 함께 씁니다. 직원은 Client VPN, 지사 네트워크는 Site-to-Site, 그리고 대화해야 하는 대상 사이에 명시적 경로와 접근 정책을 둡니다. 표는 네 가지 점검의 요약이며, 그것을 수행하는 일을 대신하지 않습니다.

두 제품 모두 대체하지 못하는 것이 하나 있습니다. 암호화 요구가 VPN 엔드포인트를 넘어서는 애플리케이션으로 가는 TLS입니다. 준수 범위가 애플리케이션에서 끝난다면 터널은 전송 수단이고 인증서가 여전히 통제입니다.

설계 검토 전에 네 가지 답을 한 줄씩 적어 두십시오. 두 답이 어긋날 때, 예를 들어 사용자 인증 클라이언트 설계와 지사 규모의 라우팅 요구가 함께 있다면, 그 어긋남이 바로 발견 사항이며 컷오버 중에 보는 것보다 지금 보는 편이 쌉니다.