Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

Solução de problemas: erro interno durante a ativação do gateway

Modo de foco
Solução de problemas: erro interno durante a ativação do gateway - AWS Storage Gateway

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As solicitações de ativação do Storage Gateway atravessam dois caminhos de rede. As solicitações de ativação recebidas enviadas por um cliente se conectam à máquina virtual (VM) do gateway ou à instância do Amazon Elastic Compute Cloud (Amazon EC2) pela porta 80. Se o gateway receber com êxito a solicitação de ativação, ele se comunicará com os endpoints do Storage Gateway para receber uma chave de ativação. Se o gateway não conseguir alcançar os endpoints do Storage Gateway, ele responderá ao cliente com uma mensagem de erro interna.

Use as informações de solução de problemas a seguir para determinar o que fazer se você receber uma mensagem de erro interna ao tentar ativar o AWS Storage Gateway.

nota
  • Implante novos gateways usando o arquivo de imagem de máquina virtual mais recente ou a versão da imagem de máquina da Amazon (AMI). Ocorrerá um erro interno se tentar ativar um gateway que usa uma AMI desatualizada.

  • Antes de baixar a AMI, selecione o tipo de gateway correto que você pretende implantar. Os arquivos.ova e AMIs para cada tipo de gateway são diferentes e não são intercambiáveis.

Resolver erros ao ativar o gateway usando um endpoint público

Para resolver erros de ativação ao ativar seu gateway usando um endpoint público, execute as verificações e configurações a seguir.

Verificar as portas necessárias

Para gateways implantados no ambiente on-premises, verifique se as portas estão abertas no firewall local. Para gateways implantados em uma EC2 instância da Amazon, verifique se as portas estão abertas no grupo de segurança da instância. Para confirmar se as portas estão abertas, execute um comando telnet no endpoint público por meio de um servidor. Esse servidor deve estar na mesma sub-rede do gateway. Por exemplo, os seguintes comandos telnet testam a conexão com a porta 443:

telnet d4kdq0yaxexbo.cloudfront.net 443 telnet storagegateway.region.amazonaws.com 443 telnet dp-1.storagegateway.region.amazonaws.com 443 telnet proxy-app.storagegateway.region.amazonaws.com 443 telnet client-cp.storagegateway.region.amazonaws.com 443 telnet anon-cp.storagegateway.region.amazonaws.com 443

Para confirmar se o próprio gateway pode alcançar o endpoint, acesse o console da VM local do gateway (para gateways com implantação no ambiente on-premises). Ou você pode usar SSH para a instância do gateway (para gateways implantados na Amazon). EC2 Em seguida, execute um teste de conectividade de rede. Confirme se o teste retorna a mensagem [PASSED]. Para obter mais informações, consulte Testing Your Gateway Connection to the Internet.

nota

O nome de usuário de login padrão para o console do gateway é admin e a senha padrão é password.

Garantir que a segurança do firewall não modifique os pacotes enviados do gateway para os endpoints públicos

Inspeções SSL, inspeções profundas de pacotes ou outras formas de segurança de firewall podem interferir nos pacotes enviados do gateway. O handshake de SSL falhará se o certificado SSL for modificado de acordo com o que o endpoint de ativação espera. Para confirmar que não há nenhuma inspeção de SSL em andamento, execute um comando OpenSSL no endpoint de ativação principal (anon-cp.storagegateway.region.amazonaws.com) na porta 443. Você deve executar esse comando em uma máquina que esteja na mesma sub-rede do gateway:

$ openssl s_client -connect anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
nota

regionSubstitua pelo seu Região da AWS.

Se não houver inspeção de SSL em andamento, o comando retornará uma resposta similar à seguinte:

$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com CONNECTED(00000003) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com verify return:1 --- Certificate chain 0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon 1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon i:/C=US/O=Amazon/CN=Amazon Root CA 1 2 s:/C=US/O=Amazon/CN=Amazon Root CA 1 i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority ---

Se houver uma inspeção SSL em andamento, a resposta mostrará uma cadeia de certificados alterada, semelhante à seguinte:

$ openssl s_client -connect anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com CONNECTED(00000003) depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com ---

O endpoint de ativação aceita handshakes de SSL somente se reconhecer o certificado SSL. Isso significa que o tráfego de saída do gateway para os endpoints deve estar isento das inspeções realizadas por firewalls em sua rede. Essas inspeções podem ser uma inspeção SSL ou uma inspeção profunda de pacotes.

Verificar a sincronização de horas do gateway

Distorções de tempo excessivas podem causar erros de handshake de SSL. Para gateways on-premises, você pode usar o console da VM local do gateway para verificar a sincronização de horário do gateway. A diferença de tempo não deve ser superior a 60 segundos. Para obter mais informações, consulte Synchronizing Your Gateway VM Time.

A opção System Time Management não está disponível em gateways hospedados em EC2 instâncias da Amazon. Para garantir que os EC2 gateways da Amazon possam sincronizar adequadamente o horário, confirme se a EC2 instância da Amazon pode se conectar à seguinte lista de pools de servidores NTP pelas portas UDP e TCP 123:

  • 0.amazon.pool.ntp.org

  • 1.amazon.pool.ntp.org

  • 2.amazon.pool.ntp.org

  • 3.amazon.pool.ntp.org

Resolver erros ao ativar o gateway usando um endpoint da Amazon VPC

Para resolver erros de ativação ao ativar seu gateway usando um endpoint da Amazon Virtual Private Cloud (Amazon VPC), faça as seguintes verificações e configurações:

Verificar as portas necessárias

