Wir haben (in Go und Delphi) mehrere Windows-Mikrodienste geschrieben, die auf HTTP-Anfragen an bestimmten Ports im Bereich 11000-12000 antworten. Diese sind so konzipiert, dass sie intern innerhalb der Domäne oder des privaten Netzwerks des Clients ausgeführt werden (also nicht im Internet).
Sie laufen perfekt auf allenaber einunserer über 50 Clientsysteme auf Betriebssystemen von Windows 7/10/11 bis Windows Server 2008R2/2012/2016/2019. Der Installationsprozess für jeden dieser Dienste richtet Regeln in der Windows-Firewall ein, um die Anforderungen an jede Dienst-EXE zu akzeptieren.
Auf dem einzigen Clientsystem, auf dem sie nicht funktionieren, läuft Windows Server 2016 Essentials. Dies ist das einzige Clientsystem, auf dem dieses spezielle Betriebssystem läuft, daher könnte dies ein Faktor des Problems sein.
Selbst wenn man lokal einen Webbrowser auf diesem System verwendet, um die Dienste abzufragen, funktionieren sie nicht. Die Anfragen warten einfach eine Weile und dann läuft ein Timeout ab: ERR_CONNECTION_TIMED_OUT. Dieselben Anfragen an dieselben Ports an Adresse 127.0.0.1 (localhost) funktionieren jedoch sofort – was beweist, dass die Dienste tatsächlich ausgeführt werden. Die Art des Fehlers, wenn der Zieldienst nicht ausgeführt wird oder wenn wir den falschen Port ansprechen, ist anders. In diesem Fall erhalten wir schnell eine „Verbindung verweigert“-Fehlermeldung: ERR_CONNECTION_REFUSED
Auf dem System sind keine Antiviren- oder Firewallprodukte von Drittanbietern installiert. Es wird nur Windows Defender mit der normalen Windows-Firewall verwendet. Wir haben alles Mögliche mit der Windows-Firewall versucht, einschließlich der vollständigen Deaktivierung. Nichts von dem, was wir versucht haben, hat einen Unterschied gemacht.
Wir haben viele alternative Portnummern ausprobiert, hatten aber keinen Erfolg, bis wir den Bereich 49.000 und höher erreichten. Wir würden aber wirklich lieber nicht von unserem normalen Portnummernbereich abweichen, es sei denn, es ist absolut unvermeidlich.
Wir haben viele Stunden damit verbracht, erfolglos nach einer Lösung zu suchen. Wir hoffen wirklich, dass irgendein kluger Mensch da draußen eine Idee hat, die zur Lösung des Problems führt.
Antwort1
Wie @HelpingHand in seinen Kommentaren zur ursprünglichen Frage feststellte, lag das Problem bei Windows DirectAccess.
DirectAccess wurde vom Client nicht verwendet, aber Windows Server Essentials war bereits so vorkonfiguriert, dass alle Ports von 6001-47000 zugewiesen wurden. Dies wurde durch den PowerShell-Befehl bestätigt.
Get-NetNatTransitionConfiguration
was zu folgendem Ergebnis führte:
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}
Ich habe den PowerShell-Befehl ausgeführt
Set-NetNatTransitionConfiguration –IPv4AddressPortPool @("192.168.1.10, 6001-10950", "192.168.1.10, 12050-47000")
Dadurch wurden die Portzuweisungen für DirectAccess geändert, um die Lücke zu lassen, die ich für unsere Dienste brauchte, und dann funktionierten die Ports sofort. Ich musste nicht einmal etwas neu starten.
Danke für eure Hilfe @HelpingHand