Resolver problemas do Cloud DNS

Esta página fornece soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS para criar zonas públicas, zonas particulares,zonas de pesquisa reversa, zonas de encaminhamento e registros de recurso.

Zonas públicas

Nesta seção, abordamos os problemas com as zonas públicas.

Não é possível criar uma zona pública

Se você receber um erro attempted action failed, isso significa que a API Cloud DNS não está ativada no seu projeto.

Para ativar a API Cloud DNS, siga estas etapas:

  1. No console do Google Cloud , acesse a página Biblioteca de APIs.

    Acessar a Biblioteca de APIs

  2. Em Selecionar um projeto recente, selecione o projeto Google Cloud em que você quer ativar a API.

  3. Na página Biblioteca de APIs, use a caixa Pesquisar APIs e serviços para pesquisar Cloud DNS API. Será exibida uma página descrevendo a API.

  4. Clique em Ativar.

Zonas particulares

Nesta seção, são abordados os problemas com as zonas particulares.

Problemas de zona particular em projetos de serviço de VPC compartilhada

Para informações importantes sobre o uso de zonas particulares com redes VPC compartilhadas, consulte Zonas particulares e VPC compartilhada.

Não é possível criar uma zona particular/listar ou criar políticas

É necessário ter o papel de administrador do DNS para executar várias ações em zonas particulares, como listar as políticas do servidor do Sistema de Nome de Domínio (DNS, na sigla em inglês) ou criar uma zona desse tipo. Esse papel é concedido por meio da ferramenta Gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Zonas particulares não resolvidas na mesma rede VPC

Primeiro, verifique se você está realizando o teste na mesma rede.

Verifique se a interface principal da instância de VM está na mesma rede que a zona particular que você criou.

Uma instância de máquina virtual (VM) envia todo o tráfego da interface principal, a menos que ele seja destinado a uma sub-rede anexada a uma das outras interfaces ou se a VM tiver o roteamento de política configurado. Verifique se a VM de teste tem a interface principal na mesma rede que a zona particular que você está testando.

Determine se sua VM está usando:

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

Verifique se a rede está na lista de redes autorizadas para consultar a zona particular:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

Verificar se o nome DNS na consulta corresponde à zona

OGoogle Cloud resolve um registro de acordo com a ordem de resolução de nomes, usando a zona com o sufixo mais longo para decidir qual zona consultar para um determinado nome de DNS. Verifique se o sufixo do registro que você está consultando corresponde a pelo menos uma zona particular acessível na sua rede VPC. Por exemplo, Google Cloudprimeiro procura myapp.dev.gcp.example.lan em uma zona que atende a dev.gcp.example.lan, se acessível, antes de procurar em uma zona que atende a gcp.example.lan, se acessível.

A saída do comando a seguir mostra o sufixo DNS de uma determinada zona particular:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

Consultar o nome DNS usando o servidor de metadados

Use dig para enviar a consulta de nome DNS diretamente ao servidor de metadados do Google Cloud, 169.254.169.254:

dig DNS_NAME @169.254.169.254

Use dig para consultar o servidor de nomes padrão da VM:

dig DNS_NAME

Se a saída dos dois comandos dig produzir respostas diferentes, verifique a seção ;; SERVER: do segundo comando. O servidor que responde precisa ser o de metadados: 169.254.169.254. Se não for, você configurou o sistema operacional convidado para usar um servidor de nomes DNS personalizado em vez do servidor de metadadosGoogle Cloud padrão. As zonas particulares do Cloud DNS exigem que você use o servidor de metadados na resolução de nomes. Os ambientes de convidado do Linux e do Windows fazem isso por você. Se você importou a imagem que está usando para uma VM, verifique se o ambiente convidado apropriado foi instalado.

Zonas particulares não resolvidas por meio do Cloud VPN ou Cloud Interconnect

Primeiro, verifique se você consegue consultar e resolver o nome de DNS em uma rede VPC autorizada.

Verifique a conectividade por meio do Cloud VPN ou Cloud Interconnect

Garanta que a conectividade de um sistema local com rede VPC esteja funcionando. Especificamente, o tráfego TCP e UDP na porta 53 precisa ser capaz de sair da rede local e ser entregue à rede VPC. Verifique a configuração dos firewalls locais para garantir que esse tráfego de saída seja permitido.

