Então, eu / eu temos a nova instalação do Fedora Core 28 que estamos tentando trazer online. A instalação foi perfeitamente tão longe quanto poderíamos dizer. Possui duas placas de rede, uma para uma rede interna, uma com um endereço IP fixo. É um servidor, portanto, seu principal trabalho é executar um servidor da web, httpd . E tem que ser acessível de outra forma que não seja o console, então está rodando sshd .
No começo, tudo parece OK. O primeiro uso da rede foi usar o yum para instalar muitos pacotes, não houve problema. Adicionamos gnome para obter uma GUI, adicionamos firefox para obter um navegador da Web e usamos isso para ajudar na obtenção de dados para solução de problemas. Conexões na rede interna estão bem. Conectar-se com SSH não é um problema e pelo menos uma conta foi configurada para usar chaves de criptografia para evitar uma senha. Conectar-se ao novo servidor da Web também parece bom, usando IPs internos e externos. Então, sentimos que tínhamos confirmado que o ssh e o servidor web estavam configurados corretamente. ... Inicialmente, não sabíamos que algo estava errado.
Quando chegamos a nos conectar do mundo exterior é quando as coisas "foram para os lados". As tentativas de conexão com SSH falharam completamente e as conexões com o servidor da Web também pareciam falhar completamente também.
PRIMEIRA tentativa foi com o firewall. Como está configurado? É iptables ou firewalld ? Como podemos garantir que podemos passar do lado de fora? Descobrimos que, de alguma forma, configuramos a exceção em /etc/firewalld/zones - a zona padrão é "FedoraServer.xml" no nosso caso - como httpd , e notamos em uma reinicialização que ela reclamou e alterou para http , com a qual não notamos mais nenhuma queixa. Ainda não há alegria.
Depois, há nmap ! Este é um scanner de porta para sistemas Linux para ver as portas abertas de qualquer alvo de rede. Isso pareceu mostrar que não estávamos bloqueados pelo firewall. Confirmamos que iptables não estava em uso e foi firewalld , então desativamos e ainda não temos alegria.
Em seguida, consideramos o equipamento mais antigo. As portas ethernet de par trançado são dispositivos bidirecionais, então seria possível entrar na porta externa quando a saída estava ruim? OU, talvez, houvesse uma porta ruim no switch? Então, tentamos trocá-los, internos e externos. Nenhuma mudança.
Em seguida, consideramos que talvez o roteador estivesse filtrando, mesmo que não devesse. A nova caixa substituiu uma caixa antiga que estava aposentada e a antiga estava totalmente funcional, mas quem sabe? Talvez o roteador tenha enlouquecido? Então, fomos entrar e ver. Mas, infelizmente, ninguém conseguiu encontrar a senha do roteador.
Em vez disso, como o roteador só conhece os sistemas por seus IPs externos, encerramos um sistema totalmente funcional e o novo selecionava o endereço IP do sistema de desligamento. Isso elimina o roteador como uma causa potencial, pelo menos pensamos que sim. No entanto, os problemas persistiram.
Foi sugerido que talvez o roteador esteja com defeito, pois talvez estivesse pegando endereços MAC, e assim, para eliminar essa possibilidade, nós o reinicializamos. Mais uma vez, sem melhora.
Eu então tive a percepção de pedir ao nosso testador externo para aumentar o detalhamento dos dados de diagnóstico da conexão ssh adicionando, cada vez mais, -v à linha de comando (você pode fazer até três) e nosso sistema interno de administração para por favor, verifique os logs do Apache. E isso foi muito útil. Descobrimos que a percepção externa era ssh chegando ao nosso daemon sshd , mas as conexões estavam sendo eliminadas e os logs do servidor da Web mostravam conexões de entrada corretas apenas dos locais esperados e registramos "200" como resultado , o que significa que httpd achava que os clientes da web estavam recebendo suas páginas. Mas isso não era verdade.
OK, então agora o que?