Resolva problemas de configuração
Este guia pode ajudar a resolver problemas comuns com o Cloud NAT.
Problemas comuns
As VMs podem aceder à Internet inesperadamente, sem o Cloud NAT
Se as suas instâncias de máquinas virtuais (VM) ou instâncias de contentores conseguirem alcançar a Internet sem o Cloud NAT, mas não quiser que o façam, verifique os seguintes problemas:
Determine se a interface de rede da VM tem um endereço IP externo. Se a interface de rede tiver um endereço IP externo atribuído, Google Cloudfaz automaticamente um NAT individual para pacotes cujas origens correspondam ao endereço IP interno principal da interface. Para mais informações, consulte as especificações do Cloud NAT.
Para determinar se uma VM tem um endereço IP externo, consulte o artigo alterar ou atribuir um endereço IP externo a uma instância existente.
Certifique-se de que o seu cluster do Google Kubernetes Engine (GKE) é um cluster privado. Cada VM de nó num cluster não privado tem um endereço IP externo, pelo que cada nó pode usar rotas na sua rede de nuvem virtual privada (VPC) cujo próximo salto é a gateway de Internet predefinida sem depender do Cloud NAT. Para mais informações, incluindo como os clusters não privados interagem com gateways do Cloud NAT, consulte Interação do Compute Engine.
Liste as rotas na sua rede da nuvem virtual privada e procure as que possam fornecer conetividade à Internet através de um próximo salto diferente do gateway de Internet predefinido. Exemplos:
As rotas estáticas cujos saltos seguintes são VMs, balanceadores de carga de passagem interna de rede ou túneis do Cloud VPN podem fornecer indiretamente conetividade à Internet. Por exemplo, as VMs de salto seguinte ou as VMs de back-end de um balanceador de carga de rede de encaminhamento interno podem ter endereços IP externos ou um túnel do Cloud VPN pode ligar-se a uma rede que oferece acesso à Internet.
As rotas dinâmicas aprendidas com redes no local pelos Cloud Routers na sua rede VPC podem ligar-se a uma rede que oferece acesso à Internet.
Tenha em atenção que outras rotas personalizadas na sua rede VPC podem ter prioridades mais elevadas do que as rotas cujos saltos seguintes são gateways de Internet predefinidos. Para informações sobre como o Google Maps Google Cloud avalia os trajetos, consulte a aplicabilidade e a ordem de encaminhamento.
Não são gerados registos
- Verifique se o registo de NAT está ativado.
Verifique novamente se a sua vista dos registos não está a filtrar os registos que procura. Para ver instruções, consulte a secção Ver registos.
Certifique-se de que nenhuma regra de firewall está a bloquear o tráfego. As regras de firewall que bloqueiam o tráfego de saída são aplicadas antes de o tráfego ser enviado para o gateway NAT. Pode usar o registo de regras de firewall para ver se as suas regras de saída personalizadas estão a bloquear o tráfego de saída.
Reveja os tipos de Cloud NAT. O destino do seu tráfego pode não ser processado pelo NAT.
Determinados registos são excluídos
Verifique se o registo de NAT está ativado e se o filtro de registo não está a excluir registos que quer manter. Pode limpar um filtro de registos para que nada seja excluído.
O Cloud NAT não regista todos os eventos. Durante períodos de tráfego de saída intenso, o registo de NAT é limitado, proporcionalmente ao tipo de máquina da VM. Os registos de tradução ou de erros podem ser ignorados e não é possível determinar o que é omitido durante a limitação.
Pacotes ignorados com o motivo: sem recursos
Se vir perda de pacotes de VMs que usam o Cloud NAT, isto pode dever-se ao facto de não existirem tuplos de endereço IP de origem e porta de origem da NAT suficientes para a VM usar no momento da perda de pacotes (esgotamento de portas). Não é possível reutilizar uma tupla de cinco elementos (endereço IP de origem da NAT, porta de origem e tupla de 3 elementos de destino) no tempo limite TCP TIME_WAIT.
Se não existirem tuplos NAT disponíveis suficientes, o dropped_sent_packets_count
motivo é
OUT_OF_RESOURCES. Para mais informações sobre as métricas, consulte o artigo Usar métricas de instâncias de VM.
Consulte o artigo Reduza a utilização de portas para saber como reduzir a utilização de portas.
Se usar a atribuição dinâmica de portas, consulte a secção seguinte para ver formas de reduzir as perdas de pacotes quando a atribuição dinâmica de portas é usada.
Pacotes rejeitados quando a atribuição dinâmica de portas está configurada
A atribuição dinâmica de portas deteta quando uma VM está prestes a ficar sem portas e duplica o número de portas atribuídas à VM. Isto ajuda a garantir que as portas não são desperdiçadas, mas pode resultar em pacotes perdidos enquanto o número de portas atribuídas aumenta.
Para reduzir o número de pacotes perdidos, considere o seguinte:
Se puder aumentar as ligações mais lentamente, o Cloud NAT tem mais tempo para atribuir mais portas.
Se as VMs estiverem a estabelecer ligações TCP, pode configurá-las com um valor maior para
tcp_syn_retries, o que dá ao sistema mais tempo para estabelecer a ligação e aumenta as probabilidades de sucesso da mesma.Por exemplo, para VMs Linux, pode ver a definição atual:
sysctl net.ipv4.tcp_syn_retries
Se necessário, pode aumentar a definição:
sudo sysctl -w net.ipv4.tcp_syn_retries=NUM
Se tiver cargas de trabalho intermitentes e precisar de atribuir rapidamente mais portas, pode ter de ajustar o número mínimo de portas por VM. Veja a utilização de portas e determine um número mínimo adequado de portas por MV.
Pacotes rejeitados com o motivo: endpoint independence conflict
Se vir perda de pacotes de VMs que usam NAT público e tiver o mapeamento independente do ponto final ativado, a perda de pacotes pode ser causada por um conflito independente do ponto final. Se for o caso, o
dropped_sent_packets_count
motivo é
ENDPOINT_INDEPENDENCE_CONFLICT. Para mais informações sobre as métricas, consulte o artigo Usar métricas de instâncias de VM.
Pode reduzir as probabilidades de conflitos independentes do ponto final através das seguintes técnicas:
Desative o mapeamento independente do ponto final. Isto permite que a nova ligação de um determinado endereço IP de origem e porta use um endereço IP de origem e uma porta NAT diferentes dos que usou anteriormente. A desativação ou a ativação do mapeamento independente do ponto final não interrompe as ligações estabelecidas.
Aumente o número mínimo predefinido de portas NAT por instância de VM, para que o procedimento de reserva de portas possa atribuir mais tuplos de endereço IP de origem e porta de origem NAT a cada VM cliente. Isto diminui a probabilidade de que duas ou mais tuplas de endereço IP do cliente e porta de origem temporária sejam atribuídas à mesma tupla de endereço IP de origem e porta de origem NAT.
Verifique quantas portas de origem efémeras estão a ser usadas:
Para VMs do Linux:
netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l
Para VMs do Windows:
netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""
Configure as suas instâncias de VM para usar um conjunto maior de portas de origem efémeras:
Para VMs do Linux:
Pode ver o intervalo de portas configurado com este comando:
cat /proc/sys/net/ipv4/ip_local_port_range
Pode definir o
ip_local_port_rangepara o número máximo de portas de origem efémeras (64 512) com este comando:echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
Para VMs do Windows:
Pode ver os intervalos de portas configurados com estes comandos:
netsh int ipv4 show dynamicport tcp netsh int ipv4 show dynamicport udp
Pode definir o número de portas TCP e UDP de origem efémeras para o máximo possível (64 512) com estes comandos:
netsh int ipv4 set dynamicport tcp start=1024 num=64512 netsh int ipv4 set dynamicport udp start=1024 num=64512
Nos nós do Google Kubernetes Engine, pode automatizar esta configuração através de um
DaemonSetprivilegiado.
Para clusters do GKE, desative o NAT de origem realizado em cada nó para pacotes enviados para destinos de interesse. Pode fazê-lo de duas formas:
Implementando o
ip-masq-agente adicionando os destinos de interesse à lista denonMasqueradeCIDRs.Desativando o SNAT para os destinos predefinidos sem ocultação de IP com a flag
--disable-default-snatquando cria um cluster.
Pacotes recebidos rejeitados
Um gateway Cloud NAT mantém uma tabela de acompanhamento de ligações para armazenar detalhes de ligações ativas e mapeamentos de endereços IP e portas, ou seja, como os endereços IP e as portas das VMs se traduzem em endereços IP e portas NAT. Um gateway NAT da nuvem rejeita um pacote de dados de entrada se a tabela de acompanhamento de ligações não contiver nenhuma entrada para a ligação.
A ausência da entrada de ligação na tabela pode dever-se a qualquer um dos seguintes motivos:
- Uma ligação TCP estabelecida excedeu o tempo limite porque o tempo limite de inatividade da ligação estabelecida TCP expirou devido a inatividade.
- Um ponto final externo não consegue estabelecer uma nova ligação antes de o tempo limite de inatividade da ligação transitória de TCP expirar. Por exemplo, um Google Cloud recurso
inicia uma ligação com
TCP SYN, mas o ponto final externo não responde com umSYN ACK. - Um ponto final externo, como um verificador, tenta estabelecer ligação a um endereço IP NAT e a uma porta. O Cloud NAT não aceita ligações de entrada não solicitadas. As entradas para este tipo de ligações não estão presentes na tabela de ligações. Assim, todos os pacotes recebidos são ignorados.
- Se remover os IPs NAT da sua gateway enquanto as ligações NAT ainda estiverem ativas, os mapeamentos NAT tornam-se inválidos e estas ligações são imediatamente removidas da tabela de acompanhamento de ligações. O tráfego de retorno é rejeitado.
Antes de resolver as quedas de pacotes de entrada, confirme se as quedas afetam realmente a sua aplicação. Para confirmar, verifique se existem erros na sua aplicação sempre que ocorrem picos nos pacotes de entrada rejeitados.
Se as quedas de pacotes de entrada afetarem a sua aplicação, experimente usar as seguintes técnicas para resolver o problema:
- Use mecanismos de manutenção ativa na sua aplicação para que as ligações de longa duração possam permanecer abertas durante mais tempo.
- Aumente o valor do tempo limite de inatividade da ligação transitória de TCP para que os pontos finais externos que recebem tráfego (iniciado por recursos) através de um gateway do Cloud NAT tenham mais tempo para responder e estabelecer a ligação. Google Cloud
- Aumente o valor de TCP Established Connection Idle Timeout se tiver diminuído significativamente o valor predefinido.
Precisa de atribuir mais endereços IP
Por vezes, as suas VMs não conseguem aceder à Internet porque não tem endereços IP NAT suficientes. Vários fatores podem causar este problema. Para mais informações, consulte a tabela seguinte.
| Motivo principal | Sintoma | Solução |
|---|---|---|
| Atribuiu manualmente endereços, mas não atribuiu o suficiente, tendo em conta a sua utilização atual de portas. |
|
Efetue um dos seguintes passos:
|
| Ultrapassou um limite rígido para endereços IP NAT. |
|
|
Para monitorizar falhas causadas por um número insuficiente de endereços IP,
crie um alerta para a métrica
nat_allocation_failed. Esta métrica é definida como true se Google Cloud não conseguir
atribuir endereços IP suficientes a qualquer VM no seu gateway NAT. Para obter informações sobre as políticas de alerta, consulte o artigo Definir políticas de alerta.
Reduza a utilização de portas
Pode minimizar o número de portas que cada VM usa em situações em que não é possível ou desejável atribuir mais endereços IP NAT.
Para reduzir a utilização de portas, conclua os seguintes passos:
Desative o mapeamento independente do ponto final.
Ative a atribuição dinâmica de portas. Para usar a atribuição dinâmica de portas, define um número mínimo de portas por VM e um número máximo de portas por VM. O Cloud NAT atribui automaticamente um número de tuplos de endereço IP de origem e porta de origem NAT entre o número mínimo e máximo de portas, inclusive. A utilização de um número baixo para o número mínimo de portas reduz o desperdício de tuplos de endereço IP de origem e porta de origem da NAT em VMs com menos ligações ativas. Se encontrar limites de tempo de ligação enquanto as portas estão a ser atribuídas, consulte o artigo Reduza as perdas de pacotes com a atribuição dinâmica de portas.
Determine o número mínimo possível de portas para satisfazer as suas necessidades. Existem vários métodos para o fazer e a maioria baseia-se na revisão do número de portas usadas (
compute.googleapis.com/nat/port_usage) como entrada para o processo de tomada de decisões. Para obter informações sobre como encontrar a utilização de portas, consulte o artigo Veja a utilização de portas. Seguem-se dois métodos de exemplo para determinar um número mínimo de portas:- Considere o valor médio de
compute.googleapis.com/nat/port_usagedurante um período representativo para um número representativo de VMs. - Considere o valor que ocorre com maior frequência de
compute.googleapis.com/nat/port_usagedurante um período representativo para um número representativo de VMs.
- Considere o valor médio de
Determine o número máximo de portas mais baixo possível para satisfazer as suas necessidades. Mais uma vez, reveja
compute.googleapis.com/nat/port_usagecomo entrada no seu processo de tomada de decisões. Considere o valor máximo decompute.googleapis.com/nat/port_usagedurante um período representativo para um número representativo de VMs como ponto de partida para o número máximo de portas. Tenha em atenção que definir um número máximo demasiado elevado pode impedir que outras VMs recebam tuplos de endereço IP de origem e porta de origem da NAT.Encontrar os valores certos para as portas mínimas e máximas envolve testes iterativos. Para ver os passos para alterar os números de portas mínimos e máximos, consulte o artigo Altere as portas mínimas ou máximas quando a atribuição dinâmica de portas estiver configurada.
Reveja os tempos limite de NAT, os respetivos significados e os valores predefinidos. Se precisar de criar rapidamente uma série de ligações TCP para a mesma tupla de 3 elementos de destino, considere reduzir o tempo de espera do TCP para que o Cloud NAT possa reutilizar mais rapidamente a tupla de endereço IP de origem e porta de origem do NAT. Isto permite que o Cloud NAT use mais rapidamente a mesma tupla de 5 elementos em vez de ter de usar uma tupla de 5 elementos única, o que pode exigir a atribuição de tuplas de porta de origem e endereço IP de origem do NAT adicionais para cada VM de envio. Para ver os passos para alterar os limites de tempo da NAT, consulte o artigo Alterar limites de tempo da NAT.
Perguntas frequentes
Restrição regional para o NAT na nuvem
Posso usar o mesmo gateway Cloud NAT em mais do que uma região?
Não. Um gateway Cloud NAT não pode ser associado a mais do que uma região, uma rede VPC ou um Cloud Router.
Se precisar de fornecer conetividade para outras regiões ou redes VPC, crie gateways Cloud NAT adicionais para as mesmas.
Os endereços IP NAT externos usados pelos gateways NAT da nuvem são globais ou regionais?
Os gateways NAT da nuvem usam endereços IP externos regionais como endereços IP NAT. Embora sejam regionais, são encaminháveis publicamente. Para obter informações sobre as diferentes formas de atribuição ou afetação de endereços IP NAT, consulte Endereços IP NAT.
Quando é possível e não é possível usar o Cloud NAT
O Cloud NAT aplica-se a instâncias, incluindo VMs de nós do GKE, que têm endereços IP externos?
Geralmente, não. Se a interface de rede de uma VM tiver um endereço IP externo, Google Cloud executa sempre a NAT 1 para 1 para pacotes enviados a partir do endereço IP interno principal da interface de rede sem usar o Cloud NAT. No entanto, o Cloud NAT pode continuar a fornecer serviços de NAT a pacotes enviados a partir de intervalos de endereços IP de alias dessa mesma interface de rede. Para mais detalhes, consulte as especificações do Cloud NAT e a interação do Compute Engine.
O NAT público permite que uma VM de origem cuja interface de rede não tenha um endereço IP externo envie tráfego para uma VM de destino ou um equilibrador de carga que tenha um endereço IP externo, mesmo quando a origem e o destino estão na mesma rede da VPC?
Sim. O caminho de rede envolve o envio de tráfego para fora da rede VPC através de um gateway de Internet predefinido e, em seguida, a receção do mesmo na mesma rede.
Quando a VM de origem envia um pacote para o destino, o NAT público executa o NAT de origem (SNAT) antes de entregar o pacote à segunda instância. O NAT público executa o NAT de destino (DNAT) para respostas da segunda instância para a primeira. Para ver um exemplo passo a passo, consulte o artigo Configuração e fluxo de trabalho básicos de NAT público.
Posso usar o NAT privado para a comunicação entre VMs na mesma rede da VPC?
Não, o NAT privado não executa o NAT no tráfego entre VMs na mesma rede da VPC.
Ligações recebidas não solicitadas não suportadas
O Cloud NAT permite ligações de entrada (por exemplo, SSH) a instâncias sem endereços IP externos?
Não, o Cloud NAT não suporta ligações de entrada não solicitadas.
Para mais informações, consulte as especificações do Cloud NAT.
No entanto, Google Clouda extremidade da rede pode responder a pings se o endereço IP de destino for um endereço IP externo de um gateway Cloud NAT que tenha mapeamentos de portas ativos para, pelo menos, uma instância de VM. Para ver os endereços IP atribuídos a um gateway NAT da nuvem, use o comando gcloud compute routers get-nat-ip-info.
Os endereços IP externos marcados como IN_USE podem responder a pings.
Se precisar de estabelecer ligação a uma VM que não tenha um endereço IP externo, consulte o artigo Escolha uma opção de ligação para VMs apenas internas. Por exemplo, como parte da configuração de exemplo do Compute Engine do Cloud NAT, estabelece ligação a uma VM sem um endereço IP externo através do Identity-Aware Proxy.
Cloud NAT e portas
Por que motivo uma VM tem um número fixo de portas (64 por predefinição)?
Quando uma gateway do Cloud NAT fornece NAT para uma VM, reserva tuplos de endereço de origem e porta de origem de acordo com o procedimento de reserva de portas.
Para mais informações, consulte exemplos de reserva de portas.
Posso alterar o número mínimo de portas reservadas para uma VM?
Sim. Pode aumentar ou diminuir o número mínimo de portas por VM quando cria um novo gateway NAT da Cloud ou editá-lo mais tarde. Cada gateway do Cloud NAT reserva tuplos de endereço de origem e porta de origem de acordo com o procedimento de reserva de portas.
Para mais informações sobre como diminuir o número mínimo de portas, consulte a pergunta seguinte.
Posso diminuir o número mínimo de portas por VM após criar o gateway da NAT na nuvem?
Sim. No entanto, a diminuição do número mínimo de portas pode fazer com que o procedimento de reserva de portas reserve um número inferior de portas por MV. Quando isto acontece, as ligações TCP existentes podem ser repostas e, se for o caso, têm de ser restabelecidas.
Quando muda o mapeamento de NAT dos intervalos principal e secundário para apenas o intervalo principal, as portas adicionais atribuídas a cada instância são imediatamente libertadas?
Não. As instâncias retêm todas as portas adicionais usadas por intervalos secundários até que a definição de portas mínimas por VM seja reduzida. Quando a NAT na nuvem está configurada para mapear intervalos secundários (alias) para sub-redes, a NAT na nuvem atribui um mínimo de 1024 portas por instância, com base no procedimento de reserva de portas.
Ao mudar para Apenas intervalos principais, o Cloud NAT conserva essas portas adicionais atribuídas para instâncias às quais essas portas já foram atribuídas. Depois de alterar os intervalos aos quais o Cloud NAT é aplicado para Apenas principal, o número real de portas atribuídas a essas instâncias não é alterado até que a definição de portas mínimas por VM também seja reduzida.
Para reduzir a quantidade de portas atribuídas a essas instâncias, depois de mudar para intervalos primários, a definição de portas mínimas por VM tem de ser reduzida. Depois de esse valor ser reduzido, o Cloud NAT ajusta automaticamente o número de portas atribuídas por instância, o que reduz o consumo de portas.
Cloud NAT e outros serviços Google
O Cloud NAT permite o acesso às APIs e aos serviços Google?
Quando ativa a NAT na nuvem para o intervalo de IPs principal de uma sub-rede, Google Cloud ativa automaticamente o Acesso privado do Google. Para mais informações, consulte Interação do acesso privado da Google.