AWS Client VPN 규칙은 서브넷이 아니라 리소스에 둡니다

직원은 VPC의 한 애플리케이션에 도달해야 하고 같은 인스턴스의 데이터베이스 리스너에는 도달해서는 안 되므로, 누군가 VPN 엔드포인트용 두 번째 퍼블릭 서브넷을 추가하고 요구 사항이 충족되었다고 말합니다. 서브넷 배치는 라우팅과 가용성을 바꿉니다. 포트 하나를 허용하거나 막지 않습니다. 요구 사항을 표현하는 권한은 목적지, 즉 리소스의 보안 그룹에 있고, VPN 경계는 그 규칙이 참조하는 핸들을 제공합니다.

서브넷 배치는 라우팅이지 권한 부여가 아닙니다

엔드포인트의 네트워크 연결이 어디에 있는지는 어떤 라우팅 테이블이 클라이언트 트래픽을 나르고 어떤 가용 영역이 장애를 견디는지를 결정합니다. 어느 인스턴스의 어느 포트로 그 트래픽이 도달할 수 있는지는 말하지 않습니다. 같은 서브넷에 연결된 두 클라이언트도 여전히 같은 소스 ID로 도착하며, 리소스는 서브넷 이름으로 둘을 구분할 수 없습니다.

대신 요구 사항에서 시작하세요. 누가 호출하는지, 어떤 리소스인지, 어떤 서비스 포트인지, 어느 방향인지. 그런 다음 그 네 가지를 목적지에서 표현할 수 있는 규칙 모델을 고릅니다. 이런 틀은 보통 추가 서브넷을 설계에서 완전히 없앱니다.

Client VPN 연결 그룹이 바로 그 핸들입니다

서브넷에 연결된 AWS Client VPN 엔드포인트의 경우 문서화된 방식은 구체적입니다. 의도한 보안 그룹을 엔드포인트의 대상 네트워크 연결에 적용한 다음, 그 Client VPN 그룹을 소스로 사용해 리소스의 보안 그룹에서 필요한 트래픽을 허용합니다.

구체적으로, 애플리케이션 인스턴스의 그룹은 연결 그룹에서 오는 애플리케이션 포트만 허용하고 그 밖의 것은 허용하지 않습니다. AWS의 리소스 액세스 절차가 그 관계를 설명하며, 엔드포인트가 연결되는 모든 서브넷에서 같은 그룹 정책을 유지할 가치가 있습니다. 다른 그룹과의 오래된 연결은 경계를 조용히 넓히기 때문입니다.

그 규칙은 누구도 인증하지 않습니다. 로그인은 별도의 제어이고 리소스로 가는 경로는 세 번째입니다. 요청이 도착하기 전에 셋 모두 성립해야 합니다. 어느 것이 실패하는지가 어떤 수정이 맞는지를 정하며, 규칙 변경은 첫 번째에만 정답입니다.

하나의 연결 그룹이 구분할 수 없는 것

같은 연결 그룹 뒤의 모든 클라이언트는 같은 보안 그룹 소스로 리소스에 도달합니다. 역할이 다른 두 사용자는 그 계층에서 구분할 수 없으며, 그룹의 이름이나 태그와 무관합니다. Client VPN의 외부 그룹 권한 부여는 디렉터리나 SAML 그룹에 대해 목적지 접두사로 접근을 제한하는데, 이는 리소스 역할보다 거칠고 ID 시스템이 아니라 네트워크 경계로 다루어야 합니다.

더 미세한 구분은 애플리케이션의 몫입니다. 대부분의 직원에게 닫혀 있어야 하는 데이터베이스 리스너는 그룹 구성원이 깔끔하게 유지되기를 바라는 것보다 허용된 접두사에서 아예 도달할 수 없게 하는 편이 더 잘 보호됩니다.

그룹 이름을 바꾸는 것은 ID를 만들지 않으며, 팀마다 복제하면 감사할 연결만 늘어납니다.

그 규칙을 모든 VPN 설계에 복사하지 마세요

자가 관리 EC2 VPN 게이트웨이, 라우팅된 검사 어플라이언스, 관리형 Client VPN은 서로 다른 세 가지 패킷 경로입니다. 어떤 소스 주소가 실제로 리소스에 도달하는지, 중간에 변환이 일어나는지, 그 경로에서 서비스가 어떤 참조 방식을 지원하는지 확인하세요.

중간 장치를 통해 트래픽을 전달하는 것은 인스턴스 간 직접 트래픽처럼 소스 보안 그룹 참조를 유지하지 않습니다. AWS는 그러한 설계가 그룹 참조 대신 적절한 프라이빗 소스 주소나 CIDR을 필요로 할 수 있다고 문서화합니다. 관리형 Client VPN 절차는 각 게이트웨이에 연결된 그룹이 전달된 패킷에 대한 보편적 ID 토큰으로 작동한다는 증거가 아닙니다.

경로의 NAT 홉 하나면 가정이 깨지고, 장애는 존재하지만 결코 일치하지 않는 규칙처럼 보입니다.

실효 경계를 검토하세요

리소스에 연결된 모든 보안 그룹을 읽으세요. 허용 규칙은 합쳐지고 좁은 규칙이 다른 그룹의 넓은 규칙을 취소하지 않습니다. 그런 다음 네트워크 ACL, 호스트 방화벽, 애플리케이션 자체의 권한 부여를 확인하세요. 이들은 각기 다른 실수를 가진 별개의 계층입니다.

같은 리소스에 대해 허용되는 요청 하나와 의도적으로 제외되는 요청 하나로 마무리합니다. 그 짝이 경계를 증명하는 반면, 성공한 연결 하나는 무언가 열려 있다는 것만 증명합니다. 엔드포인트가 있는 서브넷이 아니라 경로, 실효 소스, 의도한 서비스 포트를 확인하세요.

작업 순서는 네 부분 요구 사항을 쓰고, 그룹을 연결에 붙이고, 리소스 규칙을 포트로 좁히고, 허용 하나와 거부 하나를 검증한 다음에야 라우팅 이유로 서브넷을 나누는 것을 검토하는 것입니다.