AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

Ein Thema von hoika · begonnen am 14. Feb 2019 · letzter Beitrag vom 15. Feb 2019
Antwort Antwort
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
6.976 Beiträge
 
Delphi XE4 Professional
 
#1

Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 14. Feb 2019, 16:01
Hallo,
eine schöne kurze Erklärung meines Problems steht im Titel.

Etwas ausführlicher:
Ich habe ein COM-Objekt in einer DLL, was per (Indy und OpenSSL) eine verschlüsselte Verbindung zu einem anderen Rechner herstellt.
Das Objekt tauscht diverse Daten aus und gibt mir Bescheid, wenn irgendwas wichtiges sein sollte.
Das klappt auch meistens ganz gut.
Das wäre die ausgehende Verbindung.

Aber jetzt kommt's:
Wenn das COM-Objekt in einer TCP-Serververbindung eine Port aufmacht und auf eingehende Verbindungen wartet,
wird es oft durch die Firewall blockiert.
Mit Firewall sind auch die Internet Security Suites gemeint, nicht nur die Windows-Firewall.

Jetzt die Frage:
Was für eine Regel erstelle ich denn jetzt und wofür?
Für mein Programm, was das COM-Objekt erzeugt, oder für die DLL, die das COM-Objekt enthält?

Bei einigen SecSuites kann ich klickern was ich will, ich bekomme keine eingehende Verbindung.
Heiko

Geändert von hoika (14. Feb 2019 um 16:03 Uhr)
  Mit Zitat antworten Zitat
peterbelow

Registriert seit: 12. Jan 2019
Ort: Hessen
238 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 13:37
Bei meinem früheren Brötchengeber waren alle Arbeitsplatzrechner per firmenweiter Richtlinie so konfiguriert, dass sie keine eingehenden TCP Verbindungen zuließen. Server-artige Anwendungen konnten nur auf speziellen Serverrechnern mit entsprechendem Betriebssystem (Windows Server oder Linux) installiert werden, nach erheblichem Papierkrieg im Vorfeld. Globale IT-Abteilungen sind ziemlich paranoid, leider aus gutem Grund...
Peter Below
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
6.976 Beiträge
 
Delphi XE4 Professional
 
#3

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 13:41
Hallo,
danke für die allererste Info

Es handelt sich hier um Einzel-Rechner beim Kunden,
die irgendeine Internet Security Suite drauf haben.

Sobald die ausgeschalten ist, klappt die Verbindung.
Nur weis ich nicht, was ich außer "ja, mein Programm darf eingehende Verbindungen" noch einstellen soll.
Heiko
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.547 Beiträge
 
Delphi 6 Enterprise
 
#4

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 13:51
Kann man nicht expliziert den Port freigeben, auf den deine Serveranwendung "hört"?
Ralph
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
6.976 Beiträge
 
Delphi XE4 Professional
 
#5

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 15:17
Hallo,
ist auch gemacht worden, hat aber nichts geholfen.
Heiko
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.547 Beiträge
 
Delphi 6 Enterprise
 
#6

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 15:39
Ich bin da eigentlich aus dem Thema und frage immer unsere Systemintegratoren um Hilfe, aber braucht die Rückrichtung nicht auch einen Port und der wird (vom Client?) in einem bestimmten Bereich generiert und dem Server mitgeteilt, damit der auch antworten kann? Und muss der Port-Bereicht nicht ggf. auch in der Firewall freigegeben werden?
Ralph
  Mit Zitat antworten Zitat
Michael II

Registriert seit: 1. Dez 2012
Ort: Region Bern CH
280 Beiträge
 
Delphi 10.3 Rio
 
#7

AW: Firewall blockiert beim COM-Objekt eingehende TCP-Verbindungen

  Alt 15. Feb 2019, 22:32
Hast du dies probiert um festzustellen, welche .exe bzw. welche Komponenten beteiligt sind an der Verbindung:

Starte den Server auf einer Kiste, auf welcher die Verbindung klappt. Verbinde mit deinem Server.

cmd als Administrator aufrufen und
netstat -b
ausführen. Mehr dazu findest du wie üblich via netstat /?

Dank netstat siehst du, welche Dinge du freigeben musst.

Viele Sicherheitsprogramme führen Listen von Programmen/Komponenten welche "alles oder viel" dürfen; Programm/Komponenten zu dieser Liste hinzufügen und es sollte klappen.

Wenn du deine Anwendung an viele Leute verteilst, dann ist es sicher praktisch, wenn du während dem Setup Prozess wenn immer möglich diese Freigaben in dein Setup Programm integrierst. (Und beim Deinstallieren wieder entfernst.) Für die Windows Firewall geht dies zum Beispiel auch mit Delphi via HNetCfg.FwPolicy2.

Und: Falls dein Programm dann immer noch blockiert wird: Selbst wenn dein Programm nur ein paar tausend Mal installiert wird, helfen dir viele Anbieter von Sicherheitslösungen, indem sie dir mitteilen, wie deine App freigegeben werden kann. Bei einigen Anbietern musst du deine jeweils aktuelle App auf einen ftp Server hochladen, bei anderen genügt es, wenn du ihnen den Downloadlink z.V. stellst. Ganz sicher hilfreich ist es, wenn deine App signiert ist.
Michael Gasser
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:55 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf