패킷 미러링

이 페이지에서는 가상 프라이빗 클라우드(VPC) 네트워크의 패킷 미러링에 대하여 간략하게 설명합니다. 워크로드의 네트워크 트래픽을 대규모로 분석하고 서드 파티 가상 어플라이언스를 사용하여 네트워크 트래픽을 모니터링하려면 네트워크 보안 통합 패킷 미러링을 사용하세요. 자세한 내용은 대역 외 통합 개요를 참고하세요.

패킷 미러링은 VPC 네트워크에서 지정된 인스턴스의 트래픽을 클론하여 검사를 위해 전달합니다. 패킷 미러링은 페이로드와 헤더를 포함한 모든 트래픽과 패킷 데이터를 캡처합니다. 캡처는 이그레스 및 인그레스 트래픽, 인그레스 트래픽 또는 이그레스 트래픽 모두에 대해 구성될 수 있습니다.

미러링은 네트워크가 아닌 가상 머신(VM) 인스턴스에서 수행됩니다. 따라서 패킷 미러링은 VM에서 호스트의 대역폭을 추가로 사용합니다.

패킷 미러링은 보안 상태를 모니터링하고 분석해야 하는 경우에 유용하며 샘플링 기간 사이의 트래픽뿐 아니라 모든 트래픽을 내보냅니다. 예를 들어 미러링된 트래픽에 위협 또는 이상이 있는지 감지하기 위해 보안 소프트웨어를 사용해도 됩니다. 또한 전체 트래픽 흐름을 검사하여 애플리케이션 성능 문제를 감지할 수 있습니다. 자세한 내용은 사용 사례의 예시를 참조하세요.

작동 방식

패킷 미러링은 미러링된 소스에서 트래픽을 복사하여 수집기 대상으로 전송합니다. 패킷 미러링을 구성하려면 소스 및 대상을 지정하는 패킷 미러링 정책을 만듭니다.

• 미러링된 소스는 서브넷, 네트워크 태그 또는 인스턴스 이름을 지정하여 선택할 수 있는 Compute Engine VM 인스턴스입니다. 서브넷을 지정하면 해당 서브넷에 있는 모든 기존 인스턴스와 향후 인스턴스가 미러링됩니다. 소스 유형을 하나 이상 지정할 수 있으며 인스턴스가 유형 최소 하나 이상과 일치하면 미러링됩니다.

  패킷 미러링은 패킷 미러링 정책이 적용되는 네트워크 내 인스턴스의 네트워크 인터페이스에서 트래픽을 수집합니다. 인스턴스에 여러 네트워크 인터페이스가 있는 경우에는 적용 가능한 또 다른 정책이 구성되어 있지 않는 한 다른 인터페이스는 미러링되지 않습니다.

• 수집기 대상은 내부 부하 분산기 뒤에 있는 인스턴스 그룹입니다. 인스턴스 그룹의 인스턴스를 수집기 인스턴스라고도 합니다.

  수집기 대상을 지정할 때 내부 패스 스루 네트워크 부하 분산기와 연결된 전달 규칙의 이름을 입력합니다. 그러면 Google Cloud에서 미러링된 트래픽을 수집기 인스턴스로 전달합니다. 패킷 미러링을 위한 내부 부하 분산기는 패킷 미러링에 적용할 전달 규칙을 구성해야 한다는 점을 제외하고 다른 내부 부하 분산기와 유사합니다. 부하 분산기로 전송된 트래픽 중 미러링되지 않은 트래픽은 모두 삭제됩니다.

필터링

기본적으로 패킷 미러링은 미러링된 인스턴스의 모든 IPv4 트래픽을 수집합니다. 모든 IPv4 트래픽을 수집하는 대신 필터를 사용하여 수집된 트래픽을 확장하여 전체 또는 일부 IPv6 트래픽을 포함할 수 있습니다. 또한 필터를 사용하여 미러링되는 트래픽의 범위를 좁힐 수 있으므로 미러링된 인스턴스에서 사용하는 대역폭을 제한하는 데 도움이 될 수 있습니다.

