Pode ser devido a muitas razões.
/ * Primeiro de tudo, eu tenho que dizer que isso está mais relacionado ao serverfault.com não aqui .
É tão comum não poder acessar o endereço externo da rede de dentro da própria rede interna, pois o tráfego do endereço externo é enviado de volta à rede interna. Portanto, é bem provável que seja um problema de DNS e, como mencionei anteriormente nos comentários, você pode usar um URL diferente para sua rede local e para tráfego interno, ou seja, usar DNS dividido.
BTW, Dependendo do tipo de conexão que você tem, talvez não consiga acessar nada se o IP externo for o mesmo que o IP do servidor , portanto, esteja ciente das configurações de topologia e gateway da rede . Eu não sou um especialista em rede, então eu só posso ajudá-lo com a administração do sistema - é por isso que eu recomendo serverfault.com , não este lugar.
BTW, isso é algo útil - embora tenha sido no sistema Windows não Linux, rede é rede - que eu encontrei no SuperUser.com, eu acho que isso pode te ajudar muito, e aqui está o que < strong> JakeGould disse em sua resposta:
My money is on some kind of NAT loopback setting on your router being reset or deactivated. NAT loopback allows you to access port-forwarded services—like web services on port 80—on your router’s external IP address as well as the internal IP address.
Is your router perhaps an ISP-supplied router/modem combo? It could be that your ISP reset or upgraded the router/modem firmware and the NAT loopback settings were munged in the process. Many ISPs reserve the right to remotely access the router/modem the provided you with to perform routing maintenance at times and something like NAT loopback is a fairly non-standard setting that could be easily overlooked—or ignored—during such a reset. Now I am not condoning your ISP reseting your equipment without your knowledge, but just putting that out there as something that might happen if you are using ISP supplied equipment.
I would recommend going into your router’s config to see if NAT loopback options—or something similar sounding—exists and see if adjusting that clears things up.
Enquanto isso, devido ao que você disse sobre Ping failure , é possível adicionar uma regra ICMP personalizada em iptables
, já que o Ping opera enviando uma solicitação de eco do ICMP (Internet Control Message Protocol) (Tipo 8) pacotes para o host de destino e aguardando uma Resposta de eco ICMP (Tipo 0), a sintaxe é muito fácil:
$ iptables -A INPUT -s x.x.x.x -p ICMP --icmp-type 8 -j ACCEPT
#OR if you don't know ICMP type numbers
$ iptables -A INPUT -s x.x.x.x -p ICMP --icmp-type echo-request -j ACCEPT
BTW, saiba que sua sintaxe da tarefa do cron deve ser algo assim:
# ┌───────────── min (0 - 59)
# │ ┌────────────── hour (0 - 23)
# │ │ ┌─────────────── day of month (1 - 31)
# │ │ │ ┌──────────────── month (1 - 12)
# │ │ │ │ ┌───────────────── day of week (0 - 6) (0 to 6 are Sunday to
# │ │ │ │ │ Saturday, or use names; 7 is also Sunday)
# │ │ │ │ │
# │ │ │ │ │
# * * * * * command to execute
Recomendamos que você encontre o problema e descubra o que causa esse problema verificando as configurações de rede e de sistema que você criou ou está definido e, em seguida, tente uma solução. Evite fazer coisas a menos que você saiba o que é .