Peço desculpas antecipadamente se uso alguma palavra técnica de maneira errada. Ainda sou um novato em Linux/redes
Estou tentando descobrir esse problema há mais de uma semana e nenhuma das perguntas relacionadas que outras pessoas fizeram me ajudou. Recentemente construí um servidor web rodando em Apache2 para hospedar meu próprio site. Também pretendia usá-lo para SSH, FTP e VNC. Registrei um domínio no GoDaddy, cokongwu.com. Um ip estático (192.168.0.105) foi configurado para o servidor e eu configurei o encaminhamento de porta também para as portas 80, 21, 23, 53 e 443 para o ip estático. lendo os guias sobre como configurar um servidor web acessível ao público, pensei que isso era tudo o que precisava, pois estava funcionando perfeitamente no início, mas é claro que descobri que uma vez tentei acessar o servidor web usando o nome de domínio fora da rede , não consegui me conectar. Depois de mais algumas pesquisas, descobri que precisava alterar meu registro A em meu arquivo de zona no GoDaddy para meu ip público. Depois de fazer isso, descobri que não conseguia mais me conectar ao meu servidor da Web, tanto dentro da rede, onde seria redirecionado para a página do roteador, quanto fora da rede, onde a conexão simplesmente expiraria. Mais tarde, descobri que, como meu IP público não podia ser definido como estático, tive que usar um serviço, especificamente o dyndns, para que ele pudesse atualizar constantemente o IP quando ele mudasse. Eu configurei o atualizador dyndns no centro de atualização de software e configurei minha conta dyndns, cokongwu.com, com um registro A que aponta para meu IP público e um alias www.cokongwu.com que aponta para cokongwu.com. Também configurei um nome de host, cokongwu.dyndns.org, que também aponta para meu IP público e adicionei os servidores de nomes dyndns aos servidores de nomes de Godaddy. O registro A que tenho para cokongwu.com em godaddy ainda aponta para meu ip interno e os registros CName (www e cokongwu.com) apontam para cokongwu.dyndns.org. (no entanto, desde que substituí os servidores de nomes de godaddy por servidores de nomes de dyndns, eu não é mais possível gerenciar o arquivo de zona do domínio)
Depois de tudo isso, tentar acessar hostname.com ainda apresenta os mesmos problemas de antes. Acessá-lo aponta para o meu ip público em vez do meu ip interno, mas dentro da rede eu simplesmente sou encaminhado para a página de configuração do meu roteador e fora da rede ele simplesmente expira. Estou sem ideias sobre como consertar isso, então qualquer ideia é bem-vinda. Não deveria (o ip público) ser redirecionado para o meu ip interno?
Mais uma vez, desculpe se estou usando alguma dessas palavras técnicas de maneira errada, ainda sou muito novo nisso tudo.
Eu conheço muitas perguntas relacionadas a esta postagem de determinados comandos, então farei o mesmo:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5556 0.0.0.0:* LISTEN 3387/dyn_updater
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2729/vino-server
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::21 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5800 :::* LISTEN 2729/vino-server
tcp6 0 0 :::5900 :::* LISTEN 2729/vino-server
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 127.0.1.1:53 0.0.0.0:* -
udp 0 0 0.0.0.0:39124 0.0.0.0:* -
udp 0 0 0.0.0.0:631 0.0.0.0:* -
udp6 0 0 :::5353 :::* -
udp6 0 0 :::53973 :::* -
ufw:
sudo ufw status
[sudo] password for fender:
Status: inactive
000-default.conf:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
ServerName cokongwu.com
ServerAlias www.cokongwu.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Responder1
Pelo que entendi você está tendo os seguintes problemas:
1 - Não é possível acessar o servidor web (usando o FQDN, "nome de domínio totalmente qualificado" www.cokongwu.com) dedentroa LAN?
2 - Você não consegue verificar a funcionalidade do site nofora?
1 - Acesso ao servidor web por dentro usando FQDN.
Não consigo ver na sua pergunta de onde você está tentando acessar o servidor web, então presumo que seja de um cliente separado dentro da LAN.
Como você provavelmente está usando um servidor DNS externo, sua solicitação para www.cokongwu.com resolverá o número IP disponível publicamente, ou seja, a parte externa do seu roteador de Internet (veja abaixo). Como esse roteador não encaminhará o tráfego que chegapara o número IP externode dentrode volta para dentro, o tráfego irá parar nesse ponto.
Para que as coisas funcionemdentroa rede, www.cokongwu.com terá que ser resolvido como seuinternoNúmero IP (192.168.0.105). Você pode tentar navegar no servidor web usando o número IP interno, mas como planeja usar SSL, eventualmente isso exigirá que você acesse o servidor web usando o FQDN ou você receberá erros de certificado.
A "maneira mais difícil" de corrigir a resolução interna de nomes é configurar um servidor DNS interno, mas o procedimento acima funcionará na solução de problemas e em implantações em pequena escala. Você não parece estranho ao Google e se quiser configurar um servidor DNS interno, existem muitos guias sobre isso na internet.
Depois que a resolução interna de nomes fornecer o endereço IP interno, navegar até o servidor web fornecerá a mesma resposta como se você fosse um cliente vindo de fora.
2 - acesso externo ao servidor web.
Resolver www.cokongwu.com dig www.cokongwu.com +noall +answerme deu a seguinte resposta.
www.cokongwu.com. 0 IN CNAME cokongwu.com.
cokongwu. com. 59 EM A 69.171.137.28
Isto mostra que owwwhost é um cname (alias) apontando paracokongwu. comque é um disco A. Fazendo uma pesquisa reversa em69.171.137.28com dig -x 69.171.137.28 +shortdá:
dsl-69-171-137-28.acanac.net
Parece um host dinâmico. Se a atualização do dyndns estiver funcionando, esse deverá ser o seu endereço IP público atual. Verifique isso com o seguinte comando em uma linha de comando:
curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'
(vergonhosamente roubado deaqui) Ou navegando parawww.whatismyip.com
Supondo que este seja o seu atual, navegando parawww.cokongwu.comdeveria funcionar de fora...
Eu tentei isso e não funcionou, o que pode significar qualquer um ou uma combinação dos seguintes:
A - O serviço dyndns não atualizou seu endereço IP
B - O encaminhamento no seu roteador externo não está funcionando
C - O servidor web não está respondendo
Fazer um teste rápido telnet <ip number> <port number>não fornece respostas de nenhum dos números de porta listados acima. Isso me levaria a acreditar que o motivo deveria ser A ou B. Se for B, pode ser que você não encaminhou a porta corretamente ou se estiver usando um roteador em conjunto com seu modem, você não fez a ponte corretamente o modem ao roteador para permitir que ele lide com todas as solicitações de encaminhamento de porta.
Algumas reflexões adicionais
Percebi que você mencionouporta 53como uma das portas encaminhadas para o servidor web.Porta 53 UDPé o padrão para entradasolicitações de DNS. A menos que você realmente tenha umServidor dnsrodando na máquina do servidor web, você pode fechar esta porta com segurança... ela não servirá para nada de qualquer maneira.
Notei também que você mencionou o uso de ssh e ftp, mas abriu as portas 21 e 23 no firewall e encaminhou para o servidor web. A porta 23 é atelnetporta e a porta 21 é aPorta FTP. Aconselho vivamente a utilização de nenhum destes serviços, uma vez que ambos são protocolos inseguros que irão transmitirtudoem texto não criptografado, incluindo nomes de usuário e senhas.
Recomendo apenas abrir e encaminharporta 22no firewall.Porta 22é usado porssh, que é o substituto criptografado do telnet.Porta 22também é usado peloscpserviço, que utiliza oserviço SSHpara transferência de arquivos. Usandosshescpem vez de telnet e ftp, manterá todo o tráfego de e para o servidor web seguro.
Uma recomendação adicional seria usar uma porta diferente para ssh de entrada, de preferência um número de porta superior a 1000, como a porta 1522 (apenas um exemplo). Isso evita que o serviço ssh de entrada seja descoberto por varreduras de portas externas. Basta alterar a porta de entrada de 22 para um número de porta maior (ou seja, 1522), mas ainda assim mantê-la encaminhada paraporta 22no servidor web. Em seguida, acesse o servidor ssh por fora usando o número de porta alto (1522) e por dentro usando a porta 22.
Espero que isso seja útil para você e que resolva seu problema =)