Não consigo acessar o servidor web apache fora / dentro da rede local

Question

Peço desculpas antecipadamente se usar palavras técnicas de maneira errada. Eu ainda sou um novato no Linux / networking

Venho tentando descobrir esse problema por mais de uma semana e nenhuma das perguntas relacionadas que outros me fizeram me ajudou. Eu criei recentemente um servidor web em execução no apache2 para hospedar meu próprio site. Eu também pretendia usá-lo para SSH, FTP e VNC. Eu 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 portforwarding também para as portas 80, 21, 23, 53 e 443 no ip estático. lendo os guias sobre como configurar um servidor web publicamente acessível, achei que isso era tudo o que era necessário, pois estava funcionando perfeitamente no começo, mas é claro que descobri que uma vez tentei acessar o servidor usando o nome de domínio fora da rede Eu não consegui me conectar. Depois de mais algumas pesquisas, descobri que precisava alterar meu registro A no meu arquivo de zona no GoDaddy para o meu ip público. Uma vez que fiz isso, descobri que não conseguia mais me conectar ao meu servidor, nem dentro da rede, em vez disso, eu seria redirecionado para a página do roteador, assim como para fora da rede onde a conexão simplesmente terminaria. Mais tarde eu descobri que desde que meu ip público não poderia ser configurado como static eu tive que usar um serviço, especificamente dyndns para que ele pudesse atualizar constantemente o ip quando ele muda. Eu configurei o atualizador dyndns do 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. Eu também configurei um hostname, cokongwu.dyndns.org, que também aponta para o meu ip público e adicionei os servidores de nomes do dyndns aos servidores de nomes do Godaddy. O registro A que eu tenho para o cokongwu.com no godaddy ainda aponta para o meu ip interno e os registros do CName (www e cokongwu.com) ambos apontam para o cokongwu.dyndns.org (no entanto, como substituí os nameserves do godaddys pelos servidores de nomes do dyndns, não pode mais gerenciar o arquivo de zona para o domínio)

Depois de tudo isso, tentar acessar hostname.com ainda fornece 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 apenas sou encaminhado para a página de configuração dos roteadores e fora da rede, apenas expira. Eu estou sem ideias de como consertar isso, então qualquer idéia é bem vinda. Não deveria (o ip público) ser redirecionado para o meu ip interno?

Mais uma vez, desculpe se estou usando qualquer uma dessas palavras técnicas de maneira errada, ainda sou muito novo nessa coisa toda.

Eu sei um monte de perguntas relacionadas a este post certos comandos, então eu vou fazer 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

    

Answer 1

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) de dentro da LAN?
2 - Você não consegue verificar a funcionalidade do site a partir do fora ?

1 - Acesso ao servidor da web de dentro usando o FQDN.
Não consigo ver na sua pergunta de onde você está tentando acessar o servidor web, então vou supor que é de um cliente separado dentro da LAN.

Como você provavelmente está usando um servidor de DNS externo, sua solicitação para www.cokongwu.com resolverá o número de IP disponível publicamente, ou seja, a parte externa de seu roteador de internet (veja abaixo). Como esse roteador não roteará o tráfego que vem para o número de IP externo do interior de volta para o interior , o tráfego será interrompido nesse ponto.

Para que as coisas funcionem dentro da rede, o site www.cokongwu.com terá que ser resolvido como seu número de IP interno (192.168.0.105). Você pode tentar navegar no servidor da Web usando o número IP interno, mas desde que planeja usar o SSL, eventualmente isso exigirá que você acesse o servidor da Web usando o FQDN ou obterá erros de certificado.

O "caminho mais difícil" para corrigir a resolução interna de nomes é configurar um servidor DNS interno, mas o acima funcionará com resolução de problemas e implementações de pequena escala. Você não parece estranho ao Google e, se quiser configurar um servidor DNS interno, há muitos guias para isso na Internet.

Quando a resolução interna de nomes fornecer o endereço IP interno, a navegação para o servidor da web dará a mesma resposta, como se você fosse um cliente vindo de fora.

2 - acesso externo ao servidor da web.
Resolver www.cokongwu.com com dig www.cokongwu.com +noall +answer me deu a seguinte resposta.

www.cokongwu.com. 0 NO CNAME cokongwu.com.
cokongwu.com. 59 EM A 69.171.137.28

Isso mostra que o host www é um cname (alias) apontando para cokongwu.com , que é um registro A. Fazendo uma pesquisa inversa em 69.171.137.28 com dig -x 69.171.137.28 +short dá:

dsl-69-171-137-28.acanac.net

Isso parece um host dinâmico. Se a atualização do dyndns estiver funcionando, esse deve ser 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/<.*$//'

(shamelesly roubado de aqui ) ou navegando para www.whatismyip.com

Assumindo que esta é a sua corrente, navegar para www.cokongwu.com deve funcionar do lado de fora ...

Eu tentei isso e não funcionou, o que poderia significar qualquer combinação ou uma das seguintes:

A - O serviço dyndns não atualizou seu endereço IP
B - O encaminhamento em seu roteador externo não está funcionando C - O servidor da web não está respondendo

Realizar um teste rápido usando 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 tenha redirecionado a porta corretamente ou esteja usando um roteador em conjunto com o seu modem, você não conectou corretamente o modem ao roteador para permitir que ele manipule todas as solicitações de encaminhamento de porta.

Algumas ideias adicionais
Percebo que você mencionou porta 53 como uma das portas encaminhadas para o servidor da web. O Port 53 UDP é o padrão para solicitações de solicitações de DNS recebidas. A menos que você tenha um servidor dns em execução na máquina do servidor web, você pode fechar esta porta com segurança ... ele não servirá para nenhum propósito.

Também notei que você mencionou o uso de ssh e ftp, mas abriu as portas 21 e 23 no firewall e as enviou para o servidor da web. A porta 23 é a porta telnet e a porta 21 é a porta FTP . Eu recomendaria strongmente o uso de nenhum desses serviços, já que ambos são protocolos inseguros que transmitirão tudo em texto não criptografado, incluindo nomes de usuários e senhas.

Eu só recomendo abrir e encaminhar porta 22 no firewall. A Porta 22 é usada por ssh , que é a substituição criptografada para o telnet. A Porta 22 também é usada pelo serviço scp , que usa o serviço ssh para a transferência de arquivos. Usando ssh e scp ao invés de telnet e ftp manterão todo o seu tráfego de e para o servidor web seguro.
Uma outra recomendação seria usar uma porta diferente para ssh de entrada, preferivelmente um número de porta acima de 1000, como a porta 1522 (apenas um exemplo). Isso evita que o serviço ssh de entrada seja descoberto por varreduras de portas externas.Simplesmente altere a porta de entrada de 22 para um número de porta mais alto (ou seja, 1522), mas ainda mantenha-a encaminhada para a porta 22 no servidor web. Então acesse o servidor ssh do lado de fora usando o número de porta alta (1522) e do lado de dentro usando a porta 22.

Espero que isso seja de alguma utilidade para você e espero que você solucione seu problema =)