Los hosts virtuales Apache no son accesibles públicamente después del reenvío de puertos

Los hosts virtuales Apache no son accesibles públicamente después del reenvío de puertos

Decidí instalar Proxmox en mi nuevo servidor para alojar servidores web, de correo electrónico y VPS. De esa manera, puedo configurar varias máquinas virtuales para cada tipo de servidor.

Elegí Debian 9 para mi servidor web Apache. Y también logré importar mis sitios de WordPress importados usando el complemento duplicador, y funcionó perfectamente. Edité mi tabla WP_Options en PHPMyAdmin a https en lugar de HTTP como URL del sitio, luego configuré mi host virtual Apache de esta manera (midominio.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>

Puedo acceder a mi sitio web localmente configurando una regla en mi archivo de hosts de Windows como esta:

192.168.10.104      mydomain.com

También configuré una IP estática para evitar que el servidor web obtenga una nueva dirección IP. Lo hice en /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

Quiero señalar que creé un host virtual para mi [dirección IP pública][1].

Para evitar conflictos, desactivé el firewall UFW y eliminé fail2ban. Solo por ahora.

En mi opinión, mi DNS, mis servidores de nombres y el reenvío de puertos están configurados correctamente. Sin embargo, podría estar equivocado.

[Configuraciones NS de mi registrador de dominio][2]

[Mis configuraciones de DNS en DigitalOcean][3]

[Mis configuraciones de reenvío de puertos][4]

Si intento acceder a mi sitio web usando [UpTrends][5] aparece el mensaje "Error de conexión TCP". Tampoco hay problemas con mi certificado SSL desde mi punto de vista local en el sitio web.

¿Algún consejo?

Respuesta1

¡Finalmente!

Resulta que la solución fue simplemente reiniciar el enrutador (con la energía desconectada durante 10 segundos), además de reiniciar el servidor.

A veces los problemas se pueden solucionar de una manera fácil pero inesperada :)

Respuesta2

Su configuración de DNS es correcta y la visita http://example.comse conecta exitosamente a publicip:80 y realiza una redirección HTTP.

Sin embargo, al conectarse a publicip:443 (es decir https://example.com), se devuelve ICMP "Host inalcanzable", que en este caso debe provenir de su enrutador (el dispositivo con la dirección IP pública, ya sea el host Proxmox o un enrutador dedicado, no asunto), o desde el propio servidor web.

Dado que el error ICMP llega con un retraso,más probableproviene del enrutador e indica que la regla de reenvío de puerto para :443 apunta a la dirección IP incorrecta (una que no está en uso, es decir, tiempo de espera de respuesta ARP).

(Si se tratara de un bloqueo de firewall, el intento de conexión devolvería un error RST o ICMP inmediatamente, o nada en absoluto).

Si la configuraciónmirarBien, utilízalo tcpdumppara echar un vistazo a lo que hay.de hechosucediendo. La ejecución tcpdump -e -n -i <interface> "arp or port 443"en el host Proxmox (en la interfaz frente a su VM web) mostrará la dirección IP real a la que intenta alcanzar la regla de reenvío de puertos.


Lo mismo se aplica en general; No basta con apagar las cosas. También es necesario mirar elactualreglas de firewall (el firewall real es iptables o nft); es decir, comprobar si el estado actual coincide con el estado solicitado. No estás seguro de que deshabilitar ufw dejó el firewall completamente vacío hasta que lo verifiques con iptables-save, iptables-legacy-save, nft list ruleset.

información relacionada