Google Cloud 부하 분산기에는 일반적으로 클라이언트의 트래픽이 백엔드에 도달하도록 하나 이상의 방화벽 규칙이 필요합니다.
대부분의 부하 분산기에서 백엔드 인스턴스의 상태 점검을 지정해야 합니다. 상태 점검 프로브가 백엔드에 도달하려면 상태 점검 프로브가 백엔드 인스턴스에 도달할 수 있도록 인그레스 허용 방화벽 규칙을 만들어야 합니다.
Google 프런트엔드(GFE)를 기반으로 하는 부하 분산기에는 GFE 프록시의 트래픽이 백엔드 인스턴스에 도달하도록 허용하는 인그레스 허용 방화벽 규칙이 필요합니다. 대부분의 경우 GFE 프록시는 상태 점검 프로브와 동일한 소스 IP 범위를 사용하므로 별도의 방화벽 규칙이 필요하지 않습니다.
예외는 다음 표에 표시되어 있습니다.
오픈소스 Envoy 프록시를 기반으로 하는 부하 분산기에서는 프록시 전용 서브넷의 트래픽이 백엔드 인스턴스에 도달하도록 허용하는 인그레스 허용 방화벽 규칙이 필요합니다. 이러한 부하 분산기는 수신 연결을 종료하며 이후 부하 분산기에서 백엔드로 전송되는 트래픽이 프록시 전용 서브넷의 IP 주소에서 전송됩니다.
다음 표에는 각 부하 분산기 유형에 필요한 최소 필요 방화벽 규칙이 요약되어 있습니다.
부하 분산기 유형
최소 필수 인그레스 허용 방화벽 규칙
개요
예
전역 외부 애플리케이션 부하 분산기
상태 점검 범위
35.191.0.0/16
130.211.0.0/22
백엔드로 들어오는 IPv6 트래픽:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
GFE 프록시 범위:
백엔드가 인스턴스 그룹, 영역별 NEG(GCE_VM_IP_PORT) 또는 하이브리드 연결 NEG(NON_GCP_PRIVATE_IP_PORT)인 경우 상태 점검 범위와 동일합니다.
_cloud-eoips.googleusercontent.com DNS TXT 레코드에 나열된 IP 주소 범위입니다. Linux 시스템에서 다음 명령어 예시를 사용하여 글로벌 인터넷 NEG 백엔드의 소스 IP 주소를 추출할 수 있습니다.
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
백엔드가 인스턴스 그룹, 영역별 NEG(GCE_VM_IP_PORT) 또는 하이브리드 연결 NEG(NON_GCP_PRIVATE_IP_PORT)인 경우 상태 점검 범위와 동일합니다.
_cloud-eoips.googleusercontent.com DNS TXT 레코드에 나열된 IP 주소 범위입니다. Linux 시스템에서 다음 명령어 예시를 사용하여 글로벌 인터넷 NEG 백엔드의 소스 IP 주소를 추출할 수 있습니다.
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
인터넷의 클라이언트 외부 소스 IP 주소입니다.
예를 들어 0.0.0.0/0(모든 IPv4 클라이언트), ::/0(모든 IPv6 클라이언트) 또는 특정 IP 주소 범위 집합입니다.
대상 풀 기반 부하 분산기는 메타데이터 서버를 통해 상태 점검을 프록시할 수 있습니다. 이 경우 상태 점검 프로브 소스는 메타데이터 서버의 IP 주소 169.254.169.254와 일치합니다. 하지만 메타데이터 서버의 트래픽은 항상 VM에 도달할 수 있습니다. 방화벽 규칙은 필요하지 않습니다.
1 하이브리드 NEG에는 Google의 상태 점검 프로브 범위에서 오는 트래픽을 허용할 필요가 없습니다. 하지만 단일 백엔드 서비스에서 하이브리드 및 영역별 NEG 조합을 사용하는 경우 영역별 NEG에 대한 Google 상태 점검 프로브 범위의 트래픽을 허용해야 합니다.
2
리전 인터넷 NEG의 경우 상태 점검은 선택사항입니다. 리전별 인터넷 NEG를 사용하는 부하 분산기에서 오는 트래픽은 프록시 전용 서브넷에서 시작되며 수동 또는 자동으로 할당된 NAT IP 주소로 NAT 변환됩니다(Cloud NAT 사용). 이 트래픽에는 상태 확인 프로브와 부하 분산기에서 백엔드로의 사용자 요청이 포함됩니다. 자세한 내용은 리전 NEG: Cloud NAT 게이트웨이 사용을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Firewall rules\n\nGoogle Cloud load balancers typically require one or more firewall rules\nto ensure that traffic from clients reaches the backends.\n\n- Most load balancers are required to specify a health check for backend\n instances. For the health check probes to reach your backends, you must create\n an ingress allow [firewall rule](/firewall/docs/using-firewalls) that allows\n health check probes to reach your backend instances.\n\n- Load balancers based on Google Front Ends (GFEs) require an ingress allow\n firewall rule that permits traffic from the GFE proxy to reach the backend\n instances. In most cases, GFE proxies use the same source IP ranges as the\n health check probes and therefore don't require a separate firewall rule.\n Exceptions are noted in the following table.\n\n- Load balancers based on the open source Envoy proxy require an ingress allow\n firewall rule that permits traffic from the *proxy-only subnet* to reach the\n backend instances. These load balancers terminate incoming connections and\n traffic from the load balancer to the backends is then sent from IP addresses\n in the proxy-only subnet.\n\nThe following table summarizes the minimum required firewall rules for each\ntype of load balancer.\n\n^1^\nAllowing traffic from Google's health check probe ranges isn't required for hybrid\nNEGs. However, if you're using a combination of hybrid and zonal NEGs in\na single backend service, you need to allow traffic from the [Google\nhealth check probe ranges](/load-balancing/docs/health-check-concepts#ip-ranges) for the zonal NEGs.\n\n^2^\nFor regional internet NEGs, health checks are optional. Traffic from load\nbalancers using *regional* internet NEGs originates from the [proxy-only subnet](/load-balancing/docs/proxy-only-subnets) and is then\nNAT-translated (by using Cloud NAT) to either manually or automatically allocated\nNAT IP addresses. This traffic includes both health check probes and user\nrequests from the load balancer to the backends. For details, see [Regional NEGs:\nUse a Cloud NAT gateway](/load-balancing/docs/negs/internet-neg-concepts#nat-support)."]]