프로토콜, CIDR 범위(IPv4, IPv6 또는 둘 다), 트래픽 방향(인그레스 전용, 이그레스 전용, 또는 둘 다)에 따라 트래픽을 수집하도록 필터를 구성할 수 있습니다.

정책 순서

하나의 인스턴스에 여러 패킷 미러링 정책을 적용할 수 있습니다. 패킷 모니터링의 우선순위는 항상 1000이며 변경할 수 없습니다. 동일한 정책은 지원되지 않습니다. Google Cloud 는 동일한 패킷 미러링 정책으로 구성된 부하 분산기로 트래픽을 전송할 수 있습니다. 미러링된 트래픽을 예측 가능하고 지속적인 방법으로 단일 부하 분산기로 전송하려면 필터의 주소 범위가 겹치지 않는 정책을 만드세요. 범위가 겹치면 고유한 필터 프로토콜을 설정합니다.

Google Cloud 는 각 정책의 필터에 따라 각 흐름당 하나의 정책을 선택합니다. 고유한 정책이 있는 경우 Google Cloud 는 미러링된 트래픽과 일치하는 해당 정책을 사용합니다. 예를 들어 필터 198.51.100.3/24:TCP가 포함된 정책 하나와 필터 2001:db8::/64:TCP:UDP가 포함된 다른 정책이 있을 수 있습니다. 두 정책은 서로 다르므로 Google Cloud 에서 어떤 정책을 사용하는지에 대한 모호성이 없습니다.

하지만 겹치는 정책이 있으면 Google Cloud 가 필터를 평가하여 사용할 정책을 선택합니다. 예를 들어 필터 10.0.0.0/24:TCP가 포함된 정책 하나와 필터 10.0.0.0/16:TCP가 포함된 다른 정책이 있다고 가정하겠습니다. 이 경우 CIDR 범위가 겹치기 때문에 정책이 겹치게 됩니다.

정책을 선택할 때 Google Cloud 는 필터의 CIDR 범위 크기를 비교하여 정책의 우선순위를 지정합니다.

Google Cloud 는 필터를 기준으로 정책을 선택합니다.

• 정책에 다르지만 겹치는 CIDR 범위가 있고 똑같은 프로토콜이 사용된 경우 Google Cloud 는 가장 구체적인 CIDR 범위를 사용하는 정책을 선택합니다. 미러링된 인스턴스에서 나가는 TCP 패킷의 대상이 10.240.1.4이고 10.240.1.0/24:ALL 및 10.240.0.0/16:TCP 필터를 사용하는 정책이 2개 있다고 가정해 보겠습니다. 10.240.1.4에 대한 가장 구체적인 일치 항목이 10.240.1.0/24:ALL이므로Google Cloud 는 10.240.1.0/24:ALL 필터가 있는 정책을 사용합니다.

• 정책에 프로토콜이 겹치는 똑같은 CIDR 범위가 지정된 경우,Google Cloud 는 프로토콜이 가장 구체적인 정책을 선택합니다. 예를 들어 10.240.1.0/24:TCP와 10.240.1.0/24:ALL의 경우 똑같은 범위가 사용되었지만 프로토콜이 겹칩니다. TCP 트래픽 일치를 위해 Google Cloud 는 10.240.1.0/24:TCP 정책을 사용합니다. 10.240.1.0/24:ALL 정책은 다른 모든 프로토콜에 일치하는 트래픽에 적용됩니다.

• 정책의 CIDR 범위는 똑같지만 프로토콜이 서로 다르면 이러한 정책은 겹치지 않습니다. Google Cloud 는 미러링된 트래픽의 프로토콜에 해당하는 정책을 사용합니다. 예를 들어 2001:db8::/64:TCP에 대한 정책과 2001:db8::/64:UDP에 대한 정책이 있으면 Google Cloud 는 미러링된 트래픽의 프로토콜에 따라 TCP 또는 UDP 정책을 사용합니다.

• 겹치는 정책에 정확히 동일한 필터가 포함된 경우 정책이 동일합니다. 이 경우 Google Cloud 는 이러한 정책에 따라 일치하는 트래픽이 재평가될 때마다 동일한 정책 또는 다른 정책을 선택할 수 있습니다. 동일한 패킷 미러링 정책은 만들지 않는 것이 좋습니다.

