Tengo un servidor que aloja un sitio web entregado a través de https en el puerto 443. El sitio web no está abierto directamente a la Internet pública, pero el tráfico se enruta a través de una VPN desde una instancia EC2 que tiene una IP pública.
Se puede acceder al sitio web desde el servidor host, computadoras en la misma red interna y computadoras en la VPN, que no son la instancia EC2.
Emitir el comando openssl s_client -connect www.mydomain.tld:443desde cualquiera de esas máquinas da la respuesta:
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = cloud.hss.ac.uk
verify return:1
---
Certificate chain......
[Truncated for brevity]
Sin embargo, el mismo comando emitido en la instancia EC2, o desde una máquina fuera de las redes internas o VPN, da la respuesta:
CONNECTED(00000003)
Entonces, ¿obtenemos una conexión, pero no hay certificados SSL?
Configurar el nivel de registro para depurar en el archivo de configuración de Apache muestra que los certificados SSL se están entregando, pero no llegan a la instancia EC2 por algún motivo.
La instancia EC2 solo envía solicitudes entrantes NAT en los puertos 80 y 443 al servidor de alojamiento mediante IFtables. Aquí están las configuraciones en/etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table ip nat {
chain prerouting {
meta nftrace set 1
type nat hook prerouting priority -100; policy accept;
iifname "eth0" tcp dport { 80, 443 } dnat to x.x.x.x
counter
}
chain postrouting {
meta nftrace set 1
type nat hook postrouting priority 100; policy accept;
masquerade
}
}
Todo esto funciona bien en el puerto 80.
Me estoy quedando sin ideas, así que busco algunas aquí.
La VPN es una VPN de Hamachi, en caso de que sea relevante.
El reenvío de IP está habilitado:
sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1