Tool zum Testen von Verbindungen

Es gibt 9 Antworten in diesem Thema, welches 981 mal aufgerufen wurde. Der letzte Beitrag () ist von gierig.

    Hallo zusammen,


    zunächst: Ich habe in den Tags zwar die UDM-Pro angegeben (weil Zwangsauswahl), aber meine Frage ist im Prinzip Hardware-unabhängig.


    Bei Kunden entsteht gelegentlich das Problem, dass ein Softwareanbieter sein Produkt nicht zu Laufen bekommt. Häufig kommt es dann zur Standard-Vorwärtsverteidigung: "Die Firewall blockt da bestimmt was".

    Nun wissen wir Ubiquitianer ja, dass eine Unifi-Firewall ohne weitere Konfiguration weder vom LAN in Richtung Internet, noch zwischen VLANs irgendetwas blockt. Der Beweis, dass ein Gerät irgendetwas nicht tut, ist naturgemäß schwer zu erbringen.

    Wie geht Ihr in solchen Situationen vor? Einfach einen Portscanner gegen den Host laufen lassen, den die problembehaftete Software erreichen möchte?

    Einmal editiert, zuletzt von Networker () aus folgendem Grund: Tippfehler

    Was genau ist den das Fehlerbild bei der Software?

    gibt diverse tests:

    -Portscan -> Thema Firewall beseitigt

    -NSlookup am client und Server

    -Durchsatz & performance messen mit iperf


    bei Filebasierten Anwedungen einfach mal Testweise die Rechte erhöhe für die Freigaben.


    Windows Server ? auf HyperV? Da gibt es diverse Optimierungen im Bereich Netzwerk bzgl. dem Offloading z.B. was massiv die performance erhöhen können.

    bzgl. Firewall kannst auch einfach mit 2 Klicks in der Windows Firewall das logging aktivieren und dann siehst du nachweislich ob etwas verworfen wurde.


    Aber ja, diese Standardaussage ist sehr wohl bekannt :grinning_squinting_face: :smiling_face:

    Es gibt aktuell gar keinen konkreten Fall, es geht fast immer um Anwendungen, die irgendeine Gegenstelle im Internet erreichen wollen.

    Immer wieder gerne z.B. irgendwelche KIM-Clients, die nichtmal dazu in der Lage sind, sinnvolle Fehlermeldungen zu produzieren. Diese Art Software kennt man allerdings nur, wenn man sich mit IT im Gesundheitswesen bechäftigt.

    Ja gut, das läuft aber dann über den TI Konnektor - das ist oft eine Kombi aus Konnektor Konfig Fehler bzgl. generelle TI instabilität, empfindliche Software und ggf. Windows Fehler und auch noch die Praxissoftware in der das Ganze ggf. eingebunden ist

    Betreue selbst einige Ärzte, ist also nicht unbekannt :smiling_face:

    Da ist dann wirklich die Frage - wie ist der gesamte Aufbau ...


    Und glaub mir - selbst mit technischen Nachweisen das dein Zeug nix blockt kommst du da nicht weit, die Jungs für die Konnektoren etc. sitzen auf einem sehr, sehr hohem Ross.

    Ja, die TI-Provider und DVO lassen sich ihre regelmäßigen Minderleistungen recht erfolgreich vergolden und werden dabei auch noch politisch eskortiert.

    Aber wie gesagt, ich möchte das hier gar nicht an einer bestimmten Software oder einem konkreten Fall festmachen.


    Ich hätte in solchen Fällen einfach gerne einen unkomplizierten Ansatz, dem Support-Menschen zu zeigen: "Hier, außerhalb Deiner Software klappt die Verbindung, also häng' Dich rein und lass uns die Suche nach Ausflüchten bitte beenden!".

    Wir haben hier diverse Kunden mit dem Dreck, allerdings nirgends Unifi Gateways im Einsatz, höchstens WLAN. Aber ja die Probleme kenne ich. Ich habe allerdings auch nie irgend ein Tool gebraucht. Entweder ich habe die benötigten Ports freigegeben bzw den Proxy ausgeschaltet oder halt nicht.

    Für schnellen Check Advanced Portscanner

    Advanced Port Scanner – der kostenlose schnelle Portscanner


    Ansonsten Wireshark

    Ich nutze für solche Sachen eigentlich hauptsächlich zwei Basis-Kommandozeilen-Tools, die m.W. auch auf Windows vorhanden sind, bzw. wenigstens nachrüstbar sind. Das sind einmal 'curl' für alles, was irgendwie HTTP oder HTTPS spricht - funktioniert auch für viele HTTP-basierte REST APIs ganz hervorragend.

    Wenn's hingegen irgendein anderes Protokoll ist, gibt's immer noch das uralte 'telnet $HOST $PORT' - damit habe ich den Kollegen schon nachgewiesen, daß sie eine MySQL Datenbank (Port 3306) von ihren Büchsen sehr wohl erreichen können und daß es eher an deren komischer Applikation liegen muß, warum die nicht mit der DB sprechen will.

    Ansonsten halt ggf. auch andere Tools, je nach Bedarf, 'netstat' auf der lokalen Büchse um nach Verbindungen zu suchen, das bereits erwähnte Wireshark (oder, auf der Kommandozeile, 'tcpdump'), 'nmap' - ist halt auch immer von der Fragestellung abhängig. Jedes Tool hat seine Stärken und Schwächen.

    logs logs logs und nochmal logs - das einzig Sinnvolle und wirklich Handfeste. Sei es Firewall Seitig (Windows Firewall sowie des unifi Teil), windows Logs, Anwendung log (der Kim Client schreibt da ja auch was) als auch vom Konnektor :smiling_face:

    nmap als universeller PortScanner (alles andere is Spielzeug :smiling_face: )


    telnet Host Zielport  um zu prüfen ob port auch Verbindung annimmt oder Daten zurückkommen. Denn selbst da abartigste Protokoll das meinetwegen die connection wieder gleich beendet weil es nicht das bekommt was es erwartet, wird trotzdem erstmal die Verbindung öffnen. Das ist auch im Jahre 2024 DAS Tool um TCP Verbindungen zu testen.


    Das alleine reicht meist schon für "Kuckst du wir kommen da hin"


    Ist zwar bei Win/Linux/Mac nicht mehr standardmäßig drauf aber immer noch

    installierbar...


    netcat / nc

    ist nen netter ersatz für telnet, weil kann ggf auch UDP verschießen.

    Aber UDP ist eigentlich immer doof weil zustandslos und nichts zurückkommen muss

    wie bei TCP. Da ist dann meist eher um UDP traffic zu erzeugen um dann mit....


    tcpdump / tshark / wireshark im Prinzip alles das nen PCAP machen kann um

    es direkt zu sehen (tshark als Kommandozeilen Version von Wireshark hat Filter ohne Ende)

    oder dann halt pcap es sich in Wireshark zu holen um zu schauen ob

    A mit B und andersrum spricht.

    VIELE Viele Geräte / Rechner haben zu mindestens tcpdump mit dabei.

    Dabei geht dann oft garnicht um den (oft verschlüsselten) PayLoad sondern um

    L2-L4 also Ethernet, IP Adressen und PORTS um zu schauen was wo und wohin.


    Das geht natührlich nicht immer, weil Gerät kann es nicht oder auf Kunden Gerät /

    Server / Device darf nichts installiert werden. Daher:


    Mann in the Middle

    Im einfachsten fall nen Mirror / Span port am Switch.

    Oder zwei USB Karten am Rechner als Bridge zusammen gedengelt und

    dazwischen gehangen, verhält sich dann wie nen zwei SwitchPorts.

    dann mit Wireshark die Bridge abgehört. Und schon sieht man die Traffic von A nach B.


    FrüherTM hatte ich für sowas nen alten 8 Port Cisco der dann halt nen

    Monitoring Port (heißt bei Cisco SPAN) auf Port 8 und die anderen waren

    dann halt normale ports.


    Dazu und fürs "Allgemeine" die default dinge wie nslockup / dig ggf. im trace debug / Detail modus. Das Gute alt Ping ggf. mit größeren Paketen + dont fragment Flag oder

    oder kleinen TTL um einen Routetrace zu "manual" durchzuführen.

    Curl und co wurden oben schon erwähnt.


    Und tatsächlich grade bei Webanwendung die "Webentwickler" tools

    die quasi jeder der großen Browser mitbringt. Da ist schnell entdeckt wenn

    Resource y von Server X nicht nachgeladen werden konnte der nen ganz anderen

    Namen hat als Dokomentiert und Freigeben ist.