VPC 흐름 로그

VPC 흐름 로그는 미러링된 패킷을 로깅하지 않습니다. 수집기 인스턴스가 VPC 흐름 로그가 사용 설정된 서브넷에 있는 경우 미러링된 인스턴스의 트래픽을 포함하여 수집기 인스턴스로 직접 전송되는 트래픽이 로깅됩니다. 즉, 원래 대상 IPv4 또는 IPv6 주소가 수집기 인스턴스의 IPv4 또는 IPv6 주소와 일치하면 흐름이 로깅됩니다.

VPC 흐름 로그에 대한 자세한 내용은 VPC 흐름 로그 사용을 참조하세요.

주요 속성

다음 목록은 패킷 미러링의 제약조건 또는 동작을 설명하며, 패킷 미러링을 사용하기 전에 읽고 이해해야 합니다.

• 각 패킷 미러링 정책은 미러링된 소스 및 수집기 대상을 정의합니다. 다음 규칙을 준수해야 합니다.

  • 미러링된 모든 소스는 동일한 프로젝트, VPC 네트워크, Google Cloud 리전에 있어야 합니다.
  • 수집기 대상은 미러링된 소스와 동일한 리전에 있어야 합니다. 수집기 대상은 미러링된 소스와 동일한 VPC 네트워크나 VPC 네트워크 피어링을 사용하여 미러링된 소스의 네트워크에 연결된 VPC 네트워크에 위치할 수 있습니다.
  • 각 미러링 정책은 단일 수집기 대상만 참조할 수 있습니다. 하지만 여러 미러링 대상에서는 단일 수집기 대상을 참조할 수 있습니다.

• 모든 레이어 4 프로토콜은 패킷 미러링에서 지원됩니다.

• VM 인스턴스의 동일한 네트워크 인터페이스에서는 트래픽을 미러링하거나 수집하면 안 됩니다. 미러링하거나 수집할 경우 미러링 루프가 발생할 수 있기 때문입니다.

• 동일한 Google Kubernetes Engine(GKE) 노드에서 포드 간 전달되는 트래픽을 미러링하려면 클러스터에 노드 내 공개 상태를 사용 설정해야 합니다.

• IPv6 트래픽을 미러링하려면 필터를 사용하여 미러링할 IPv6 트래픽의 IPv6 CIDR 범위를 지정합니다. ::/0의 CIDR 범위 필터를 사용하여 모든 IPv6 트래픽을 미러링할 수 있습니다. 쉼표로 구분된 CIDR 범위 필터 0.0.0.0/0,::/0을 사용하여 모든 IPv4 및 IPv6 트래픽을 미러링할 수 있습니다.

• 미러링 트래픽은 미러링된 인스턴스의 대역폭을 사용합니다. 예를 들어 미러링된 인스턴스에서 1Gbps의 인그레스 트래픽과 1Gbps의 이그레스 트래픽이 발생하면 총 인스턴스 트래픽은 인그레스 1Gbps, 이그레스 3Gbps(1Gbps의 일반 이그레스 트래픽과 2Gbps의 미러링된 이그레스 트래픽)가 됩니다. 수집되는 트래픽을 제한하려면 필터를 사용하세요.

• 패킷 미러링의 비용은 미러링된 인스턴스에서 인스턴스 그룹으로 이동하는 이그레스 트래픽의 양과 트래픽이 영역 간에 이동하는지 여부에 따라 다릅니다.

• 패킷 미러링은 인그레스 및 이그레스 방향에 모두 적용합니다. 미러링되고 있는 2개의 VM 인스턴스가 서로 트래픽을 주고 받는 경우Google Cloud 는 동일한 패킷에 대한 두 가지 버전을 수집합니다. 인그레스 또는 이그레스 패킷만 미러링하도록 지정하여 이 동작을 변경할 수 있습니다.

• 프로젝트에서 만들 수 있는 패킷 미러링 정책 수에는 한도가 있습니다. 자세한 내용은 할당량 페이지의 프로젝트별 할당량을 참조하세요.

