☰

Ошибка подключения к порту HTTP микросервиса на Windows Server

tag-icon • tag-icon http windows-server-2016
Ошибка подключения к порту HTTP микросервиса на Windows Server

Мы написали (на Go и Delphi) несколько микросервисов Windows, которые отвечают на HTTP-запросы на определенных портах в диапазоне 11000-12000. Они предназначены для работы внутри домена или частной сети клиента (т. е. не в Интернете).

Они отлично работают на всехКроме одногоиз наших 50+ клиентских систем на ОС от Windows 7/10/11 до Windows Server 2008R2/2012/2016/2019. Процесс установки каждой из этих служб устанавливает правила в брандмауэре Windows для приема запросов к каждому exe-файлу службы.

Единственная клиентская система, с которой они не работают, работает под управлением Windows Server 2016 Essentials. Это единственная клиентская система, работающая под управлением этой конкретной ОС, так что это может быть фактором проблемы.

Даже локально используя веб-браузер на этой системе для запроса служб, они не работают. Запросы просто ждут некоторое время, а затем истекает время ожидания: ERR_CONNECTION_TIMED_OUT. Однако те же самые запросы на те же самые порты по адресу 127.0.0.1 (localhost) срабатывают мгновенно, что доказывает, что службы действительно работают. Режим отказа, когда целевая служба не работает или если мы обращаемся к неправильному порту, отличается. В этом случае мы получаем быстрый отказ «отказано в подключении»: ERR_CONNECTION_REFUSED

В системе не установлены сторонние антивирусы или брандмауэры, которые используют только Windows Defender с обычным брандмауэром Windows. Мы перепробовали все, что только могли придумать с брандмауэром Windows, включая его полное отключение. Ничто из того, что мы пробовали, не дало результата.

Мы пробовали использовать множество альтернативных номеров портов, но не добились успеха, пока не достигли диапазона 49000 и выше. Однако мы бы предпочли не менять наш обычный диапазон номеров портов, если только это не является абсолютно неизбежным.

Мы потратили много часов, пытаясь найти хоть какое-то решение, но безуспешно. Мы очень надеемся, что у какого-нибудь светлого человека есть идея, которая приведет к поиску причины проблемы.

решение1

Как указал @HelpingHand в своих комментариях к исходному вопросу, проблема была в Windows DirectAccess.

DirectAccess не использовался клиентом, но Windows Server Essentials поставлялся с предустановленной настройкой для выделения всех портов от 6001 до 47000. Это было подтверждено командой PowerShell

Get-NetNatTransitionConfiguration

что дало следующий результат:

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}

Я выполнил команду PowerShell

Set-NetNatTransitionConfiguration –IPv4AddressPortPool @("192.168.1.10, 6001-10950", "192.168.1.10, 12050-47000")

что изменило распределение портов для DirectAccess, чтобы оставить зазор, необходимый для наших служб, и затем порты просто начали работать немедленно. Мне даже не пришлось ничего перезапускать.

Спасибо за помощь @HelpingHand

Связанный контент