Originalmente, la configuración de mi blog estaba planeada como un proyecto puramente IPv6 a través de WireGuard, ya que todo se ejecuta en un servidor doméstico (por cierto, se pueden obtener direcciones IPv6 gratuitas en route64.org). Para mejorar la accesibilidad, ahora he añadido un proxy IPv4 externo (gracias a @Larvitz).

Sin embargo, surgieron problemas de SSL de inmediato: dado que originalmente tanto el registro A como el AAAA pasaban por el proxy, la validación de Let's Encrypt en mi servidor fallaba.

La solución: El "hack de IPv6"

La solución fue apuntar explícitamente el registro AAAA directamente a la IP de WireGuard de mi servidor, en lugar de dirigirlo también a través del proxy.

• Dominio: blog.burningboard.org
• Registro A (Proxy): 194.28.98.217
• Registro AAAA (Servidor): 2a11:6c7:f05:a8::2 (WireGuard)

Gracias a este registro AAAA directo a mi IP de WireGuard, Let’s Encrypt sigue llegando a mi servidor directamente a través de IPv6 (ya que el registro AAAA tiene prioridad por defecto) y emite el certificado SSL. El tráfico IPv4 es reenviado de forma cifrada por el proxy hacia mí.

La configuración final

Para que la comunicación funcione sin problemas, tuvimos que ajustar los servidores Caddy:

1. En mi servidor (NixOS, blog.nix)

Para que las IPs reales de los visitantes lleguen correctamente y no sean sobrescritas por la IP del proxy, este debe marcarse como de confianza:

services.caddy.globalConfig = ''
  servers {
      trusted_proxies static 2a06:9801:1c:1000::10
  }
'';

2. En el proxy externo (Caddy)

Para que el proxy se comunique correctamente con mi servidor a través de HTTPS, debe enviar el nombre de host (SNI):

reverse_proxy [https://[2a11:6c7:f05:a8::2]:443](https://[2a11:6c7:f05:a8::2]:443) {
    header_up Host {host}
    transport http {
        tls_server_name blog.burningboard.org
    }
}

¡El blog ahora es accesible a través de IPv4 e IPv6, está cifrado de forma segura y mi IP doméstica sigue siendo privada! 🚀