No se puede acceder al dominio a través de HTTPS en el mismo servidor detrás de un firewall PfSense

Question

Estoy alojando una plataforma en un servidor que tiene varios nombres de dominio, digamos ejemplo.com y otroejemplo.com. Estoy ejecutando un backend Spring Boot en ese servidor, que usa el dominio example.com e intenta comunicarse con anotherexample.com. Mi problema es que parece que no puedo conectarme con el otro dominio a través de HTTPS, simplemente ni siquiera se conecta. He probado las siguientes pruebas que arrojan resultados diferentes:

1. Usar curlen una máquina que no esté detrás del firewall parahttps://otroejemplo.com, funciona perfecto
2. Usar curlen el servidor, pero en lugar de usarhttp://otroejemplo.com, funciona perfecto
3. Usando curlen el servidor parahttps://otroejemplo.com, no hay respuesta, finalmente se agota el tiempo de espera
4. Usando curlen el firewall parahttps://otroejemplo.com, no hay respuesta, finalmente se agota el tiempo de espera
5. Usando openssl s_client -connect anotherexample.com:443 -servername anotherexample.comen el servidor, no hay respuesta, finalmente se agota el tiempo de espera
6. Al cambiar /etc/hostsen el servidor a 127.0.0.1 anotherexample.com, cuando lo ejecuto openssl s_client -connect anotherexample.com:443 -servername anotherexample.com, obtengo una respuesta.

¿Cuál podría ser el problema que hace que no pueda conectarme a ningún dominio alojado en máquinas detrás del firewall? ¿Es algo mal configurado en el servidor (Ubuntu 22.04) o en el firewall PfSense (2.7.2)?

Mi estructura es la siguiente:

• PfSense Firewall que utiliza NAT para garantizar que la IP pública llegue a la IP interna del servidor
• Servidor que ejecuta NGINX con los puertos 80 y 443 abiertos. Los certificados se realizan a través de LetsEncrypt y funcionan perfectamente en el navegador.

Answer 1

Eso es normal; DNAT ("reenvío de puertos") no funciona cuando tanto el origen como el destino real están en la misma subred (o incluso son el mismo sistema). Se han publicado muchos hilos anteriores sobre el mismo problema con las puertas de enlace domésticas (busque "NAT hairpin"), pero se aplica igualmente a cualquier implementación de NAT, incluido pfSense, así que busque las publicaciones anteriores para obtener una explicación completa; El problema básico es que el firewall sólo tiene la oportunidad de reescribir paquetes en una dirección pero no en la otra.

Una solución común es hacer que pfSense también reescriba la dirección IP de origen, haciendo que el servidor web parezca como si la conexión realmente viniera del firewall en lugar de sí misma. Para hacer eso, habiliteReflexión NATen su cortafuegos. En otros lugares se llamaría "bucle invertido NAT", "horquilla NAT" o simplemente una regla SNAT personalizada sin un nombre específico.

Tenga en cuenta que esto tendrá ligeras implicaciones en el rendimiento porque cada paquete necesariamente pasa a través de Ethernet hasta pfSense.yatrás, en lugar de poder permanecer completamente dentro de la máquina. Sus aplicaciones web también deberán contar con la IP del firewall si está utilizando acceso basado en IP.

Entonces yo personalmenterecomendarlas 127.0.0.1entradas /etc/hosts para todos los dominios en lugar de depender de la reflexión NAT.