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
region
Substitua 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.rproxy.goskope.comverify 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 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:
-
Abra o console da Amazon VPC
. -
No painel de navegação, escolha Endpoints.
-
Escolha seu endpoint da VPC do Storage Gateway.
-
Escolha Ações.
-
Escolha Gerenciar nomes DNS privados.
-
Em Habilitar nome de DNS privado, selecione Habilitar para este endpoint.
-
Escolha Modificar nomes DNS privados para salvar a configuração.