
Eu tenho um Dell PowerEdge T350 com iDRAC9 Basic. O servidor está conectado a um switch que está conectado a um roteador upstream que está conectado à Internet. Muito simples. Tanto o NIC1 do servidor está conectado ao switch quanto a própria placa UTP LAN do iDRAC. Ativei o iDRAC e posso acessar a GUI da web de outro host conectado ao mesmo switch (também conhecido como intranet).
Ambas as interfaces LAN do servidor possuem IPs de intranet estáticos configurados (na faixa 192.168.1.x) e não DHCP-d, já que as traduções de porta no roteador é melhor termos um IP fixo. Configurei as traduções de portas no roteador para que dois serviços pudessem ser acessados remotamente: RDP e iDRAC. O RDP é o próprio sistema operacional do servidor.
Aí vem a parte interessante:
- Posso acessar o sistema operacional do servidor com RDP através da intranet
- Posso acessar o sistema operacional do servidor com RDP remotamente
- Posso acessar a GUI da web do iDRAC pela intranet
- NÃO POSSO acessar remotamente a GUI da web do iDRAC
Configurei o redirecionamento de porta do iDRAC (ou podemos chamá-lo de pin hole do firewall) da mesma forma que fiz com o RDP. Embora o RDP precise de redirecionamento de porta TCP e UDP 3389. O iDRAC só precisa do redirecionamento da porta TCP 443.
Questões:
- Existe algum switch ou opção de configuração no iDRAC que impeça o acesso à intranet por padrão? (Embora haja uma tradução de endereço/NAT acontecendo pelo roteador, essa pergunta pode nem fazer sentido?)
- O roteador em questão é um PACE 5268AC FXN. Não consigo encontrar nada no manual que indique que ele permitiria o redirecionamento 3389 (ou também 3390 porque também fixei o RDP de outra máquina), mas falharia com HTTPS. Não vejo nada de útil no log do firewall que possa ajudar. Parece que de alguma forma os pacotes recebidos da intranet 443 nem chegam ao roteador? Eu não entendo.
- Também tentei 33443 -> 443 e outros tipos de redirecionamentos em vez de 443 -> 443, mas também não funcionou.
- Acrescento também que o certificado SSL do iDRAC é um fracasso (não válido), mas parece que a coisa falhou em algum estágio anterior. O ISP é a AT&T.
Para registro, minha versão do firmware do iDRAC é 6.10.30.00 (Build 29), configurações do iDRAC versão 5.00.00.10
Responder1
Verifiquei novamente minhas configurações de rede do iDRAC, o gateway estava adequado (192.168.1.254). Também procurei e verifiquei se o iDRAC pode executar ping no gateway ( racadmin ping 192.168.1.254
quando fiz login na GUI da Web do iDRAC na intranet). Também verifiquei a configuração pinhole da porta do roteador, que também parecia boa. Tentei acessar a GUI da Web remotamente algumas vezes e verifiquei que os logs do firewall do roteador não registravam esses pacotes e os reconheciam como acesso pinhole.
Não tenho certeza do que mudou, mas talvez meu navegador tente o protocolo http por padrão quando vê um endereço IP (estou acessando o iDRAc remotamente apenas com um endereço IP estático, sem nome DNS), quando coloco manualmente o protocolo https, consegui uma mensagem de erro em vez de um tempo limite:
Pedido ruim
Seu navegador enviou uma solicitação que este servidor não conseguiu entender
Além disso, um erro 400 Bad Request foi encontrado ao tentar usar um ErrorDocument para lidar com a solicitação de arquivo.
Isso acontecia tanto com navegadores baseados em Firefox quanto em Chromium. Então procuro esta mensagem de erro específica e em um artigo da Base de Conhecimento encontrei uma solução que ajudou:Falhas de conexão HTTP/HTTPS FQDN no firmware iDRAC9 versão 5.10.00.000
Causa O servidor da web na versão 5.10.00.00 do firmware iDRAC9 impõe uma verificação de cabeçalho de host HTTP/HTTPS por padrão. Resolução Por padrão, o iDRAC9 verificará o cabeçalho do host HTTP/HTTPS e comparará com o 'DNSRacName' e o 'DNSDomainName' definidos. Quando os valores não corresponderem, o iDRAC recusará a conexão HTTP/HTTPS. No iDRAC9 5.10.00.00, essa imposição de cabeçalho de host pode ser desativada com o seguinte comando RACADM.
#Disable host header check
racadm set idrac.webserver.HostHeaderCheck 0
Agora me pergunto se isso representa algum risco à segurança. Acessamos o iDRAC a partir de IPs não fixos e o endereçamos com um endereço IP. Só consigo pensar em um cliente REST que injetaria os cabeçalhos HTTP necessários. Mas pelo menos posso acessar a GUI da web do iDRAC agora.
Responder2
Uma solução é usar o endereço IP em vez do FQDN. Então funciona.