• 각 패킷 미러링 정책에 지정할 수 있는 미러링된 소스의 최대 개수는 소스 유형에 따라 다릅니다.

  • 서브넷 5개
  • 태그 5개
  • 인스턴스 50개

• 패킷 미러링 필터의 최대 개수는 30개로, IPv4 및 IPv6 주소 범위 개수에 프로토콜 개수를 곱한 값입니다. 예를 들어 30개의 범위와 1개의 프로토콜을 지정하면 필터는 30개가 됩니다. 그러나 30개의 범위와 2개의 프로토콜은 지정할 수 없습니다. 이 경우 필터가 60개가 되어 최댓값을 초과하기 때문입니다.

• 미러링된 트래픽은 VM이 애플리케이션 계층에서 해당 트래픽을 암호화하는 경우에만 암호화됩니다. VPC 네트워크 및 피어링된 VPC 네트워크 내의 VM 간 연결은 암호화되지만, 암호화 및 복호화는 하이퍼바이저에서 수행됩니다. VM의 관점에서 이 트래픽은 암호화되지 않습니다.

사용 사례

다음 섹션에서는 실제 시나리오를 통해 패킷 미러링을 사용하는 이유에 대해 설명합니다.

엔터프라이즈 보안

보안 및 네트워크 엔지니어링팀은 보안 침해 및 침입을 나타낼 수 있는 모든 이상 동작과 위협을 포착해야 합니다. 따라서 의심스러운 흐름을 종합적으로 검사하기 위해 모든 트래픽을 미러링합니다. 공격은 여러 패킷에 걸쳐 발생할 수 있기 때문에 보안팀은 흐름별로 모든 패킷을 가져올 수 있어야 합니다.

예를 들어 다음 보안 도구를 사용하려면 여러 패킷을 캡처해야 합니다.

• 침입 감지 시스템(IDS) 도구를 사용하여 영구적 위협을 감지하려면 여러 패킷으로 구성된 단일 흐름을 서명과 일치시킬 수 있어야 합니다.

• 딥 패킷 검사 엔진은 패킷 페이로드를 검사하여 프로토콜에서 이상이 있는 부분을 감지합니다.

• PCI 규정 준수 및 기타 규제 관련 사용 사례에 대한 네트워크 증거를 수집하려면 대부분의 패킷을 조사해야 합니다. 패킷 미러링은 간헐적 통신이나 통신을 시도했지만 실패한 경우와 같이 다양한 공격 벡터를 캡처하는 솔루션을 제공합니다.

애플리케이션 성능 모니터링

네트워크 엔지니어는 미러링된 트래픽을 사용하여 애플리케이션 및 데이터베이스팀에서 보고한 성능 문제를 해결할 수 있습니다. 네트워킹 문제를 확인하기 위해 네트워크 엔지니어는 애플리케이션 로그를 사용하는 대신 전송 중인 데이터를 확인할 수 있습니다.

예를 들어 네트워크 엔지니어는 패킷 미러링의 데이터를 사용하여 다음 작업을 수행할 수 있습니다.

• 패킷 손실이나 TCP 재설정과 같은 문제를 보다 신속하게 찾아 해결할 수 있도록 프로토콜과 동작을 분석합니다.

• 원격 데스크톱, VoIP, 기타 대화형 애플리케이션에서 트래픽 패턴을 실시간으로 분석합니다. 네트워크 엔지니어는 여러 패킷 재전송 또는 예상보다 많은 재연결 횟수 등 애플리케이션의 사용자 경험에 영향을 미치는 문제를 검색할 수 있습니다.

수집기 대상 토폴로지 예시

패킷 미러링은 다양한 설정으로 사용할 수 있습니다. 다음 예시는 수집기 대상 위치와 VPC 네트워크 피어링 및 공유 VPC와 같은 다양한 패킷 미러링 구성 관련 정책을 보여줍니다.

동일한 네트워크에 있는 수집기 대상

다음 예시는 미러링된 소스와 수집기 대상이 동일한 VPC 네트워크에 있는 경우의 패킷 미러링 구성을 보여줍니다.