Certifique-se de que as portas necessárias em seu firewall local (para gateways implantados no local) ou grupo de segurança (para gateways implantados na Amazon) estejam abertas. EC2 As portas necessárias para conectar um gateway a um endpoint da VPC do Storage Gateway são diferentes das necessárias para conectar um gateway a endpoints públicos. As seguintes portas são necessárias para estabelecer conexão com a um endpoint da VPC do Storage Gateway:

  • TCP 443

  • TCP 1026

  • TCP 1027

  • TCP 1028

  • TCP 1031

  • TCP 2222

Para obter mais informações, consulte Como criar um endpoint da VPC para o Storage Gateway.

Além disso, verifique o grupo de segurança conectado ao endpoint da VPC do Storage Gateway. O grupo de segurança padrão anexado ao endpoint pode não permitir acesso às portas necessárias. Crie um grupo de segurança que permita o tráfego do intervalo de endereços IP do seu gateway pelas portas necessárias. Em seguida, anexe esse grupo de segurança ao endpoint da VPC.

nota

Use o console da Amazon VPC para verificar o grupo de segurança que está conectado ao endpoint da VPC. Visualize o endpoint da VPC do Storage Gateway no console e escolha a guia Grupos de segurança.

Para confirmar se as portas necessárias estão abertas, você pode executar comandos telnet no endpoint da VPC do Storage Gateway. Você deve executar esses comandos em um servidor que esteja na mesma sub-rede do gateway. Você pode executar os testes no primeiro nome DNS que não especifique uma zona de disponibilidade. Por exemplo, os seguintes comandos telnet testam as conexões de porta necessárias usando o nome DNS vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:

telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222

Garantir que a segurança do firewall não modifique os pacotes enviados do gateway ao endpoint da Amazon VPC do Storage Gateway

Inspeções SSL, inspeções profundas de pacotes ou outras formas de segurança de firewall podem interferir nos pacotes enviados do gateway. O handshake de SSL falhará se o certificado SSL for modificado de acordo com o que o endpoint de ativação espera. Para confirmar se não há nenhuma inspeção de SSL em andamento, execute um comando OpenSSL no endpoint da VPC do Storage Gateway. Você deve executar esse comando em uma máquina que esteja na mesma sub-rede do gateway. Execute o comando para cada porta necessária:

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

Se não houver inspeção de SSL em andamento, o comando retornará uma resposta similar à seguinte:

openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com CONNECTED(00000005) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com verify return:1 --- Certificate chain 0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon i:C = US, O = Amazon, CN = Amazon Root CA 1 2 s:C = US, O = Amazon, CN = Amazon Root CA 1 i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2 i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority ---

Se houver uma inspeção SSL em andamento, a resposta mostrará uma cadeia de certificados alterada, semelhante à seguinte:

openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com CONNECTED(00000005) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com ---

O endpoint de ativação aceita handshakes de SSL somente se reconhecer o certificado SSL. Isso significa que o tráfego de saída do gateway para o endpoint da VPC pelas portas necessárias está isento das inspeções realizadas pelos firewalls de sua rede. Essas inspeções podem ser inspeções SSL ou inspeções profundas de pacotes.

Verificar a sincronização de horas do gateway

Distorções de tempo excessivas podem causar erros de handshake de SSL. Para gateways on-premises, você pode usar o console da VM local do gateway para verificar a sincronização de horário do gateway. A diferença de tempo não deve ser superior a 60 segundos. Para obter mais informações, consulte Synchronizing Your Gateway VM Time.

A opção System Time Management não está disponível em gateways hospedados em EC2 instâncias da Amazon. Para garantir que os EC2 gateways da Amazon possam sincronizar adequadamente o horário, confirme se a EC2 instância da Amazon pode se conectar à seguinte lista de pools de servidores NTP pelas portas UDP e TCP 123:

  • 0.amazon.pool.ntp.org

  • 1.amazon.pool.ntp.org

  • 2.amazon.pool.ntp.org

  • 3.amazon.pool.ntp.org

Verificar se há um proxy HTTP e confirme as configurações do grupo de segurança associado

Antes da ativação, verifique se você tem um proxy HTTP na Amazon EC2 configurado na VM do gateway local como um proxy Squid na porta 3128. Nesse caso, verifique se:

  • O grupo de segurança anexado ao proxy HTTP na Amazon EC2 deve ter uma regra de entrada. Essa regra de entrada deve permitir o tráfego do proxy Squid na porta 3128 pelo endereço IP da VM do gateway.

  • O grupo de segurança vinculado ao endpoint da Amazon EC2 VPC deve ter regras de entrada. Essas regras de entrada devem permitir o tráfego nas portas 1026-1028, 1031, 2222 e 443 a partir do endereço IP do proxy HTTP na Amazon. EC2

Resolver erros ao ativar o gateway usando um endpoint público e quando há um endpoint da VPC do Storage Gateway na mesma VPC

Para resolver erros ao ativar seu gateway usando um endpoint público quando há um endpoint da Amazon Virtual Private Cloud (Amazon VPC) na mesma VPC, execute as verificações e configurações a seguir.

Confirmar se a configuração Habilitar nome de DNS privado não está habilitada no endpoint da VPC do Storage Gateway

Se a opção Habilitar nome de DNS privado estiver habilitada, você não poderá ativar nenhum gateway dessa VPC para o endpoint público.

Para desabilitar a opção de nome de DNS privado:
  1. Abra o console da Amazon VPC.

  2. No painel de navegação, escolha Endpoints.

  3. Escolha seu endpoint da VPC do Storage Gateway.

  4. Escolha Ações.

  5. Escolha Gerenciar nomes DNS privados.

  6. Em Habilitar nome de DNS privado, selecione Habilitar para este endpoint.

  7. Escolha Modificar nomes DNS privados para salvar a configuração.

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.