Hemos escrito (en Go y Delphi) varios microservicios de Windows, que responden a solicitudes HTTP en puertos específicos en el rango 11000-12000. Están diseñados para ejecutarse internamente dentro del dominio o la red privada del cliente (es decir, no en Internet).
Funcionan perfectamente en todospero unode nuestros más de 50 sistemas cliente, en sistemas operativos que van desde Windows 7/10/11 hasta Windows Server 2008R2/2012/2016/2019. El proceso de instalación de cada uno de estos servicios configura reglas en el firewall de Windows para aceptar las solicitudes de cada servicio exe.
El único sistema cliente en el que no funcionan es el que ejecuta Windows Server 2016 Essentials. Este es el único sistema cliente que ejecuta ese sistema operativo específico, por lo que puede ser un factor en el problema.
Incluso localmente, usando un navegador web en ese sistema para consultar los servicios, no funcionan. Las solicitudes simplemente esperan un momento y luego expiran: ERR_CONNECTION_TIMED_OUT. Sin embargo, las mismas solicitudes a los mismos puertos en la dirección 127.0.0.1 (localhost) funcionan instantáneamente, lo que demuestra que los servicios realmente se están ejecutando. El modo de falla cuando el servicio objetivo no se está ejecutando o si nos dirigimos al puerto incorrecto es diferente. En ese caso, obtenemos un error rápido de "se negó a conectarse": ERR_CONNECTION_REFUSED
No hay productos antivirus o firewall de terceros instalados en el sistema, que solo utiliza Windows Defender con el firewall normal de Windows. Hemos intentado todo lo que se nos ocurrió con el firewall de Windows, incluso desactivarlo por completo. Nada de lo que hemos probado hizo alguna diferencia.
Hemos intentado usar muchos números de puerto alternativos, pero no logramos ningún éxito hasta que llegamos al rango 49000 y superior, pero preferiríamos no tener que cambiar nuestro rango de números de puerto normal a menos que sea completamente inevitable.
Hemos pasado muchas horas intentando encontrar alguna solución sin suerte. Realmente esperamos que alguna persona brillante tenga alguna idea que le permita encontrar la causa del problema.
Respuesta1
Como lo identificó @HelpingHand en sus comentarios sobre la pregunta original, el problema era Windows DirectAccess.
El cliente no estaba utilizando DirectAccess, pero Windows Server Essentials lo incluía preconfigurado para asignar todos los puertos del 6001 al 47000. Esto fue confirmado por el comando de PowerShell.
Get-NetNatTransitionConfiguration
lo que dio el siguiente resultado:
InstanceName : DirectAccess
PolicyStore : PersistentStore
State : Enabled
TcpMappingTimeout : 7200
InboundInterface :
OutboundInterface : {Ethernet}
PrefixMapping : {fd3b:4e13:1a52:7777::/96,0.0.0.0/0}
IPv4AddressPortPool : {192.168.1.10,6001-47000}
InstanceName : DirectAccess
PolicyStore : ActiveStore
State : Enabled
TcpMappingTimeout : 7200
InboundInterface :
OutboundInterface : {Ethernet}
PrefixMapping : {fd3b:4e13:1a52:7777::/96,0.0.0.0/0}
IPv4AddressPortPool : {192.168.1.10,6001-47000}
Ejecuté el comando PowerShell
Set-NetNatTransitionConfiguration –IPv4AddressPortPool @("192.168.1.10, 6001-10950", "192.168.1.10, 12050-47000")
lo que cambió las asignaciones de puertos para DirectAccess para dejar el espacio que necesitaba para nuestros servicios, y luego los puertos simplemente comenzaron a funcionar de inmediato. Ni siquiera tuve que reiniciar nada.
Gracias por tu ayuda @HelpingHand