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.
Vage Vermutung: Riecht nach kaputtem Hole (NAT) Punching, falls es in der Anwendung/Protokoll überhaupt umgesetzt ist. Solange man das Protokoll nicht kennt kann man da nur raten. Was der Relayserver da noch reinmurkst weiss auch keiner, alles viel zu vage für eine Ferndiagnose. Da hilft auch kein Wireshark, vor allem wenn du keine Ahnung hast und wie das Protokoll aussieht. Hat das überhaupt schon mal problemlos funktioniert oder ist das nur zwischen diesen beiden Rechnern ein Problem?
Jens M. schrieb: > Ein spezieller, per SHA gesicherter TCP-Zugang auf einem > Nonstandard-Port, da geht gar nichts wenn du nicht den richtigen > Schlüssel hast. Security by optimism. Portweiterleitungen sind nicht ohne Grund ein sicherheitstechnisches NoGo und in Zeiten, wo jeder 0815 Heimrouter VPN beherrscht, auch nicht mehr notwendig. Die Einrichtung ist gar nicht sooo schwierig und man umschifft Probleme wie deines, da sich die beteiligten Geräte ähnlich wie im lokalen Netzwerk verhalten. Steck ein bißchen Zeit rein und du wirst die Vorteile schätzen lernen.
Jens M. schrieb: > Da müsste ich ja 65535mal probieren... Wieso? Du kennst den Port, den der entfernte Router ins Internet hängt. Das ist im Rahmen der Portweiterleitung so eingerichtet. Das ist also nur genau eine Portnummer.
Frank D. schrieb: > Riecht nach kaputtem Hole (NAT) Punching, falls es in > der Anwendung/Protokoll überhaupt umgesetzt ist. Joa, so schaut das für mich aus. Ich bin nun kein Netzwerkfux, aber bei den Regeln der FW kann ich ja testen "80/443 verboten"=Browser kaputt, "80/443 erlaubt" = Browser geht, jeweils zusammen mit einer "Drop everything"-Regel (ja, plus Kleinscheiß wie NTP, DHCP und DNS). Nach dem gleichen Muster kommt dann eine "Allow 12345" dazu und dann sollte das nach Hilfe und Support gehen. Du meinst aber mit "Protokoll" nicht TCP, sondern wie die App mit dem Server bzw. Partner redet, oder? Frank D. schrieb: > Was der Relayserver da noch > reinmurkst weiss auch keiner Der erlaubt eine Verbindung beider Partner via HTTP zu sich und liefert dir meine Daten und andersrum. HTTP weil das meist funktioniert, Teamviewer machts auch so. Frank D. schrieb: > Hat das überhaupt schon mal problemlos funktioniert oder ist das nur > zwischen diesen beiden Rechnern ein Problem? Ich nehme an das eine angeblich mehrfach verkaufte Lösung schon prinzipiell funktioniert, und "bei mir" eben nicht, das juckt mich. Und es hat hier noch nie ohne Relay geklappt, aber das sieht man erst seit dem letzten Update. Dank Relay geht's schon irgendwie, aber direkt wär geiler: eine Testinstallation mit beiden Partner im LAN zeigt was eigentlich geht, zum tricksen mit einem Switch dazwischen mit 10MBps. Trotzdem wesentlich besser als aktuell übers Internet. Daraufhin hab ich ins Log geschaut und das Relay gesehen. Und ja: auch die beiden LAN-Partner schauen erst ins Telefonbuch, bekommen dann beide ihre LAN- und WAN-Ports und Adressen mitgeteilt, schauen dann ob sie den anderen Partner per LAN sehen können und ab geht's. Icke ®. schrieb: > Portweiterleitungen sind nicht ohne Grund ein > sicherheitstechnisches NoGo und in Zeiten, wo jeder 0815 Heimrouter VPN > beherrscht, auch nicht mehr notwendig. Wie funktioniert VPN? Der eine Router hat einen Port offen, wo man anklopfen kann und der lässt einen dann rein? Wo ist der Unterschied zu jetzt? Und was passiert, wenn alle Geräte sich via VPN über eine schmale Upstream-DSL16-Strippe quälen müssen, wo es hier nur um ein paar hundert Bytes alle paar zig Sekunden geht? Harald K. schrieb: > Du kennst den Port, den der entfernte Router ins Internet hängt. sollte... - Yaps liefert übrigens Timeout auf allen mir bekannt offenen Ports von A zu B. - Ping geht durch. - Tracert liefert mir 8 Hops, aber nur unter Windows ;) - Ein öffentlicher Portscan geht ja nur vom Internet zum Ziel, die sind beide gut. Ich vermute also das mindestens einer der beiden entweder von der FW oder vom Provider blockiert wird eine Verbindung auf einem freien hohen Port aufzubauen.
Jens M. schrieb: > Wie funktioniert VPN? Der eine Router hat einen Port offen, wo man > anklopfen kann und der lässt einen dann rein? Wo ist der Unterschied zu > jetzt? Ein offener Port am Router selbst ist nicht das Gleiche wie eine Portweiterleitung ins lokale Netzwerk. Schon gar nicht bei ausgereiften Technologien wie VPN. Für jemanden, der nicht mal weiß, wie man einen offenen Port erkennt, lehnst du dich ziemlich weit aus dem Fenster. Aber sei es drum, dein Problem.
Jens M. schrieb: > Du meinst aber mit "Protokoll" nicht TCP, sondern wie die App mit dem > Server bzw. Partner redet, oder? Ja, das Protokoll der Anwendung meine ich. Vielleicht leitet das zu schnell auf den Relayserver um wenn keine Antwort von der Direktverbindung zum anderen Client kommt oder die Anwendung fährt generell erst mal über Relayserver solange er nicht überlastet ist,... Frag am besten den Herstellersupport.
Icke ®. schrieb: > Für jemanden, der nicht mal weiß, wie man einen > offenen Port erkennt, lehnst du dich ziemlich weit aus dem Fenster. Tja, ich bin nun mal Windows-User, kein Linuxgeek. YAPS bringt mich nicht weiter, die Terminalprogramme (die wenigen die Windows hat) geben ebenfalls keine hilfreiche Info preis. Wireshark kenn ich vom Namen her, kenn ich mich aber nicht mit aus. Ob das was bringt muss ich sehen, ich hab meine Zeit aber auch nicht gestohlen und denke ich muss Stunden damit zubringen bis ich verstehe wie ich es benutzen muss, und dann auch noch die gewonnenen Protokolle lesen. Alle anderen öffentlichen Dienste zeigen mir zwar einen offenen Port an, aber eben nicht ob der auch für mich offen ist, das Problem kann ja auch mein ausgehender Port/Router/Firewall/Provider sein. Und wenn ich sehe, wie professionelle IT-Dienstleister einfach mal eben Domaincontroller, Exchanges und irgendwelche Standard-Windows-PCs mit irgendeiner Freeware via Portweiterleitung ins Internet hängen, weil der Kunde und auch der DL keine Ahnung haben (oder keinen Bock, oder "wenig machen, viel Abrechnen"), da kann ein einzelner offener Port mit nicht mehr Schaden anrichten. Und lt. öffentlichem Scan ist genau dieser eine erwartete Port offen, sonst nix, von allen 65k Stück. Also verlasse ich mich da genau auf den Softwarehersteller, das der die Sache sicher genug gemacht hat. Also quasi als würde Fritz, Microsoft oder Cisco da sitzen, denen vertraue ich ja auch. Lt. Aussage Supporter: Jeder darf rein, der sofort von sich aus einen passenden Key liefert, also quasi im ersten Packet. Kein passender Key = Sperre. Die Keys sind eine Verkettung von TLS, AES128 und SHA, so genau konnte man mir das auch nicht sagen. Sollte aber m.E. sehr sicher sein. Ich verstehe nicht, wo das Problem sein soll, wenn ein einziger offener Port exponiert ist, und der Unterschied zwischen "ist ok" und "die Welt geht unter" ist ob 192.168.1.1 oder 192.168.1.2 das Paket beantwortet. Denn auch für den VPN-Verbindungsaufbau muss ein Port offen sein, und auf dem Router Software laufen (die vmtl. weniger oft aktualisiert wird, wenn überhaupt), und Schlüssel ausgetauscht werden (mit vmtl. ähnlichen Verfahren). Ich exponiere da ja keinen http oder SMTP... Ich mein, ich sowieso nicht, ich persönlich bin nur der einäugige unter den Blinden hier, der einzige User der zumindest weiß wie man USB korrekt anschließt. Das ganze Zeug kommt vom Systemhaus, die nehmen 85€/15min plus Anfahrt und machen genau gar nix, außer durchverkaufen. Frank D. schrieb: > Frag am besten den Herstellersupport. "Nur bei Ihnen gibts da Probleme, überall anders läuft das einfach so". Ich bin aber ein Mensch der wissen wie wie's funktioniert, nicht nur wie's geht. Ist heute nicht mehr gern gesehen, ich weiß. Frank D. schrieb: > die Anwendung fährt > generell erst mal über Relayserver solange er nicht überlastet ist Lt. Log wird die Direktverbindung zuerst und mehrfach probiert, weil die einfach schneller und ohne dritten Mann auch "intimer" ist. Dazu werden alle vom Telefonbuch genannten Verbindungen des Partners getestet, auch interne IPs, kann ja sein, das es da eine direkte Route gibt. Erst dann wird ein Relay probiert. Aber ein Timeout kann natürlich auch sein. Ich vermute nach den Tests die ich mit den Tips hier aus dem Thread schon versucht habe, das ich eine ausgehende Sperre habe, obwohl die Regeln anders lauten (ich habe einen Ausdruck der Regeln der FW).
Jens M. schrieb: > 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. Ist mit Wireguard und einer FritzBox als Gegenstelle nicht mal das Problem.
Nutzt du auch den bekannten Port bei deiner Zielangabe? Also deine.öffent.liche.IP:Port ??
Jens M. schrieb [vieles] Oh weia. Bei all dem viertelverstandenem Halbwissen, was hier aus nahezu jedem Satz raustropft, schlägt der Kopf gleich dutzendfach auf die Tischkante. Bitte, lasst das unbedingt jemanden machen, der sein Fach nachweislich beherrscht! Ja, das kostet. Der nette "Internetfachmann" aus der Bastelbude nebenan für einen Fuffi die Stunde ist nicht der richtige Ansprechpartner.
Max I. schrieb: > Bitte, lasst das unbedingt jemanden machen, der sein Fach nachweislich > beherrscht! Der hat's ja bislang gemacht, und wie gut es klappt sieht man ja. Max I. schrieb: > Der nette "Internetfachmann" aus der Bastelbude nebenan > für einen Fuffi die Stunde ist nicht der richtige Ansprechpartner. Das hab ich nicht zu entscheiden, hab's nicht entschieden und kann daa auch nicht beeinflussen. Ich kann ein Ticket aufmachen "geht nicht", das wird mit "is halt so" geschlossen. Meine Hoffnung ist das ich eins mit "Bitte so einstellen" mache und das dann a) passiert und b) hilft. Max I. schrieb: > Bei all dem viertelverstandenem Halbwissen, was hier aus nahezu > jedem Satz raustropft, schlägt der Kopf gleich dutzendfach auf die > Tischkante. Jaja, du warst schon in der Wiege allwissend. Ich versuchs ja zu verstehen und dazuzulernen... Du hast außer Gemaule noch gar nix beigetragen, sehr hilfreich, danke.
So, Rück- und Erfolgsmeldung: Nachdem ich mit einem Bekannten die Wireshark-Protokolle durchgesehen habe, ist uns aufgefallen das ein Verbindungsversuch von außen auf den Zielport zwar beantwortet wird, weiterer Transfer aber einfach ausläuft (timeout). Ich habe ein entsprechendes Ticket aufgemacht und dem Supporter bei der Arbeit über die Schultern geschaut: Des Rätsels Lösung war eine Firewallregel, die den Zugang zu "Private Nets" unterbindet, damit eben Traffic für das LAN nicht ins WAN weitergeht. Die Portweiterleitung funktioniert (wohl schon von der FW selbst beantwortet wg. des NAT, daher ist ein externer Portscan erfolgreich), aber dann hat die Firewall den eingehenden Traffic zu 192.16.x.x verworfen weil "solcher Verkehr nichts im Internet verloren hat". Diese Regel wurde korrigiert und schwupps bauen die Clients Verbindungen ohne Relay auf. Der "Einsteller" hat einfach bei der Regel festgelegt, das Verkehr der hier in der FW ankommt schon nicht mehr für das LAN sein kann und ungerichtet alles mit "Target is PrivateNets" auf Drop gestellt. Diese Logik wurde nun um "Source is Interface:LAN" ergänzt und gilt damit nur noch für ausgehenden Traffic. Eine weitere Regel verwirft alles eingehende das nicht für entsprechende Clients ist, so das die Hackfläche minimiert wird. Es bleibt ein exponierter Port auf einem Client über, ein Sicherheitsalbtraum, aber ein Komfortgewinn. Danke für den Tip mit Wireshark, aber das hat ganz schön gedauert bis ich da durchgestiegen bin... Wäre mit anderen Programmen auch nicht möglich gewesen, einzig die Firewallregeln haben das Phänomen bei "Einzelschrittsimulation" erklärt. Nennt man glaub ich Rubberducking, und dann hat's geklickt.
Jens M. schrieb: > ein Sicherheitsalbtraum, aber ein Komfortgewinn. Na dann ist ja alles gut. (Kopf -> Tischkante)
Jens M. schrieb: > Jaja, du warst schon in der Wiege allwissend. War klar, dass sowas kommt. Darum geht es doch gar nicht. > Ich versuchs ja zu verstehen und dazuzulernen... Grundsätzlich sinnvoll, aber: Jens M. schrieb: > ich persönlich bin nur der einäugige unter den Blinden hier, der > einzige User der zumindest weiß wie man USB korrekt anschließt. Von diesem Level aus ist's ein langer Weg zu Themen wie oben grob erkennbar. "Grob erkennbar" ist das nächste Problem, wenn man in einem Forum unscharfe Fragen stellt. Keiner kennt hier die Summe aller Umstände. > Du hast außer Gemaule noch gar nix beigetragen Weil es, wie oben umrissen, sinnlos und unseriös wäre. Gegen Einwurf hinreichender Mengen Zahlungsmittel kann man das auch ordentlich lösen. > sehr hilfreich, danke. Gerne.
:
Bearbeitet durch User
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.