위의 다이어그램에서 패킷 미러링 정책은 mirrored-subnet를 미러링한 후 미러링된 트래픽을 내부 패스 스루 네트워크 부하 분산기로 전송하도록 구성되어 있습니다.Google Cloud 는 서브넷의 기존 인스턴스와 향후 인스턴스의 트래픽을 미러링합니다. 인터넷, 온프레미스 호스트 또는 Google 서비스와 주고 받는 전체 트래픽이 미러링됩니다.

피어 네트워크의 수집기 대상

서로 다른 VPC 네트워크의 인스턴스에서 미러링된 트래픽을 중앙 VPC 네트워크의 수집기 대상으로 전송하는 중앙 집중식 수집기 모델을 빌드할 수 있습니다. 이렇게 하면 단일 대상 수집기를 사용할 수 있습니다.

다음 예시에서 collector-load-balancer 내부 패스 스루 네트워크 부하 분산기는 project-a의 network-a VPC 네트워크에 있는 us-central1 리전에 있습니다. 패킷 미러링 정책 두 개에서 이 대상 수집기를 사용할 수 있습니다.

• policy-1은 project-a의 network-a VPC 네트워크에 있는 us-central1 리전의 미러링된 소스에서 패킷을 수집하여 collector-load-balancer 대상으로 전송합니다.

• policy-2는 project-b의 network-b VPC 네트워크에 있는 us-central1 리전의 미러링된 소스에서 패킷을 수집하여 동일한 collector-load-balancer 대상으로 전송합니다.

미러링된 소스가 서로 다른 VPC 네트워크에 있으므로 미러링 정책 두 개가 필요합니다.

위의 다이어그램에서 수집기 대상은 서로 다른 두 네트워크의 서브넷에서 미러링된 트래픽을 수집합니다. 모든 리소스(소스와 대상)는 동일한 리전에 있어야 합니다. network-a의 설정은 미러링된 소스와 수집기 대상이 동일한 VPC 네트워크에 있는 경우의 예시와 비슷합니다. policy-1는 subnet-a에서 들어오는 트래픽을 수집하여 collector-ilb로 전송하도록 구성되어 있습니다.

policy-2는 project-a에서 구성되지만 subnet-b를 미러링된 소스로 지정합니다. network-a와 network-b가 피어링되기 때문에 대상 수집기는 subnet-b에서 트래픽을 수집할 수 있습니다.

네트워크가 서로 다른 프로젝트에 있으므로 여러 소유자를 포함할 수 있습니다. 이러한 소유자들에게 올바른 권한이 있다면 이 중 한 소유자가 패킷 미러링 정책을 만들 수 있습니다.

• project-a의 소유자가 패킷 미러링 정책을 만들 경우 네트워크, 서브넷 또는 인스턴스에 대한 compute.packetMirroringAdmin 역할이 있어야 project-b에서 미러링할 수 있습니다.

• project-b의 소유자가 패킷 미러링 정책을 만들 경우 project-a에 compute.packetMirroringUser 역할이 있어야 합니다.

두 VPC 네트워크에서 비공개 연결을 사용 설정하는 방법에 대한 자세한 내용은 VPC 네트워크 피어링을 참조하세요.

공유 VPC

다음 공유 VPC 시나리오에서 수집기 대상의 미러링된 인스턴스는 모두 동일한 공유 VPC 네트워크에 있습니다. 리소스가 모두 동일한 네트워크에 있더라도 호스트 프로젝트나 여러 서비스 프로젝트와 같은 서로 다른 프로젝트에 있을 수 있습니다. 다음 예시는 패킷 미러링 정책을 만들 위치와 이 정책을 만들 권한이 있는 사용자를 보여줍니다.

미러링된 소스 및 수집기 대상이 동일한 프로젝트(호스트 프로젝트 또는 서비스 프로젝트)에 있는 경우의 설정은 모든 항목이 동일한 VPC 네트워크에 있을 때와 비슷합니다. 프로젝트 소유자가 모든 리소스를 만들고 해당 프로젝트에 필수 권한을 설정할 수 있습니다.

자세한 내용은 공유 VPC 개요를 참조하세요.