É possível usar qualquer protocolo, como o ping (ICMP), para testar a conectividade do ambiente local com uma VM de exemplo na rede VPC. Embora as solicitações do Cloud DNS não sejam enviadas para VMs do Google Cloud , testar a conectividade com uma VM de amostra permite verificar a conectividade por um túnel do Cloud VPN ou uma conexão do Cloud Interconnect. Configure uma regra de firewall de permissão de entrada adequada para a VM de amostraGoogle Cloud , porque, caso contrário, a regra de negação de entrada implícita vai bloquear todo o tráfego de entrada.

Garanta que o encaminhamento de entrada esteja ativado na rede VPC autorizada

O encaminhamento de entrada precisa estar ativado em cada rede VPC autorizada a consultar a zona particular do Cloud DNS. Use o comando a seguir para listar todas as políticas:

gcloud dns policies list

Identifique a rede na tabela de saída e verifique o campo Encaminhamento para ver se ele está ativado.

Verifique se a rede autorizada é uma rede VPC

O encaminhamento de DNS requer sub-redes, que estão disponíveis apenas para redes VPC, e não para redes legadas.

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

As redes legadas são identificadas na saída como LEGACY.

Verifique se há um endereço de encaminhamento de DNS válido reservado na rede

O comando a seguir mostra todos os endereços IP de encaminhamento de DNS reservados no projeto.

gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER" \
    --format='csv[no-heading](address, subnetwork)'

É possível adicionar uma cláusula AND ao filtro para limitar a saída apenas à sub-rede relevante.

Exemplo:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

Se você não encontrar um endereço IP na rede ou região esperada, abra um tíquete com o suporte daGoogle Cloud .

Execute o comando dig que aponta a consulta no endereço encontrado no comando anterior. Para isso, use uma VM na mesma rede. Esse teste verifica se o encaminhamento de entrada está funcionando e se o problema está em outro lugar.

dig DNS_NAME @10.150.0.1 # address returned by previous command

Repita o mesmo comando dig, mas a partir de um host local na VPN.

O registro CNAME definido em uma zona particular não está funcionando

O Cloud DNS busca apenas registros CNAME, conforme descrito em Busca de CNAME.

Zonas de pesquisa inversa

Nesta seção, você encontra dicas de solução de problemas com zonas de pesquisa inversa. Alguns problemas de zona particular também se aplicam a zonas de pesquisa inversa. Para ver mais dicas, consulte a seção de solução de problemas em Zonas particulares.

VM com endereço não RFC 1918 não resolvida

Se você tiver um endereço não RFC 1918, reconcilie a VM.

Reconcilie sua VM com um endereço não RFC 1918

Se você criou uma VM durante a versão Alfa não RFC 1918, antes do Cloud DNS oferecer compatibilidade, talvez a VM não seja resolvida corretamente. Para resolver esse problema, reinicie as VMs.

Zonas de encaminhamento

Nesta seção, você encontra dicas de solução de problemas para zonas de encaminhamento. Alguns problemas da zona particular também se aplicam a zonas de encaminhamento. Para ver mais dicas, consulte a seção de solução de problemas em Zonas particulares.

As zonas de encaminhamento (de saída) não estão funcionando

Primeiro, verifique se você consegue consultar e resolver o nome de DNS em uma rede VPC autorizada.

O encaminhamento de consultas de VMs em uma rede VPC consumidora para produtora não está funcionando

Se você estiver usando o peering de DNS e quiser encaminhar consultas de VMs em uma rede VPC de consumidor para uma rede VPC de produtor e, em seguida, para um ou mais servidores de nomes locais, verifique se um dos seguintes pré-requisitos foi atendido:

  • A rede VPC do produtor tem o modo de roteamento dinâmico definido como GLOBAL.

  • A VM na rede VPC do consumidor está na mesma região que o túnel de VPN ou o Cloud Interconnect na VPC do produtor.

  • (Somente rotas estáticas ou próximos saltos personalizados) A rede VPC do produtor tem uma rota estática configurada para enviar tráfego destinado aos servidores de nomes locais pelo túnel de VPN clássica, uma VPN autogerenciada ou um gateway não BGP. A rede VPC do produtor também precisa ter uma VM ou um túnel de VPN na mesma região da sub-rede usada pelas VMs do cliente.

    • Por exemplo, suponha que a VPC1 use uma zona de peering que envia consultas para example.com. a VPC2. Suponha também que a VPC2 tenha uma zona de encaminhamento particular para example.com. que encaminha as consultas a um servidor de nomes local usando um túnel de VPN clássica.

      Para que uma VM localizada em us-east1 na VPC1 consiga consultar example.com., a VPC2 precisa ter uma VM em us-east1. Uma rota estática também precisa ser configurada para abranger os intervalos CIDR dos servidores de nomes locais, com o próximo salto configurado como o túnel de VPN clássica.

      Verifique a conectividade por meio do Cloud VPN ou Cloud Interconnect

