Hallo, Profis, ich möchte euch mal um Hilfe bitten, weil mein Googlefu keine Erkenntnisse gebracht hat. Folgende Situation: Ich habe an zwei Standorten jeweils einen Windows-PC, der mit einem Router ganz normal an einer Internetstrippe hängt, eine Seite Fritzbox/DSL, die andere Glasfaser und dementsprechende Hardware vom Provider. Zwischen den beiden PCs soll eine Verbindung via TCP und UDP bestehen, auf einem bestimmten Netzwerkport. Öffentliche IP und Portweiterleitungen sind da und funktionieren auch (mit anderen Diensten). Auf beiden PCs läuft ein Client, der leider nur anzeigt, das die Verbindung über ein Relay des Herstellers läuft, nicht direkt. Die Firewalls sind angeblich aus- wie eingehend offen (zumindest stehen da entsprechende Regeln drin). Also alles auf "müsste so gehen", tut's aber nicht (richtig). IPs bzw. DynDNS ist korrekt, öffentliche IPv4 ohne IPv6/CGNAT passen. Zur Diagnose suche ich nun eine Möglichkeit, unter Windows auf "meinem" PC mittels eines Scanners zu prüfen, welche Ports ich auf einem anderen Remotegerät (WAN nicht LAN!) erreichen kann. Evtl. auch "mein Scanner pingt zum Test einen öffentlich verfügbaren Server an, der dann sagt 'hey, du hast mich gerade auf Port 4711 angestupst'". Ich könnte dann sagen "bei mir geht Port 12345 ausgehend, es liegt an deinem Ende" oder eben nicht, dann wüsste ich das bei mir was nicht stimmt. Ich finde aber nur Vorschläge wie ich sehen kann welche Ports auf meinem Router zumindest irgendwie beantwortet werden (öffentlicher Server scannt meine öffentliche IP) oder wie ich auf meinem PC offene Ports anzeigen kann (ein Programm wartet bei mir auf Daten). Beides liefert im übrigen plausible Info, aber ich weiß halt nicht ob es auch ausgehend funktioniert. Kennt da einer von euch was? Und nein, VPN ist keine Alternative.
Früher gab es für Windows mal Portscanner wie YAPS (Yet Another Port Scanner). Kann Windows mittlerweile nicht auch Linux ? Dann mit nmap (IP) -p (Port) -open
:
Bearbeitet durch User
Nmap gibt es auch für Windows (mit ein paar Einschränkungen). Oder du machst mal ein telnet IP Port und schaust was zurück kommt. Habt Ihr keine Lust auf Tunnelverwaltung, oder warum der Gang über öffentliche IPs?
:
Bearbeitet durch User
Jens M. schrieb: > Auf beiden PCs läuft ein Client, der leider nur anzeigt, das die > Verbindung über ein Relay des Herstellers läuft, nicht direkt. Woher soll der ominöse Client wissen, unter welcher IP die Gegenstation erreichbar ist. Üblicherweise sucht solche Software im lokalen Netz per Broadcast ein Gegenüber und geht im Fehlerfall über das Gateway des Herstellers.
Klingt nach einer richtig schön kaput gehackten Konfiguration wenn VPN nicht geht. Ich würde mit dem kleinen Besteck anfangen: Zuerst natürlich das Multimeter des Networking anklemmen: wireshark. Was geht wirklich raus, was kommt wirklich zurück? Dank der Paketschnittstelle der Fritzbox auch auf ihrer WAN-Seite, nicht nur im LAN. ping. Ja, ist ICMP, aber zeigt ob da überhaupt was hin und her geroutet wird. Wenn nicht irgend welche idiotischen Admins mit im Spiel sind die ICMP abgeklemmt haben. traceroute. Ein richtiges, dass TCP, UDP und Portnummern kann. Nicht das dreckelige Windows tracert. Für TCP auch einfach mal curl. Und mit netcat kann man ebenfalls mal remote mit TCP oder UDP anklopfen. Notfalls sogar telnet für TCP. Dann, und nach reiflicher Überlegung wie man vermeidet vom Provider oder Admins auf der anderen Seite eins auf den Deckel zu bekommen, das große Besteck: nmap. Aber ehrlich, was soll das bringen? Wenn ich auf port xyz will/muss, dann nützt es mir nicht zu wissen dass es auf der anderen Seite einen offenen Port abc gibt. xyz muss antworten, und das sagen mir die anderen Tools schon. Ja, ich kann nmap auf einen einzigen Port ansetzen. Das machen die anderen Tools schon.
:
Bearbeitet durch User
Fred F. schrieb: > Früher gab es für Windows mal Portscanner wie YAPS (Yet Another Port > Scanner). Sowas ähnliches: https://www.heise.de/download/product/portscan-70308 Jens M. schrieb: > Öffentliche IP und Portweiterleitungen sind da und funktionieren auch Fehlt nur noch das Schild "hack me, please..."
Fred F. schrieb: > Portscanner wie YAPS Yaps hatte ich vor Jahren mal, aber seit W10 wird der glaub ich vom Defender gekillt. Hab ich schon ewig nicht mehr benutzt, da bin ich gar nicht drauf gekommen. Muss ich mal ausprobieren, vielleicht ist das schon was... Man sieht manchmal den Wald vor Bäumen nicht... Ob das ins Internet geht? Axel G. schrieb: > telnet IP Port Da müsste ich ja 65535mal probieren... Axel G. schrieb: > Habt Ihr keine Lust auf Tunnelverwaltung, oder warum der Gang über > öffentliche IPs? Da ist prinzipiell ein Server, und "eine Menge" Clients, primär Windows aber auch Android. Diese Anwendung ist das einzige was so laufen soll, alles andere ist Cloud oder normales Internet. Dafür eine VPN-Geschichte aufziehen ist zuviel Aufwand. Zumal es ja eigentlich gehen sollte und auch so gedacht ist, aber aus irgendeinem Grund sehen sich die Clients nicht direkt. Mario M. schrieb: > Woher soll der ominöse Client wissen, unter welcher IP die Gegenstation > erreichbar ist. Das ist schon so vorgesehen: der Hersteller betreibt "Telefonbuchserver" und "Relayserver". Die Clients haben IDs, melden sich beim Telefonbuchserver, der sagt die Erreichbarkeit des anderen an, die Verbindung wird versucht (steht im Log), dann kommt "Client can't be reached, trying Relay", und bingo geht, aber eben "Connection is relayed". Angeblich brauchts nur einen eingehenden Port TCP und UDP, und die FW-Regeln stehen auch so an beiden Enden. Hannes J. schrieb: > Klingt nach einer richtig schön kaput gehackten Konfiguration wenn VPN > nicht geht. VPN "ginge", wird aber als zu viel Aufwand nur dafür gesehen. Hannes J. schrieb: > der > Paketschnittstelle der Fritzbox auch auf ihrer WAN-Seite Uhja, auch ein Tipp den ich testen kann, danke. Hannes J. schrieb: > ping. Ja, ist ICMP, aber zeigt ob da überhaupt was hin und her geroutet > wird Geht Ping auf einen öffentlichen DSL-Anschluss in die Fritzbox und kommt zurück? Kann ich kaum glauben. Hannes J. schrieb: > traceroute. Ein richtiges, dass TCP, UDP und Portnummern kann. Nicht das > dreckelige Windows tracert Du kennst nicht zuf#llig eins für windows das taugt? Linux kann ich nicht so toll... Hannes J. schrieb: > und nach reiflicher Überlegung wie man vermeidet vom Provider oder > Admins auf der anderen Seite eins auf den Deckel zu bekommen Der Admin auf beiden Seiten ist der gleiche, die Telekom sollte recht frendlich sein, der Glasanbieter ist eine kleine lokale Bude die selber Nerdet. Das wird kein Problem sein. Hannes J. schrieb: > Wenn ich auf port xyz > will/muss, dann nützt es mir nicht zu wissen dass es auf der anderen > Seite einen offenen Port abc gibt. xyz muss antworten Richtig. Mein Problem ist irgendwo in der Kette: PC - Router/Firewall/Modem - DSL - Internet - Glas - Medienadapter - Router/Firewall - PC Die regeln sehen gut aus, da steht dementsprechend "Client darf jeden:Port erreichen" und "Eingehend Port weiterleiten auf Server". Da stellt sich mir die Frage: - Komme ich auf meinem PC gar nicht aus der Windows-Firewall raus? Das Relay geht über https, das klappt ja, ist aber sehr langsam. - komm ich aus meinem Router ins Internet, oder blockt die Firewall? - Lässt der Provider (an beiden Enden) einen Client eine Verbindung auf diesen Port aufbauen? Ist eine nicht-Standard-Nummer... - Komme ich am anderen Ende auf diesem Port in den Router? - Oder durch die Firewall? - Oder bis in den PC, aber nicht durch die Windows-FW? Wie finde ich das raus? Wireshark scheint da auskunftsfreudig, aber da muss ich mich ausgiebig mit beschäftigen, das ist ja schon was kompliziert... Ich kann zwar einen Testclient via Teamviewer bedienen, aber ist doch schon was mühsam. Der Android-Client ist leider recht schweigsam, da seh ich nur rot/gelb/grün, die Windows-App hat wenigstens so eine Logbuch-Liste, wo ich zuindest erahnen kann wie der Partner erreicht wird, mit IPs und so. Da seh ich auch die WAN-IP, aber eben "can't be reached".
Icke ®. schrieb: > Fehlt nur noch das Schild "hack me, please..." Ach, mal halblang. Ein spezieller, per SHA gesicherter TCP-Zugang auf einem Nonstandard-Port, da geht gar nichts wenn du nicht den richtigen Schlüssel hast. Und mehr als eben dieser Port ist auch nicht auf. Die Software ist speziell, gegen Fuzzing oder Sicherheitslücken kann man nichts machen, aber eine offene SSH oder http dürfte ähnlich gefährlich sein.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.