서비스 프로젝트의 수집기 대상

다음 예시에서는 수집기 대상이 호스트 프로젝트의 서브넷을 사용하는 서비스 프로젝트에 있습니다. 이 경우에는 정책도 서비스 프로젝트에 있지만 정책은 호스트 프로젝트에 있을 수도 있습니다.

위 다이어그램의 서비스 프로젝트에는 공유 VPC 네트워크의 수집기 서브넷을 사용하는 수집기 인스턴스가 포함되어 있습니다. 패킷 미러링 정책은 서비스 프로젝트에서 생성되었으며 subnet-mirrored의 네트워크 인터페이스가 있는 인스턴스를 미러링하도록 구성되어 있습니다.

서비스 또는 호스트 프로젝트 사용자는 패킷 미러링 정책을 만들 수 있습니다. 그러려면 사용자는 수집기 대상이 위치한 서비스 프로젝트에 compute.packetMirroringUser 역할이 있어야 합니다. 또한 사용자에게는 미러링된 소스에 대한 compute.packetMirroringAdmin 역할도 필요합니다.

호스트 프로젝트의 수집기 대상

다음 예시에서 수집기 대상은 호스트 프로젝트에, 미러링된 인스턴스는 서비스 프로젝트에 있습니다.

이 예시는 개발자가 서비스 프로젝트에 애플리케이션을 배포하고 공유 VPC 네트워크를 사용하는 시나리오에 적용할 수 있습니다. 이 시나리오에서는 네트워킹 인프라나 패킷 미러링을 관리할 필요가 없습니다. 대신 호스트 프로젝트 및 공유 VPC 네트워크를 관리하는 중앙 네트워킹팀이나 보안팀이 패킷 미러링 정책을 프로비저닝해야 합니다.

위의 다이어그램에서 패킷 미러링 정책은 수집기 대상이 있는 호스트 프로젝트에 생성됩니다. 이 정책은 미러링된 서브넷의 인스턴스를 미러링하도록 구성됩니다. 서비스 프로젝트의 VM 인스턴스는 미러링된 서비스를 사용할 수 있으며 관련 트래픽은 미러링됩니다.

서비스 또는 호스트 프로젝트 사용자는 패킷 미러링 정책을 만들 수 있습니다. 그러려면 서비스 프로젝트의 사용자는 호스트 프로젝트에 compute.packetMirroringUser 역할이 있어야 합니다. 호스트 프로젝트의 사용자에게는 서비스 프로젝트의 미러링된 소스에 대한 compute.packetMirroringAdmin 역할이 필요합니다.

다중 인터페이스 VM 인스턴스

패킷 미러링 정책에 다중 네트워크 인터페이스가 있는 VM 인스턴스를 포함할 수 있습니다. 하나의 정책은 단일 네트워크의 리소스를 미러링할 수 있으므로 인스턴스 내 모든 네트워크 인터페이스의 트래픽을 미러링하려면 정책을 하나만 만들면 안 됩니다. 다중 네트워크 인터페이스 인스턴스의 네트워크 인터페이스를 둘 이상 미러링해야 하는 경우 각 인터페이스가 고유한 VPC 네트워크에 연결되므로 인터페이스마다 하나의 패킷 미러링 정책을 만들어야 합니다.

가격 책정

패킷 미러링에서 처리되는 데이터 양에 대해 요금이 부과됩니다. 자세한 내용은 패킷 미러링 가격 책정을 참조하세요.

패킷 미러링과 관련된 모든 기본 요건 구성요소 및 이그레스 트래픽에 대해서도 요금이 부과됩니다. 예를 들어 트래픽을 수집한 인스턴스에는 일반 요율에 따라 요금이 부과됩니다. 또한 영역 간에 주고 받는 패킷 미러링 트래픽이 있으면 이그레스 트래픽에 요금이 부과됩니다. 자세한 가격 정보는 관련 가격 책정 페이지를 참조하세요.

다음 단계

• 패킷 미러링 사용
• 패킷 미러링 모니터링
• 내부 패스 스루 네트워크 부하 분산기 개요
• 패킷 미러링 파트너 제공업체
• 대역 외 통합 개요