É possível usar qualquer protocolo, como o ping (ICMP), para testar a conectividade do ambiente local com uma VM de exemplo na rede VPC. Você também precisa tentar consultar o servidor de nomes local diretamente de uma VM de amostra doGoogle Cloud usando uma ferramenta como dig:

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

Verifique as regras de firewall na rede VPC

A regra de firewall de permissão de saída implícita permite conexões de saída e respostas estabelecidas de VMs na rede VPC, a menos que você tenha criado regras personalizadas para negar a saída. Nesse caso, é necessário criar regras de permissão com prioridade mais alta que autorizem a saída para pelo menos os servidores de nomes locais.

Verificar o firewall local

Verifique se o firewall local está configurado para permitir tráfego de entrada e saída em 35.199.192.0/19.

Confira os registros no firewall local e procure as solicitações de DNS de 35.199.192.0/19. Para usar uma expressão regex na pesquisa, use o seguinte:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Verifique o servidor de nomes local

Verifique se não há nenhuma ACL configurada no servidor de nomes local que bloqueie consultas de 35.199.192.0/19.

Confira o servidor de nomes local para ver se ele está recebendo pacotes de 35.199.192.0/19. Se você tiver acesso ao shell, poderá usar uma ferramenta como tcpdump para procurar pacotes de entrada e de saída em 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Verificar rotas de retorno

Sua rede local precisa ter uma rota para o destino 35.199.192.0/19 com o próximo salto sendo um túnel VPN ou conexão Interconnect para a mesma rede VPC que enviou a solicitação DNS. Este comportamento é descrito em Como criar zonas de encaminhamento.

Se você usar vários túneis VPN para conectar a mesma rede VPC à local, a resposta não precisará ser entregue usando o mesmo túnel que a enviou. No entanto, a resposta precisa ser entregue usando um túnel VPN com o próximo salto na mesma rede VPC em que a solicitação foi originada.

Se você conectou mais de uma rede VPC à sua rede local, verifique se as respostas de DNS não são enviadas para a rede errada.O Google Cloud descarta as respostas de DNS enviadas para a rede VPC errada. Para uma solução recomendada, consulte nosso guia de Práticas recomendadas.

Falha no encaminhamento de saída para um servidor de nomes que usa um endereço IP não RFC 1918

Por padrão, o Cloud DNS usa o roteamento padrão, que encaminha as consultas pela Internet pública quando o servidor de nomes de destino tem um endereço IP não RFC 1918. O roteamento padrão não é compatível com consultas de encaminhamento para servidores de nomes com endereços não RFC 1918 que não são acessíveis na Internet pública.

Para encaminhar consultas para um servidor de nomes que usa um endereço IP não RFC 1918 por meio da sua rede VPC, configure a zona de encaminhamento ou a política de servidor do Cloud DNS de modo a usar o roteamento privado para o servidor de nomes de destino.

Para ver uma explicação sobre as diferenças entre o roteamento padrão e o particular, consulte Destinos de encaminhamento e métodos de roteamento.

Esta limitação se aplica mesmo se houver uma rota de VPC para o servidor de nomes de destino. Quando o roteamento padrão está configurado, as rotas para endereços não RFC 1918 não afetam o comportamento do encaminhamento de saída do Cloud DNS.

Falha no encaminhamento de saída para uma placa de rede secundária

Verifique se você configurou corretamente seu controlador de interface de rede (NIC) secundário.

Para instruções sobre como configurar NICs adicionais, consulte Como criar instâncias de máquina virtual com várias interfaces de rede.

