EC2 Windows: VPN 클라이언트, VPN 서버, 아니면 AWS 게이트웨이?
Windows EC2 인스턴스는 VPN 소프트웨어를 실행할 수 있지만, 클라이언트, 자체 관리 서버, AWS 게이트웨이는 소유자가 다른 서로 다른 역할입니다.
한 팀이 Windows EC2 인스턴스에서 실행되는 앱에 VPN 연결이 필요해 호환되는 클라이언트 소프트웨어를 찾아 설치한 뒤, VPC의 나머지가 왜 그것을 쓸 수 없는지 묻습니다. 설치는 성공했습니다. 역할은 정해지지 않았습니다. 게스트 안에서 도는 소프트웨어는 남의 네트워크에 참여하는 클라이언트, 다른 클라이언트를 받아들이는 서버, 또는 AWS가 관리하는 두 VPN 제품 중 어느 것도 아닐 수 있으며, 역할마다 남는 일이 다릅니다.
증상은 보통 잘못된 역할입니다
흔한 증상은 동작하지만 잘못된 문제를 푸는 터널입니다. VM 안의 클라이언트는 그 VM에 나가는 경로를 주지만, 노트북이나 사무실, 다른 서브넷에 들어오는 경로를 주지는 않습니다. VM 안의 서버는 다른 이에게 들어오는 경로를 주지만, 이제 리스너와 인증, 전달을 여러분이 책임집니다.
관리형 서비스는 서비스 운영을 AWS로 옮기고 설계는 여러분에게 남깁니다. Site-to-Site VPN은 고객 게이트웨이와 AWS 게이트웨이를 통해 네트워크를 연결하고, Client VPN은 원격 장치에 관리형 엔드포인트를 제공합니다. 두 경우 모두 경로, 권한 부여 규칙, ID 원본은 여러분의 구성이며, 어느 제품도 Windows 게스트 안에 범용 클라이언트를 설치하지 않습니다.
네 가지 형태가 가능하며, 표는 무엇이 무엇에 연결되고 누가 운영 부담을 지는지로 그것들을 구분합니다.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
제품 이름이 아니라 행을 읽으세요. 같은 Windows 인스턴스라도 그 안에서 어떤 소프트웨어가 도는지에 따라 서로 다른 두 행에 놓일 수 있습니다.
VM 안의 클라이언트: VM이 네트워크에 참여합니다
나가는 클라이언트는 무엇이든 설치하기 전에 Windows 빌드와 아키텍처, 드라이버 요구 사항을 확인해야 합니다. 클라이언트는 인스턴스의 경로와 DNS를 바꾸며, 이는 이미 돌고 있는 서비스와 원격 관리에 쓰는 경로에도 영향을 줄 수 있습니다. 클라이언트가 설정하는 어댑터 이름과 인터페이스 메트릭을 기록하세요. 새 인터페이스가 기존 것보다 우선할 수 있습니다. 인스턴스를 SSH나 RDP 대신 세션 관리자로 관리한다면, 클라이언트가 연결된 뒤에도 그 경로가 동작하는지 확인하세요.
활성화하기 전에 클라이언트가 어떤 트래픽을 실어야 하는지 정하세요. 전체 터널은 관리 세션을 붙잡아 여러분을 잠글 수 있고, 분할 터널은 인스턴스가 사설 네트워크에 닿는 동안 다른 트래픽이 다른 출구로 나가게 합니다. 두 번째 관리 경로를 마련해 두고 시험하고, 클라이언트가 설치하는 경로를 기록해 이후 변경을 설명할 수 있게 하세요.
VM 안의 서버: 다른 클라이언트들이 그것에 참여합니다
자체 관리 서버에서는 리스너, 인증서나 키 자료, 사용자 데이터베이스, 전달 규칙을 여러분이 소유합니다. 서버가 다른 클라이언트의 트래픽을 전달하면 인스턴스는 라우터가 되고, 이를 위해서는 게스트 수준 전달과 함께 AWS 수준의 경로 및 보안 그룹 변경이 필요합니다.
리스너를 게스트에서 확인하고 다시 다른 서브넷에서 확인한 다음, 인스턴스가 전달하는 대상 호스트를 확인하세요. 정상인 로컬 서비스는 전달 경로에 대해 아무것도 증명하지 않으므로 두 결과를 모두 변경 노트에 기록하세요.
관리형 게이트웨이가 유지하는 것은 서비스이지 여러분의 접근 설계가 아닙니다
AWS Site-to-Site VPN 은 고객 게이트웨이와 AWS 게이트웨이 터널 역할을 문서화하며, 그 연결을 산다고 해서 모든 원격 접근 설계가 대체되지는 않습니다. Client VPN은 클라이언트 페르소나를 갖춘 관리형 엔드포인트를 문서화하지만, 권한 부여 규칙과 대상 경로는 여전히 여러분의 것입니다. AWS는 엔드포인트와 그 인증서를 계속 운영하지만, 누가 어떤 앱에 닿을 수 있는지는 여전히 여러분이 작성하고 유지하는 권한 부여 규칙입니다.
다섯 축으로 제품을 고르세요: 각 제품의 역할, 허용하는 프로토콜, 기대하는 ID 원본, 트래픽 전달 방식, 가용성 제공 방식입니다. 포럼 스레드에 인용된 단일 처리량 수치는 무시하세요. 공개된 용량은 서비스와 함께 움직입니다. 또한 관리형 터널 한 쌍이 임의의 게스트 클라이언트 동작을 바꾼다고 가정하지 마세요.
제품보다 역할을 먼저 고르세요
방향을 명시하는 문장 하나를 쓰세요. 이 VM은 네트워크에 참여한다, 이 VM은 클라이언트를 받아들인다, 또는 AWS 게이트웨이가 정의된 네트워크를 연결한다.
그 문장이 제품 후보 목록과 소프트웨어 소유자, 그리고 여러분이 디버깅할 실패 유형을 결정합니다. 요구가 원격 사용자의 앱 도달이라면, 앱의 VM에 설치한 클라이언트는 잘못된 형태입니다. 요구가 한 VM에서 파트너 네트워크로의 도달이라면, 관리형 사이트 간 게이트웨이는 작업에 필요한 것보다 과한 장치입니다. 두 답 모두 정당하지만, 여러분이 쓴 문장과 맞는 것은 하나뿐입니다.