Hallo Bernhard,
Danke für die Ergänzungen an der Portlist.
ich habe den Portscan mit
CurrPorts von Nirsoft durchgeführt.
Das ist eines der kleinen hilfreichen Tools aus dem Netzwerkbereich (Link ist und war beigefügt).
Insofern verlasse ich mich auf dieses Tool schon ein paar Jahre. Welche Technik da genutzt wird das weiß ich nicht. Ich vermute nur das das Tool die laufenden Prozesse überwacht und dann diejenigen auflistet die die Portanfragen starten oder gestartet haben.
Leider basieren viele Aussagen im Netzwerkbereich auf Hörensagen. Wenn man da mal etwas hinterfragt dann wird die Luft auf der Gegenseite oft dünn. Damit kann man sich bei einer Fehlersuche jedoch nicht zufrieden geben. Offengesagt verstehe ich auch nur bedingt was da der Traveler mit dieser Summe Ports so treibt. Liest man die ganzen Beiträge hier und im Netz, findet man entweder Spekulationen oder vollkommenes Fachchinesisch, wo ich an der Stelle dann auch nur noch Bahnhof verstehe. Vielleicht bekommen wir es ja hier hin da den Weg der Mitte zu finden.
Port und Gegenport, ok, das versteht man wenn es beim selben Port wie z.B. Port 25 bleibt, aber die Verfahrensweise auf der Gegenseite einen Port auszuhandeln und das dabei die Gegenseite auch noch erkennt welche Daten nun über den ausgehandelten Port transferiert werden und welcher Dienst dahinter steht, da muss ich sagen das ich da im Moment an meine Grenzen stoße.
Ich habe mir angewöhnt, fehlerhaften Prozesse, so weit möglich, "zu Fuß" nachzuvollziehen, nichts anderes was ihr Programmierer ja beim "debuggen" macht. Wäre doch super wenn wir den Traveler verstehen würden statt da nur zu mutmaßen.
Ist ja an sich ein einfaches und tolles Tool, aber wenn es denn wirklich so "easy" wäre, dann würden Hilfeschreie hier und sonstwo im Netz nicht so in der Form auflaufen wie es eben in Realität ist.
Im Klartext ist es wohl so das in erster Instanz die Frage steht, ob die interne Traveler-Kommunikation gestört ist oder ob es ein Problem bei der Darreichung der Ergebnisse ist, wie z.B. das HTTP Userinterface oder eben die Kommunikation zu den Endgeräten. Nach meinem Verständnis sollte die Fehlersuche an der Quelle, ergo beim Server beginnen und nicht am Ende der Kommunikationskaskade, hinter der Firewall.
Was die Zuordnung der Ports und deren evtl. Doppelnutzung meint:
Grundsätzlich gilt applikationstechnisch bei der Nutzung der Ports da eben das "Highlanderprinzip" "Es kann nur einen geben". Ergo reden wir jetzt bei der Portbetrachtung über Lotus Domino in Summe, da der Traveler ja eine Untermenge des Lotus Domino ist.
Port 80 und 443 da fingert Domino noch mit anderen WEBdiensten dazwischen, aber das war es dann auch schon.
Port 1352 ist der Port an dem der Notes-Client andockt so wie es im Ergebnis des Portscans aussieht wird da aber die Gegenrichtung genutzt.
Grundsätzlich steht zum besseren Verständnis ja auch auch die Frage welcher Port wird
bidirektional und welcher Port wird
unidirektional genutzt. Wenn wir das zweifelsfrei rausbekommen sind wir da wohl schon einen entscheidenden Schritt weiter.
Vielleicht kannst Du ja mal einen Vergleichsscan bei Dir durchführen ?
Eine gebündelte Fachfrage habe ich da aber noch:
Port 50125 und 50126 werden als
IPC Socket bezeichnet.
IPC verstehe ich als Merkmal der beabsichtigten oder vereinbarten speziellen Nutzung eines Ports, ergo das da mehr passiert als das da nur Daten durchfließen. Kann man da unterstellen das das so eine Art Schnittstelle zur Steuerung ist, in diesem Fall der Initiator z.B. Port 50126 ist und das der Regulator auf der Gegenseite sitzt, es im weiteren rein der internen Kommunikation dient und damit nicht firewall-technisch relevant ist ? Warum spricht man von Socket oder üblerweise von "Sockets" wenn man an sich die Summe bzw. das Grundanliegen der Ports meint ?
Danke für Deine Zeit...
Gruß
Stefan