As consultas de encaminhamento de saída recebem erros SERVFAIL

Se o Cloud DNS receber um erro de todos os servidores de nomes de destino ou não receber uma resposta de nenhum dos servidores de nomes de destino, ele retornará um erro SERVFAIL.

Para resolver este problema, verifique se os servidores de nomes locais estão configurados corretamente. Em seguida, verifique se os servidores de nomes locais respondem às consultas do intervalo de endereços do Cloud DNS descrito em Abrir Google Cloud e firewalls locais para permitir o tráfego de DNS em até quatro segundos. Por exemplo, se os servidores de nomes locais consultarem servidores de nomes upstream por estarem configurados como resolvedores de armazenamento em cache, verifique se não há problemas com servidores de nomes upstream.

Além disso, se o destino do encaminhamento for um sistema local, saiba que as rotas configuradas para esse caminho podem ser rotas dinâmicas personalizadas ou rotas estáticas personalizadas, com a importante exceção de rotas estáticas personalizadas com as tags de rede que não são válidas para encaminhar consultas DNS. Certifique-se de que a rota usada para acessar o servidor de nomes local não especifique uma tag de rede.

Registros de recurso

Nesta seção, você encontra dicas de solução de problemas para registros de recurso.

Dados inesperados ao consultar conjuntos de registros de recurso presentes na zona

Há vários motivos para você receber dados inesperados ao consultar conjuntos de registros de recursos presentes em uma zona gerenciada do Cloud DNS:

  1. Os conjuntos de registros de recurso criados com a sintaxe @ especificada em RFC 1035 não são compatíveis. O Cloud DNS interpreta de forma literal o símbolo @ nesses conjuntos de registros de recurso. Portanto, na zona example.com., um conjunto de registros criado para o QNAME @ é interpretado como @.example.com. em vez de example.com.. Para resolver esse problema, crie conjuntos de registros sem o símbolo @. Todos os nomes são relativos ao apex da zona.

  2. Como todos os outros, os registros CNAME de caractere curinga estão sujeitos às regras de existência descritas na RFC 4592 (em inglês): por exemplo, suponha que você definiu os conjuntos de registros a seguir na zona example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    Uma consulta para public.srv1.images.example.com. retorna NOERROR com uma seção de resposta vazia. A existência de um registro entre o CNAME e o QNAME impede que o CNAME seja retornado, mas não há registro que corresponda exatamente ao QNAME. Sendo assim, o Cloud DNS retornará uma resposta vazia. Este é o comportamento de DNS padrão.

Google Cloud A VM mostra registros de ponteiro (PTR) incorretos

Quando uma VM é migrada durante um evento de manutenção, a lógica do registro PTR não lida com alguns casos extremos corretamente e reverte os registros PTR de DNS para o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) googleusercontent.com. Para restaurar a funcionalidade, aplique o registro PTR novamente.

Para detalhes sobre como aplicar registros PTR em uma VM, consulte Como criar um registro PTR para uma instância de VM.

Conjuntos de registros de recurso do Cloud DNS retornados em ordem aleatória

De acordo com as práticas do setor de DNS, agora os servidores de nomes do Cloud DNS definem a ordem dos conjuntos de registros de recurso em ordem aleatória e ignoram a ordem determinada pelo servidor autoritativo. Este é um comportamento de DNS normal e se aplica a zonas públicas e privadas do Cloud DNS.

Tipo de recurso zonal incompatível

Quando você insere a sinalização --location em um comando gcloud ou solicitação de API de um recurso que segmenta uma zona diferente do Cloud DNS, a solicitação é rejeitada. Por exemplo, se você enviar uma solicitação de recurso somente por zona a um servidor global ou uma solicitação de recurso somente global para um servidor zonal, o servidor rejeitará a solicitação e fornecerá um erro _UNSUPPORTED_ZONAL_RESOURCETYPE.

Para ver uma lista de recursos e funcionalidades compatíveis com o Cloud DNS por zona, consulte Compatibilidade com o Cloud DNS por zona.

Detecção avançada de ameaças

Nesta seção, apresentamos informações sobre problemas que podem ocorrer ao usar o DNS Armor e sugestões de como corrigir cada um deles.

As métricas mostram que nenhuma ou poucas consultas DNS estão sendo enviadas ao detector de ameaças

Primeiro, verifique se você tem um detector de ameaças de DNS.

Verificar o detector de ameaças de DNS

  1. No console do Google Cloud , acesse a página Detecção avançada de ameaças.

    Acessar a detecção avançada de ameaças

  2. Verifique se você tem um detector de ameaças listado.

Verificar o suporte regional

  1. Verifique se Locais contém a região que atende às consultas DNS do fluxo de trabalho.

Verificar se você tem consultas vinculadas à Internet

Os registros de consulta só são enviados quando consultas ou solicitações vinculadas à Internet são feitas na sua rede.

  1. No console do Google Cloud , acesse a página "Monitoring".

    Acessar Monitoring

  2. Em Métrica, selecione Cloud DNS Query e escolha Query e DNS response counts.

  3. Confira as métricas dos tipos de segmentação que estão vinculados à Internet.

Como alternativa, se você tiver ativado o Cloud Logging para consultas DNS, use a Análise de registros para verificar se há consultas vinculadas à Internet.

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar a Análise de registros

  2. Confira os registros DNS e verifique as consultas vinculadas à Internet.

Os logs de eventos de ameaça não são retornados

Se os eventos de ameaça não forem recebidos pelo Cloud Logging, primeiro verifique se um detector de ameaças avançado está configurado no Painel. Os logs de eventos de ameaça só são retornados quando uma ameaça é detectada.

Verificar se a detecção de ameaças está ativada

  1. No console do Google Cloud , acesse a página Detecção avançada de ameaças.

    Acessar a detecção avançada de ameaças

  2. Verifique se há um detector de ameaças listado.

Os eventos de ameaças de DNS não são gerados para alguns domínios abusivos ou ruins

Alguns eventos de ameaça de DNS para domínios abusivos ou ruins podem não ser gerados para domínios obtidos de listas públicas de domínios ruins na Internet, já que os domínios de ameaça de DNS mudam com frequência. Domínios antigos ou expirados dessas listas não geram eventos de ameaça de DNS.

Estes são domínios de teste que você pode usar para verificar domínios de ameaças de DNS:

  • dnst-gcp-blox.com
  • ftags-gcp-blox.com
  • dga-gcp-blox.com

Verificar se os eventos de ameaça de DNS são gerados para domínios de teste

  1. Faça login em uma VM que faça parte do projeto que você está monitorando.

  2. Abra um terminal e execute um comando dig para um dos domínios de teste. 

    domain=TEST_DOMAIN 
    
dig $domain -t A

    Substitua TEST_DOMAIN por um dos domínios listados.

  3. Abra o console do Google Cloud e acesse a página Análise de registros.

    Acessar a Análise de registros

  4. Execute a seguinte consulta: resource.type="networksecurity.googleapis.com/DnsThreatDetector"

  5. Pesquise o domínio de teste que você usou no comando dig.

    Esses domínios geram eventos de ameaça de DNS. Se você não encontrar os registros DNS dos domínios listados, entre em contato com o suporte.

Endpoints de saída

Nesta seção, descrevemos os problemas que podem ser encontrados ao usar endpoints de saída e como resolvê-los.

As consultas DNS não estão sendo encaminhadas para os servidores de destino

Há várias causas possíveis para esse problema.

Configuração incorreta de recursos

Seu endpoint e a zona de encaminhamento ou a política do servidor precisam estar configurados corretamente. Isso inclui a associação do endpoint à rede VPC e à região corretas ou a configuração da zona de encaminhamento ou da política de servidor para usar os endpoints de saída certos.

Verifique se a sub-rede somente proxy regional está configurada corretamente e tem endereços IP suficientes disponíveis para consultas de proxy. Também é possível ativar o registro em log de consultas e verificar o campo jsonPayload.egressPath. Esse campo é definido como OUTBOUND_ENDPOINT se a consulta encaminhada estiver usando endpoints de saída. Se os registros de consulta não incluírem esse campo ou se ele não estiver definido como OUTBOUND_ENDPOINT, o tráfego será padronizado como 35.199.192.0/19.

Para verificar sua configuração, execute o comando gcloud beta dns outbound-endpoints describe:

gcloud beta dns outbound-endpoints describe ENDPOINT_NAME \
    --project=PROJECT_ID \
    --location=REGION

Substitua:

  • ENDPOINT_NAME: nome do endpoint.
  • PROJECT_ID: ID do projeto
  • REGION: região em que o endpoint está localizado.

Conectividade de rede

Verifique se há uma rota da rede VPC para os servidores DNS locais ou remotos e se as regras de firewall locais permitem o tráfego da porta TCP/UDP 53 do intervalo de IP da sub-rede somente proxy. Verifique também se há uma rota da rede local de volta para o intervalo de IP da sub-rede somente proxy.

Problema de peering ou VPC compartilhada

  • Problema da VPC compartilhada: os endpoints de saída precisam ser criados no projeto host em que a rede VPC e as sub-redes da VPC compartilhada estão localizadas. Ao associar uma zona de encaminhamento ou uma política de servidor DNS em um projeto de serviço com um endpoint de saída no projeto host, verifique se o usuário tem dns.outboundEndpoints.bindPrivateDNSZone ou dns.outboundEndpoints.bindPrivateDNSPolicy no projeto host.
  • Problema de peering: verifique se o status do peering de rede VPC está definido como Active.

Verifique também se as rotas e as regras de firewall permitem o tráfego DNS (porta UDP e TCP 53) entre o intervalo de IP da sub-rede somente de proxy regional na rede VPC do endpoint e os servidores DNS de destino.

Tempo limite das consultas DNS

As seções a seguir descrevem por que as consultas DNS podem expirar ao usar endpoints de saída.

Problema de latência de rede entre o endpoint de saída e os servidores de destino

Verifique a latência entre sua rede VPC e os servidores DNS de destino. Mover os servidores DNS de destino para mais perto do projeto doGoogle Cloud também pode ajudar.

Esgotamento da sub-rede somente proxy

Verifique a utilização do endereço IP da sub-rede somente proxy na região em que as consultas estão falhando com o Monitoring. Se a sub-rede estiver quase esgotada, migre para uma sub-rede somente proxy maior seguindo as etapas em Modificação de sub-rede.

Configuração incorreta da política de geolocalização

Verifique se a política de roteamento por geolocalização tem uma entrada para a região em que o endpoint de saída está localizado. Verifique também se o destino do FQDN na zona de encaminhamento corresponde ao nome DNS da zona da política de geolocalização.

Não é possível criar um endpoint de saída

As seções a seguir descrevem por que talvez não seja possível criar um endpoint de saída.

Problema de permissão do IAM

Verifique se a conta de usuário ou de serviço tem os papéis roles/dns.admin e roles/compute.networkAdmin (ou permissões para dns.outboundEndpoints.create, compute.networks.get, compute.subnetworks.get e compute.subnetworks.use). Para uma VPC compartilhada, os endpoints de saída precisam ser criados no projeto host (não é possível criar um endpoint de saída em um projeto de serviço).

A string de endereço IP fornecida em endpointIp não corresponde ao intervalo CIDR da sub-rede normal especificada ou está corrompida

Verifique o intervalo CIDR da sub-rede regular especificada na região de destino e confira se a string IP fornecida em endpointIp (--endpoint-ip) está dentro do intervalo CIDR principal da sub-rede. Verifique também se o endereço IP não é um endereço reservado na sub-rede (por exemplo, gateway ou transmissão).

A string de endereço IP fornecida é válida, mas já está em uso por outro recurso

Verifique no console Google Cloud os endereços IP da sua rede VPC ou use o comando gcloud compute addresses list e forneça um endereço IPv4 não alocado diferente da sub-rede normal com --endpoint-ip.

O sistema não encontrou uma sub-rede regional ativa somente proxy

Verifique se existe uma sub-rede regional ativa somente proxy na rede VPC e na região especificadas. Se não houver uma, crie uma sub-rede regional somente proxy (mínimo /26) com --purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE (consulte Sub-redes somente proxy para balanceadores de carga baseados no Envoy).

Falha na exclusão de recursos

Se não for possível excluir um recurso, talvez ele esteja sendo usado por um endpoint de saída.

Tentativa de excluir um recurso que está em uso ativo

Siga as etapas descritas em Gerenciar recursos de rede associados a endpoints de saída.

A seguir