VGW인가 TGW인가? AWS Site-to-Site IPsec 터널이 끝나는 지점

사람들은 AWS Site-to-Site VPN이 어디서 패킷 보호를 멈추는지 묻고 한 가지 답을 기대합니다: 게이트웨이에서. 그 답의 쓸모 있는 버전은 어느 게이트웨이인지를 지목합니다. 가상 프라이빗 게이트웨이와 전송 게이트웨이는 서로 다른 연결 객체를 가진 다른 구성이고, 잘못된 쪽을 전제한 검토자는 존재하지 않는 다이어그램 위에 나머지 평가를 쌓습니다. 아래 세 가지 확인을 순서대로 수행하면, 각각이 경계를 확정하거나 앞선 답이 다른 리소스에 관한 것이었음을 알려 줍니다.

무엇이든 평가하기 전에 세 끝점을 지목하십시오

이 경로의 암호화 검토에는 이름 붙인 세 가지가 필요합니다: 고객 게이트웨이, IPsec을 종료하는 AWS VPN 대상, 내부 패킷을 받는 애플리케이션 끝점입니다. 이 지점 이후의 모든 것이 그 셋 중 하나에 관한 진술이므로, 콘솔 페이지를 한 장도 열기 전에 리소스 식별자와 함께 적어 두십시오.

고객 게이트웨이는 여러분의 것이고 그 구성은 여러분에게 보입니다. AWS 대상은 관리형 리소스이고, 실수는 그것을 전제하는 것입니다: VPN 연결은 가상 프라이빗 게이트웨이에 연결될 수도, 전송 게이트웨이에 직접 연결될 수도 있으며 어느 쪽도 다른 쪽을 함의하지 않습니다. 세 번째 끝점은 사람들이 건너뛰는 것이고, 애플리케이션 데이터에 관한 실제 질문에 답하는 유일한 대상입니다.

확인 1: 실제로 터널을 종료하는 게이트웨이는 무엇인가

두 구성 모두 지원되며 Site-to-Site VPN 아키텍처 안내서 가 둘을 나란히 설명하므로, 흔히 일 년 된 다이어그램 대신 API에 물으십시오. 한 연결에 대한 읽기 전용 질의는 VPN 대상 필드를 돌려줍니다:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

구분자는 VpnGatewayId가 아니라 TransitGatewayId입니다. TransitGatewayId가 비어 있는 연결은 독립된 가상 프라이빗 게이트웨이에서 종료되고, 그 필드가 설정된 연결은 전송 게이트웨이의 VPN 연결 지점에서 종료되며, 그 경우에도 VpnGatewayId는 연결 지점을 뒷받침하는 게이트웨이를 가리킬 수 있으므로 채워져 있을 수 있습니다. 그 전송 게이트웨이의 VPC 연결 지점은 VPN 연결 지점이 아니므로, 먼저 TGW 필드를 읽고, 그다음 연결 지점 유형을 필드 이름이 아니라 연결 지점 목록에서 확인하십시오. 연결된 VPC에서 대상 인스턴스를 찾는 것은 어느 VPN 연결 지점이 패킷을 실어 날랐는지에 관해 아무것도 알려 주지 않습니다.

그곳에 있는 김에 터널도 확인하십시오. 연결은 이중화를 위해 두 개의 IPsec 터널을 나르고, 두 번째 터널이 한 번도 올라오지 않은 연결은 암호화 경계에 관해 아무것도 바꾸지 않더라도 가용성 측면에서 실제 발견 사항입니다:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

확인 2: 내부 패킷이 여전히 나르는 것

IPsec이 종료되면 AWS는 캡슐화를 푼 패킷을 그에 맞는 경로로 전달합니다. 그 지점부터 트래픽은 평범한 VPC 트래픽이고 VPN의 보호는 끝났습니다. 이것은 서비스의 구멍이 아니라 경계의 의미이며, 체크리스트 항목은 "VPN이 암호화되어 있다"가 "데이터가 종단 간 암호화되어 있다"를 대신하게 두지 말고 그것을 분명히 말하는 것입니다.

이제 내부에 무엇이 있었는지 보십시오. 내부 패킷이 평문 애플리케이션 프로토콜이라면 다른 무언가가 암호화하기 전까지 하류에서 기밀성을 더하는 것은 없습니다. 내부 패킷이 이미 TLS 세션을 나른다면 바깥 IPsec을 제거해도 그 세션은 자기 끝점까지 보호된 채로 남으며, 그 끝점이 어디에 있든 마찬가지입니다.

흔한 과잉 수정은 게이트웨이 뒤의 모든 것이 노출되었다고 결론 내리는 것입니다. 그렇지 않습니다. 서비스 전송, 스토리지 암호화, 애플리케이션 TLS는 각기 다른 조건을 가진 별개의 메커니즘이며, VPN의 모양에서 추론하지 말고 각자의 조건으로 평가해야 합니다. ACCEPT를 보여 주는 흐름 로그 항목은 라우팅이 작동했음을 증명하고 기밀성에 관해서는 아무것도 말하지 않으며, 이것이 바로 이 체크리스트가 막으려는 실수입니다.

확인 3: 게이트웨이 뒤에서 TLS를 종료하는 것

주소가 아니라 리스너를 따라가면, 로드 밸런서나 프록시가 TLS를 종료할 때 클라이언트가 가진 연결은 거기서 끝나고, 프록시는 백엔드로 두 번째 연결을 엽니다. 그 연결은 평문일 수도, 다른 신뢰 체인을 가진 TLS일 수도 있습니다. 사설 IP 주소와 일치하는 경로는 그 두 번째 연결에 관한 증거가 아닙니다.

정말로 중요한 끝점을 VPC 내부에서, 한 번 확인한 IP가 아니라 애플리케이션이 쓰는 이름으로 시험하십시오:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

요청이 지나는 각 홉마다 이것을 반복하십시오. 클라이언트를 향한 이름과 백엔드 이름에서 답이 다르다면, VPN이 끝내 덮지 않은 구간을 정확히 찾은 것이며 그것이 기록해야 할 발견 사항입니다.

결과는 판정이 아니라 구간으로 기록하십시오

이 체크리스트의 출력은 구간마다 한 행인 작은 표입니다: 고객 게이트웨이에서 AWS VPN 대상까지, 게이트웨이에서 워크로드까지, 워크로드에서 데이터 저장소까지, 그리고 그 사이의 프록시 홉입니다. 각 행은 무엇이 그것을 보호하고 그 보호가 무엇에 의존하는지를 말합니다. 메커니즘도 끝점도 없는 "암호화됨"은 행이 아닙니다.

그다음 원래 요구 사항에 그것이 제기된 것과 같은 용어로 답하십시오. 요구 사항이 워크로드가 받을 때까지 데이터가 기밀이라는 것이라면, VPN은 첫 구간만 충족하고 나머지 행에는 애플리케이션 전송, 서비스 TLS, 스토리지 암호화를 따로 구성하고 검증해야 합니다.

연결 식별자, 터널 상태, 인증서 주체를 기록에 남기십시오. 누군가 반년 뒤 설계를 다시 볼 때, 그 세 가지 산출물이 다이어그램에서 논쟁을 다시 시작하지 않고 몇 분 만에 경계 질문에 답합니다.