Hosts virtuais Apache não acessíveis publicamente após encaminhamento de porta

Hosts virtuais Apache não acessíveis publicamente após encaminhamento de porta

Decidi instalar o Proxmox no meu novo servidor para hospedar servidores Web, Email e VPS. Dessa forma, posso configurar várias VMs para cada tipo de servidor.

Optei pelo Debian 9 para meu servidor web Apache. E também já consegui importar meus sites WordPress importados usando o plugin duplicador, e funcionou perfeitamente. Editei minha tabela WP_Options no PHPMyAdmin para https em vez de HTTP como URL do site, então configurei meu host virtual Apache assim (mydomain.com.conf)

<VirtualHost *:80>
    ServerName mydomain.com
    ServerAdmin root@localhost
    Redirect "/" "https:// mydomain.com"
</VirtualHost>

<VirtualHost *:443>
    ServerAdmin root@localhost
    DocumentRoot /var/www/mydomain.com
    ServerName mydomain.com
    ServerAlias www.mydomain.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/mydomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem

    <Directory /var/www/mydomain.com>
        AllowOverride All
        DirectoryIndex index.php
        Require all granted
    </Directory>

</VirtualHost>

Posso acessar meu site localmente configurando uma regra em meu arquivo hosts do Windows como esta:

192.168.10.104      mydomain.com

Também configurei um IP estático para evitar que o servidor web receba um novo endereço IP. Eu fiz isso em /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
address 192.168.10.104
netmask 255.255.255.0
gateway 192.168.10.1

# This is an autoconfigured IPv6 interface
iface ens18 inet6 auto

Quero ressaltar que criei um host virtual para meu [endereço IP público][1].

Para evitar conflitos, desabilitei o firewall UFW e removi o fail2ban. Apenas por agora.

Na minha opinião, meu DNS, servidores de nomes e encaminhamento de porta estão configurados corretamente. No entanto, posso estar errado.

[Configurações NS do meu registrador de domínios][2]

[Minhas configurações de DNS na DigitalOcean][3]

[Minhas configurações de Portforwarding][4]

Se eu tentar acessar meu site usando [UpTrends][5], recebo "Falha na conexão TCP". Também não há problemas no meu certificado SSL do meu ponto de vista local no site.

Algum conselho?

Responder1

Finalmente!

Acontece que a solução foi apenas reiniciar o roteador (com a energia desconectada por 10 segundos), além de reiniciar o servidor.

Às vezes, os problemas podem ser resolvidos de maneira fácil, mas inesperada :)

Responder2

Sua configuração de DNS está correta e a visita http://example.comse conecta com sucesso ao publicip:80 e serve um redirecionamento HTTP.

No entanto, conectar-se a publicip:443 (ou seja https://example.com) retorna ICMP "Host inacessível", que neste caso deve vir do seu roteador (o dispositivo com o endereço IP público, seja o host Proxmox ou um roteador dedicado não assunto), ou do próprio servidor web.

Como o erro ICMP vem com atraso,provavelmentevem do roteador e indica que a regra de encaminhamento de porta para :443 aponta para o endereço IP errado (um que não está em uso, ou seja, tempo limite de resposta ARP).

(Se fosse um bloqueio de firewall, a tentativa de conexão retornaria um erro RST ou ICMP imediatamente, ou nada.)

Se as configuraçõesolharcerto, use tcpdumppara dar uma olhada no que éna verdadeacontecendo. A execução tcpdump -e -n -i <interface> "arp or port 443"no host Proxmox (na interface voltada para sua VM da web) mostrará o endereço IP real que a regra de encaminhamento de porta está tentando alcançar.


O mesmo se aplica em geral; não basta apenas desligar as coisas. Você também precisa olhar para oatualregras de firewall (o firewall real é iptables ou nft); ou seja, verifique se o estado atual corresponde ao estado solicitado. Você não tem certeza se desabilitar o ufw deixou o firewall completamente vazio até verificar com iptables-save, iptables-legacy-save, nft list ruleset.

informação relacionada