4. TcpListener - Ungültige IP

TcpListener - Ungültige IP

  • M

    Danke! Jetzt sehe ich klarer. Mal ein Eintrag ohne diese Fachsprache 🙂

    Jetzt aber zurück zu meiner eigentlichen Frage: Welche IP muss man beim TcpListener - oder wie er dann auch heißen wird - nehmen?
    Und welche beim TcpClient?
    Die vom Router oder die vom PC? Oder eine Andere?

    Danke im Voraus

    0
  • J

    Also folgendes, meine Glaskugel hat durch die Funkkopfhoerer immer mal Stoersignale, aber ich hoffe mal, sie reicht noch soweit, um halbwegs dein Netzwerk-Setup zu erkennen.

    Im folgenden gehe ich davon aus, dass deine Maschine momentan ihre Adresse noch dynamisch kriegt und dass du einen Telekom-Speedport hast (sind umgelabelte Billigrouter aber die Firmware sieht zumindest aehnlich aus). Es kann also sein, dass die Anleitung hier nicht 100%ig auf dich zutrifft. Falls etwas offen bleibt oder bei dir anders funktioniert, fuehl dich frei, zu fragen.

    Insofern -- let's get dirty.

    Zunaechst einmal brauchst du die Windows-Adapter-Konfiguration. Druecke Win + R und geb dann ncpa.cpl ein. Anschliessend musst du deinen verbundenden Adapter finden. Ich weiss nicht, ob du ueber WLAN oder Ethernet verbunden bist; irgendein Adapter sollte jedenfalls verbunden sein.
    Jedenfalls klickst du mit rechts auf diesen und waehlst Status . Dort kannst du unter Details sehen, welche Adresse der Adapter momentan hat und ob DHCP aktiviert ist. Sofern du nichts umgekrempelt hast, duerfte DHCP wohl aktiviert sein und die Adresse 192.168.1.2 oder etwas aehnliches sein. 192.168.x.y ist ein privater Adressraum, d.h. diese Adressen werden nur hinter deinem Router vergeben (es gibt noch mehr solche Raeume, aber am einfachsten ist es wohl, vorerst bei diesem zu bleiben).
    Wichtig ist in deiner Adresse die Zahl x nach 192.168., denn die normale Netzwerk-Maske fuer die 192.168-er-Netze ist 255.255.255.0, d.h. du hast 255 Subnetze a 255 Adressen. Oder uebersetzt: 192.168.42.2 kann (unter Normalbedingungen) auf 192.168.42.5 zugreifen, nicht aber auf 192.168.43.2 oder 192.168.43.5. Es gibt Moeglichkeiten sowas zu verbinden, aber das fuehrt zu weit.
    Kurzum: Von 192.168.x.y praegst du dir erstmal das x ein. Anschliessend gehts in die Router-Konfiguration, im Beispiel hier also unter speedport.ip . Die Menues koennen unter anderen Routern anders heissen. Jedenfalls findest du unter Allgemeine Einstellungen auch die DHCP-Einstellungen . In meinem Fall kannst du dort auch die Adresse des Routers im LAN festlegen (was auch immer das unter DHCP zu suchen hat), wobei da auch irgendwas 192.168.x.y (y vermutlich 1) stehen sollte und das x mit deinem gemerkten uebereinstimmt. Praege dir diese gesamte Adresse ein, du brauchst sie noch! Fasse die Einstellung jedenfalls nicht an, sondern gucke, fuer welchen Bereich DHCP aktiviert ist. In meinem Fall ist (eher war) es fuer den gesamten Adressraum von 192.168.1.2 bis 192.168.1.255 aktiviert. Sofern du nicht 253 Geraete hast, ist das aber nicht sinnvoll. Begrenze den Adressraum, beispielsweise auf 192.168.x.2 bis 192.168.x.42.
    So, damit hast du dir in dem Falle erstmal ein paar Adressen freigeschaufelt. Back to Windows. In den hoffentlich noch geoeffneten Adaptereinstellungen suchst du dir den Adapter wieder raus, klickst diesmal auf Eigenschaften. Scroll unten runter, bis du Internet Protokoll Version 4 findest. Doppelklick drauf (nicht auf das Haekchen, du willst es nicht deaktivieren) und stelle folgendes ein: Zuerst manuelle IP-Vergabe ( Folgende IP-Adresse verwenden ), dann die IP auf irgendein 192.168.x.z festlegen, wobei z ausserhalb des DHCP-Bereichs liegt (0 und 255 darf es auch nicht sein, das haette spezielle Bedeutung). Wenn der DHCP-Bereich also beispielsweise von 2-42 geht, kannst du z zwischen 43 und 254 frei waehlen. Als Subnetz-Maske duerfte Windows 255.255.255.0 automatisch ergaenzen. Das Gateway musst du auf die Adresse vom Router setzen, also das, was du dir merken solltest. Als DNS-Server traegst du dieselbe Adresse ein.
    Damit waere der erste Schritt getan. Im Programm bindest du fortan gegen die festgelegte IP-Adresse (oder gegen sowas wie IPv4.Any).

    Als zweites solltest du in der Windows-Firewall den Port freigeben. Ich sehe du willst 13000 verwenden, also nehmen wir den als Beispiel. In der Windows-Firewall einfach unter den Eingehenden Regeln eine Port-Freigabe-Regel fuer TCP erstellen mit Port = 13000. Ich kann dir nicht genau sagen, wie das bei dir aussieht, weil ich nicht weiss, ob die FW-Config von Windows Server anders als die von den "normalen" Windows-Clients aussieht. Jedenfalls muesste die Regel dann noch aktiviert werden und alle Verbindungen zulassen.

    So, fasst geschafft. Jetzt noch einmal zum Router. Unter den Erweiterten Einstellungen nach Portzuordnungen suchen. Dort eine neue erstellen. Im Falle eines Speedports waeren die Parameter Benutzerdefiniert/TCP, Remote-Host freigelassen, Remote-Portnummernbereich auf 1300, Lokaler Host auf die festgelegte IP deines Computers (also z.B. 192.168.1.43) und der lokale Port als 13000. Status sollte selbstredend aktiviert sein.

    So, wenn jetzt also alles gut geht, solltest du deinen Server gegen deine eigene IP des Rechners hinterm Router binden und den Client gegen die IP von WasistmeineIP oder wie das Ding heisst.

    Also nochmal ein Example-Setup:
    Router: 192.168.1.1
    DHCP-Bereich: 192.168.1.2-192.168.1.42

    IP des Rechners: 192.168.1.43
    Gateway/DNS: Wie Router, also 192.168.1.1

    Firewall: 13000 eingehend von ueberall zulassen

    Router: Port 13000 von draussen nach 13000 drinnen durchschleusen (TCP)

    Server: Gegen 192.168.1.43/13000 binden.
    Client: Auf 1.2.3.4/13000 (WasIstMeineIP) connecten.

    Trouble-Shooting: Je nach Vertrag kann es sein, dass du Verbindungen von aussen gar nicht reinbekommst oder das erst vom ISP aktivieren lassen musst.
    Ausserdem wechselt deine IP bei jedem Router-Neustart (dass du ne statische hast ist unwahrscheinlich). Also musst du nach jedem Neustart deinem Kumpel die IP neu sagen. Oder irgendeinen DynDNS-Service in Anspruch nehmen.

    Ach ja: Netzwerksachen sind heikel, offene Ports noch mehr. Ich uebernehme keinerlei Gewaehrleistung, wenn was nicht mehr geht oder sich was auf deinem Rechner einnistet.

    So, hoffentlich hilft dir die Textwand etwas.

    0
  • M

    Danke erst mal für die Antwort!
    Ich habe sie noch nicht ausprobiert, weil sie ja - wie Du gesagt hast - nicht so sicher ist.
    Gibt es vielleicht eine sichere(re) Technik?
    Mit Kennwortschutz oder so? Oder vielleicht mit einem SslStream?
    http://msdn.microsoft.com/de-de/library/system.net.security.sslstream(v=vs.110).aspx

    0
  • J

    "Unsicher" bezog sich darauf, dass du dir mit nem von aussen erreichbaren offenen Port ne Luecke ins System reisst. Weniger der offene Port selbst ist das Problem, sondern der Dienst, der ihn verwendet; in dem Falle also dein Programm. Und das voellig unabhaengig von einem SslStream oder nicht.

    Je nach dem, wie gut oder schlecht das Ding dahinter ist, kann es ein Einfallstor sein oder eben nicht. Aber lass dir gesagt sein, es ist nicht einfach, sowas absolut sicher zu programmieren. Praktisch ueberall musst du die Validitaet der Daten verifzieren, um sicherzugehen, dass dein gegenueber nix anstellen kann. Schoenes Beispiel: Heartbleed. Wer mit 256 Bytes auf "Send me 256 Bytes of 'Blah'" antwortet, der schickt auch mal Daten uebers Netz, die da nicht raus sollen.
    Ebenso kannst du Angreifern ein Einfallstor bieten, wenn du nicht aufpasst. In .NET mag das durch die tausend Range-Checks und weiss der Geier was schwieriger sein, moeglich ist es aber trotzdem.

    Es sei gesagt, dass Port 13000 wohl eher nicht zu den Standard-Angriffsports gehoert und dass man schon recht gezielt angreifen muesste, um da wirklich was einzuschleusen. Service zum Absturz bringen duerfte noch eher gehen, aber naja.
    Was ich damit sagen will: Es ist moeglich, dass dich jemand angreift, wenn auch recht unwahrscheinlich. Mit dem letzten Satz im vorherigen Post wollte ich mich nur gegen Konsequenzen absichern, sollte tatsaechlich mal etwas passieren, auch wenn die Chance gering ist (sofern dein Freund dich nicht bewusst uebers Ohr hauen will :p ).

    EDIT: Mir faellt gerade noch ein: Du koenntest auch irgendeinen VPN-Tunneling-Srevice wie Hamachi nutzen. Das waere zumindest etwas sicherer, als sich routerseitig der ganzen Welt zu oeffnen

    0
  • M

    Danke, ich werde es mir mal überlegen.

    0
  • M

    Noch eine Frage: Ich könnte die Daten mit einem SslStream verschlüsseln, damit sie nicht jeder lesen kann, oder?

    0

  • Jonas OSDever schrieb:

    Weniger der offene Port selbst ist das Problem, sondern der Dienst, der ihn verwendet; in dem Falle also dein Programm. Und das voellig unabhaengig von einem SslStream oder nicht.

    Kommt dranf an ob man Client-Zertifikate verwendet.

    0
  • M

    Laut folgender Internetseite braucht man für einen SSL-Stream nicht unbedingt ein Client-Zertifikat: http://support.microsoft.com/kb/907274/de
    Dort steht:
    Some of the misconceptions that we see on a regular basis are:

    • Client certificates are needed to make SSL work properly.

    ...

    0
  • G

    Ohne Client-Zertifikat kann man allerdings als Server nicht sagen ob man da verschlüsselt mit einem echten Nutzer spricht - oder ob man verschlüsselt mit einem Angreifer spricht.
    Zumindest sofern man da nicht noch andere Maßnahmen trifft 😉

    0
  • M

    Ich weiß, aber man könnte doch dann im SSL-Stream auf eine bestimmte Antwort warten z.B. ein Kennwort, oder?

    0
Anmelden zum Antworten