Beiträge von BigBlue007

    route print - Ergebnis s.u.. Alles mit 9. am Anfang ist das Intranet; diese Einträge gibts ergo nur, wenn ich mit dem Dialer gerade online bin, so wie jetzt im Moment. Ich nehme an, die Challenge besteht jetzt darin, die Defaultroute manuell auf den Dialer umzubiegen. Wie genau wäre der Befehl hierfür?



    Melone:


    Ja, es ist definitiv IP-Sec.


    In Deinem Posting scheint was zu fehlen. Wie sehe ich die aktuelle Routingtabelle? Wie setze ich eine Route auf das Tunnelinterface, und welche IP wäre das (wo sehe ich die)?



    Blarney:


    Ich bin sicher, dass alles, was nicht zum IBM-Intranet gehört, offen ist. Sicheres Anzeichen: Wenn ich auf http://www.ip-adress.com gehe, sehe ich die IP-Adresse des HotSpots. Würde alles über den VPN-Tunnel gehen, müsste ich eine IP-Adresse aus dem Adressbereich des IBM Global Networks sehen, nämlich die, die mein VPN-Client zugewiesen bekommen hat.


    Screenshot von netstat -a:



    Aktive Verbindungen


    Proto Lokale Adresse Remoteadresse Status
    TCP T60:epmap T60:0 ABHÖREN
    TCP T60:microsoft-ds T60:0 ABHÖREN
    TCP T60:990 T60:0 ABHÖREN
    TCP T60:5800 T60:0 ABHÖREN
    TCP T60:5900 T60:0 ABHÖREN
    TCP T60:6060 T60:0 ABHÖREN
    TCP T60:1029 T60:0 ABHÖREN
    TCP T60:1045 T60:0 ABHÖREN
    TCP T60:1065 T60:0 ABHÖREN
    TCP T60:1067 localhost:1068 HERGESTELLT
    TCP T60:1068 localhost:1067 HERGESTELLT
    TCP T60:1083 localhost:1084 HERGESTELLT
    TCP T60:1084 localhost:1083 HERGESTELLT
    TCP T60:5679 T60:0 ABHÖREN
    TCP T60:7438 T60:0 ABHÖREN
    TCP T60:netbios-ssn T60:0 ABHÖREN
    TCP T60:1099 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1103 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1104 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1105 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1106 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1107 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1108 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:kpop 147.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1122 104.235.14.72.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1131 104.129.85.209.in-addr.arpa:http FIN_WARTEN_1
    TCP T60:1147 ug-in-f93.google.com:http HERGESTELLT
    UDP T60:microsoft-ds *:*
    UDP T60:isakmp *:*
    UDP T60:1031 *:*
    UDP T60:1048 *:*
    UDP T60:1096 *:*
    UDP T60:1097 *:*
    UDP T60:1098 *:*
    UDP T60:4500 *:*
    UDP T60:ntp *:*
    UDP T60:1032 *:*
    UDP T60:1900 *:*
    UDP T60:ntp *:*
    UDP T60:netbios-ns *:*
    UDP T60:netbios-dgm *:*
    UDP T60:1900 *:*

    Normalerweise kenne ich mich mit so Zeugs ja selbst ganz gut aus, aber hier brauche ich mal fachkundigeren Rat, als ich mir selbst geben kann... ;)


    Also, gegeben sei ein unverschlüsselter Hotspot im Hotel, am Flughafen, wo auch immer. Gegeben sei weiterhin ein vorhandener VPN-Dialer (in diesem Falle von AT&T), der dazu verwendet wird, eine getunnelte Verbindung zum Firmen-Intranet herzustellen. Diesen Dialer benötige ich grundsätzlich immer, also auch, wenn ich von zu Hause aus arbeite, hat also mit offenem oder sicheren WLAN erstmal nichts zu tun.


    In einem offenen WLAN hat die VPN-Verbindung nun zusätztlich den Vorteil, dass jemand, der die offene WLAN-Verbindung belauscht, nichts mit dem mitgeschnittenen Traffic anfangen kann.


    Nun zur eigentlichen Aufgabenstellung: Wenn die VPN-Verbindung aktiv ist, dann werden ausschließlich Verbindungen zum Firmen-Intranet über den Tunnel geleitet, d.h. wenn ich z.B. im Browser eine Intranetseite anwähle, dann läuft diese Verbindung natürlich über den Tunnel, klicke ich dagegen auf Google, dann geht dies quasi "am Tunnel vorbei".


    Was ich nun gerne hätte, ist, dass der GESAMTE Traffic meines Notebooks ausschließlich über den VPN-Tunnel geht. Von der Sache her ist das kein Problem, da unser Intranet wiederum natürlich auch InTERnetverbindungen, POP3 usw. zulässt. Im VPN-Dialer selbst gibt es auch eine Option, ob die VPN-Verbindung nur für Intranet- oder auch Internetverbindungen verfügbar sein soll - habe natürlich Letzteres ausgewählt. Irgendwie muss ich jetzt aber Windows noch beibringen, dass es sämtlichen Netzwerktraffic über diesen Tunnel routen soll.


    Die in Windows eingebaute VPN-Funktionalität nützt mir IMHO nichts, da ich ja wie gesagt diesen AT&T-Dialer nutze; da komme ich auch nicht drumherum.


    Ich will also letztlich erreichen, dass ich, wenn ich unterwegs bin, die sichere VPN-Verbindung zum Firmennetzwerk auch für meine privat anzusurfenden Seiten nutzen kann und nicht jeder Depp, der nebenan im Zimmer sitzt, mein GMX-Passwort im Klartext mitschneiden kann.


    Kann da jemand helfen?

    Zitat

    Original geschrieben von Syd
    TOM TOM5 läuft auf dem qtek8310 und 8500 fehlerfrei.
    Warum sollte TT6 nicht auf dem MTeor laufen!


    Weil TT6 derzeit nur in der Version für Pocket PC bzw. Windows Mobile, aber noch nicht für Windows Mobile SMARTPHONE vorliegt. Über ein Tool, welches auf einem MS-SmartPhone die Stifteingabe emuliert, soll es wohl trotzdem laufen, dürfte aber von der Bedienung her eine Krücke sein.

    Bratwursthorst: Ja, hast Du. Denn im Normfallfall weiß ich ja nicht, ob und welche Daten der Provider speichert. Es kann ja auch sein, dass der Provider sich bereits gesetzeskonform verhält und die Daten nicht speichert.


    Der Widerspruch gegen die Speicherung ist dann natürlich erst der zweite Schritt, der erfolgen muss, falls der Provider sagt, er speichert.


    Falls er gar nicht erst antwortet, oder den Widerspruch nicht positiv bestätigt, würde ich (aber das ist jetzt nur meine persönliche Meinung und die Art und Weise, wie ich vorgehen würde und werde) mit finaler Fristsetzung mit der sofortigen Kündigung des Vertrags aus wichtigem Grund (gibts in allen AGBs einen Punkt zu) kündigen und mich dabei auf den Verstoß des Anbieters gegen §§ 96 und 97 TKG berufen.

    Übrigens, noch eine Anmerkung (ich hatte diesbzgl. die Überschrift noch geändert, hatte allerdings nur Auswirkung auf die Posting- und nicht auf die Threadüberschrift): Der BGH hat sich in seiner Entscheidung mit der eigentlichen Frage der Datenspeicherung gar nicht befasst, sondern die Beschwerde der Telekom gegen das Urteil der Vorinstanz aus formalen Gründen abgewiesen. Die Telekom hätte für die Zulassung der Beschwerde eine gewisse Mindestschadenhöhe nachweisen müssen, was sie nicht konnte.


    Dies ändert allerdings nichts daran, dass durch die Abweisung der Beschwerde der Spruch der Vorinstanz - immerhin ein Landesgericht (Darmstadt) endgültig rechtskräftig ist und sich jedermann auf das Urteil berufen kann.


    Theoretisch besteht nun immer noch die Möglichkeit, dass in einem anderen Fall die eigentliche Frage der Datenspeicherung vom BGH geklärt wird. Nachdem aber nun schon die große Telekom an einer Privatperson gescheitert ist, werden sich andere das sicher 2x überlegen, durch alle Instanzen zu gehen.


    edit: 1 Minute zu spät... ;)

    Hier die Textvorlage für ein Schreiben an den Provider (von der oben verlinkten Seite entnommen und minimal modifiziert):


    Sehr geehrte Damen und Herren,


    hiermit verlange ich Auskunft darüber, welche Daten (dynamisch zugewiesene IP-Adresse, übertragenes Datenvolumen usw.) im Zusammenhang mit der Nutzung meines Flatrate-Tarifs in Ihrem Haus für welche Zeiträume gespeichert und an welche externen Unternehmen weitergegeben werden. Ich weise darauf hin, dass Sie nach § 34 Bundesdatenschutzgesetz zu dieser Auskunfterteilung verpflichtet sind.


    Ich darf Sie bitten, die verlangte Auskunft bis spätestens xx.xx.xxxx zu erteilen. Wird die Auskunft nicht fristgerecht erteilt, werde ich die zuständige Aufsichtsbehörde einschalten.


    (Ich habe an dieser Stelle noch ein und den Vertrag gemäß Ihren AGBs Punkt 13.3 außerordentlich und mit sofortiger Wirkung kündigen eingefügt. ;) ).



    Mit freundlichen Grüßen
    xxx

    Klick!


    Ein wie ich finde wichtiger Schritt im Sinne des Datenschutzes in Deutschland. Der Spruch des BGH gilt zwar für sich genommen zunächst nur für das Vertragsverhältnis zwischen dem Kläger und T-Online. Allerdings kann natürlich nun jeder, der eine Flatrate hat, seinen Provider unter Verweis auf dieses Urteil dazu auffordern, ihm zuzusichern, dass seine IP-Adresse nach Ende jeder Verbindung gelöscht wird.


    Die Tragweite dieses Urteils ist vielfältig. Klagen der MI gegen Filesharer z.B. dürften in Zukunft hierzulande nahezu unmöglich sein. Nicht, dass ich illegale Filesharer in Schutz nehmen will, aber die größeren Gauner sitzen m.E. dann doch auf der anderen Seite... :D


    Andererseits werden Dinge wie etwa diese FONERO-Geschichte für die, die da mitmachen wollen, in Zukunft mit deutlich geringeren Risiken möglich sein.


    Dann werde ich morgen gleich mal ein Schreiben an Congster fertig machen... ;)