AWS Client VPN 또는 EC2 위의 VPN: 운영 런북

두 선택지 모두 팀에 원격 접속 VPN을 제공하므로, 중요한 질문은 어느 것이 존재하느냐가 아니라 어느 것을 운영할 수 있느냐입니다. 차이는 새벽 3시에 엔드포인트를 누가 소유하는지, 그리고 무언가 고장 났을 때 어떤 제어 수단에 닿을 수 있는지입니다. 아래 다섯 단계를 순서대로 진행하십시오. 각 단계가 비교를 일찍 끝낼 수 있기 때문입니다. 인벤토리 단계를 건너뛰면 팀이 두 번 마이그레이션하게 됩니다.

1단계: 청구서보다 요구사항을 먼저 씁니다

한 페이지에 다섯 가지 사실이 필요합니다. 누가 무엇에 대해 인증하는지, 어떤 클라이언트 플랫폼이 동작해야 하는지, 어떤 프라이빗 목적지에 도달할 수 있는지, 어떤 가용성을 약속했는지, 트래픽이 실제로 어떤 모습인지입니다. 이것이 없으면 이후의 모든 비교는 기능 목록 논쟁이 됩니다.

목적지에 대해 구체적으로 쓰십시오. «VPC 접근»은 보통 세 가지 다른 것을 뜻합니다. VPC CIDR, 피어링된 네트워크, Transit Gateway 뒤의 온프레미스 대역입니다. 관리형 엔드포인트는 셋 모두에 도달할 수 있지만 각각 경로와 권한 부여 규칙이 필요하고, 각각이 요구사항의 별도 항목입니다.

2단계: 이미 돌아가는 것을 나열합니다

무엇이든 설계하기 전에 기존 엔드포인트와 EC2에서 호스팅하는 모든 서버를 보안 그룹과 함께 나열하십시오. 이 호출은 읽기 전용이며 describe 권한이 있는 계정에서 실행해도 안전합니다.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

출력은 클라이언트가 이미 도달할 수 있는 범위의 지도로 읽으십시오. 권한 부여 규칙이 빠져 있으면 라우팅 문제처럼 보이는 장애가 설명되고, 단일 서브넷에 연결된 엔드포인트는 영역 장애가 서비스 전체를 왜 떨어뜨렸는지 설명합니다.

직접 호스팅한 인스턴스에 붙은 보안 그룹도 기록하십시오. 그 규칙은 접근 모델의 일부이며, 누군가 템플릿에서 인스턴스를 다시 만들 때 가장 먼저 조용히 깨지는 것입니다.

3단계: 책임을 나눕니다

관리형 서비스는 엔드포인트 집합과 그 패치, 리전 내 가용성을 소유합니다. 여러분은 자격 증명 등록, 권한 부여 규칙, 엔드포인트 뒤의 네트워크 경로, 로깅 구성, 서브넷을 몇 개 연결할지에 대한 결정을 소유합니다.

직접 호스팅은 이를 뒤집습니다. 여러분은 게스트 운영 체제, VPN 데몬과 그 구성, 인증서와 키, 백업, 모니터링, 복구를 소유합니다. EC2 보안 모델은 게스트와 애플리케이션 보안을 고객에게 두며, VPN 서버도 다른 게스트와 같은 게스트입니다.

분담을 오른쪽 열에 이름을 넣은 표로 쓰십시오. 인증서 갱신 옆에 아무 이름도 없다면 그것이 핵심 발견이며, 시간당 비용 차이보다 중요합니다.

4단계: 설명할 수 있는 워크로드와 비교합니다

비용은 크기가 아니라 형태를 따릅니다. 관리형 옵션은 엔드포인트 연결 시간, 클라이언트 접속 시간, 전송량, 활성화한 자격 증명과 로깅 서비스를 세십시오. 직접 호스팅은 컴퓨팅, 스토리지, 네트워크, 라이선스, 서버를 패치된 상태로 유지하는 엔지니어링 시간을 세십시오. 두 숫자 집합을 같은 시간 범위의 한 시트에 놓으십시오. 패치 시간을 무시한 삼 년 비교는 이미 보유한 서버에 항상 유리합니다.

성능 비교에도 같은 규율이 필요합니다. 대화형 데스크톱 세션 하나, 큰 전송 하나, 동시의 작은 요청 오십 개는 경로의 서로 다른 부분에 부하를 줍니다. 암호화를 위한 CPU, 인스턴스의 네트워크 성능, 클라이언트 자체 스택, 그리고 목적지입니다. 대표성 있는 클라이언트와 같은 작업으로 두 설계를 시험하십시오.

더 큰 인스턴스는 전송이 빨라진다는 증거가 아니고, 한 번의 성공한 세션은 용량 계획이 아닙니다. 인스턴스 패밀리에 대해 물려받은 이야기는 구매 규칙이 아니라 검증할 가설로 다루십시오.

5단계: 이미 실행해 본 롤백과 함께 전환합니다

정해진 기간 동안 두 엔드포인트를 병행 운영하고, 새 클라이언트 프로파일을 먼저 작은 그룹에 배포하며, 그 그룹이 실제 업무에서 새 것을 쓰기 전까지 이전 엔드포인트의 권한 부여 규칙은 그대로 두십시오. 롤백은 재구축이 아니라 프로파일 전환이므로, 이전 프로파일이 어디에 있는지 지금 정하십시오.

다음 순서로 확인하십시오. 인증이 성공하고, 클라이언트가 예상한 경로를 받고, 권한이 부여된 목적지는 응답하고 권한이 없는 목적지는 실패하며, 로그에 두 사건이 모두 남습니다. 어느 단계든 실패하면 다음 클라이언트 그룹으로 넘어가지 말고 그 단계를 멈추고 고치십시오. 각 확인의 결과를 적어 두십시오. «됐다»로만 기억되는 전환은 한 달 뒤에 디버깅할 수 없습니다.

전환 후에는 지루한 점검을 예약하십시오. 인증서 만료, 연결 수, 더 이상 그룹과 맞지 않는 권한 부여 규칙, 예상 대비 접속 수입니다. Client VPN 관리 안내서는 구성한 엔드포인트, 인증, 라우팅 부분의 참고 자료입니다.