• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Unitymedia Der Netzwerk-Intensivtest

Diskutiere Der Netzwerk-Intensivtest im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon; Quelle: http://www.heise.de/netze/artikel/Netalyzr-1045926.html Mein Testergebnis...
  • Der Netzwerk-Intensivtest Beitrag #1
DeaD_EyE

DeaD_EyE

Beiträge
118
Punkte Reaktionen
0
Blockiert der Provider Ports oder zwingt er den Datenverkehr durch einen Proxy? Werden Web-Inhalte unterwegs irgendwo gefiltert und kommen Viren durch? Oder werden DNS-Anfragen manipuliert? Funktioniert IPv6 genauso gut wie IPv4? Stimmen Latenz und Bandbreite?

Das Online-Tool Netalyzr untersucht detailliert die Verbindung Ihres Rechners zum Internet. Es gibt so nicht nur Auskunft über die Qualität Ihres Internet-Zugang, sondern hilft auch Fehler zu finden. Die Ergebnisse präsentiert Netalyzr in einem neuen Fenster mit detaillierten Erklärungen zu den einzelnen Test-Schritten und den Ergebnissen.

Quelle: http://www.heise.de/netze/artikel/Netalyzr-1045926.html

Mein Testergebnis: http://netalyzr.icsi.berkeley.edu/restore/id=43ca208a-15210-7b1ab7ac-4e31-40e5-bedb
 
  • Der Netzwerk-Intensivtest Beitrag #2
eth19?

Ich soll meinen DNS Server überprüfen. Google hat keine IPv6 Adressen mehr und angeblich macht er auch kein DNSSEC. Das hat aber in der Vergangenheit schon funktioniert...
 
  • Der Netzwerk-Intensivtest Beitrag #3
ALso mein DNS macht auch kein DNSSEC. Steht ja in der Auswertung. Immerhin kann er IPv6 Adressen auswerten, was mir aber nichts bringt oder bietet Unitymedia für Privatkunden mittlerweile IPv6 an? Angeblich stellt die Telekom bis zum Dezember um.
 
  • Der Netzwerk-Intensivtest Beitrag #4
Vergiss das Tool.
Die Idee ist gut, die Umsetzung aber sehr schlecht.

ALso mein DNS macht auch kein DNSSEC.
Sicher kann UM auch DNSSEC.

Nimm ein Unix/Linux und probiere mal von einem UM Anschluss:
dig +dnssec www.whitehouse.gov @80.69.100.206

Die DNS-Anfrage ist eine DNSSEC-Anfrage, gerichtet an den UM DNS Server 80.69.100.206 (als Bsp., kannst auch jeden anderen UM DNS Server einsetzen).

UM zeigt die verwendeten DNSSEC-Keys.
Was UM hier nicht macht, ist das automatische Ueberpruefen ob das zurueckgegebene Ergebnis das fuer den angefragten DNS-Eintrag das gerade aktuell Gültige ist.
Das musst Du dann selbst machen.

So reagiert ein auch auf die Gültigkeit von DNSSEC-Eintraegen pruefender DNS Server:
Alles was DNSSEC aktiviert hat aber deren DNSSEC-Antworten ungültig sind wird mit "Nicht existent" (NXDOMAIN) zurueckgegeben.
Also genau dieselbe Antwort als waere der DNS-Eintrag gar nicht vorhanden.

Das macht es hier Sinn wie UM erstmal vorsichtiger zu reagieren oder wuerdest Du gerne gar keine DNS-Aufloesung der betreffenden DNS-Eintraege haben nur weil der (nicht im UM Einfluss liegende) DNS-Admin der betreffenden Domain Fehler im DNSSEC eingebaut hat oder die notwendigen DNSSEC-Keys abgelaufen sind?

Sicher ist DNSSEC durchaus sinnvoll, es bringt aber einige zusaetzliche Fehlerquellen mit.
Immerhin kann er IPv6 Adressen auswerten, was mir aber nichts bringt oder bietet Unitymedia für Privatkunden mittlerweile IPv6 an?
Wieso bringt das Aufloesen von IPv6-Adressen nichts?
Hast Du ein Windows Vista oder ein Windows 7?

Diese Betriebssysteme senden falls es keine oeffentlichen IPv6-Adressen hat IPv6 ueber den in der Werkseinstellung aktivierten teredo-Tunnel.

Damit kannst Du bei Dir vor Ort auf diesen Betriebssystemen auch bereits jetzt schon IPv6 nutzen.
 
  • Der Netzwerk-Intensivtest Beitrag #5
Geringfügige Abweichungen
Bestimmte TCP-Protokolle werden im abgehenden Datenverkehr gesperrt.
Nicht alle DNS Anfragetypen wurden korrekt bearbeitet

Also alles so, wie es sein soll. Bei den gesperrten TCP-Protokollen handelt es sich um NetBIOS/SMB und die nicht korrekt bearbeiteten Anfragetypen sind halt die Einschränkungen von dnsmasq:

Der Resolver 192.168.1.1 unterstützt die folgenden Anfragetypen nicht:
Mittelgroße (~1300B) TXT-Einträge
Große (~3000B) TXT-Einträge
Er validiert DNSSEC nicht. Er lässt NXDOMAIN-Fehlermeldungen unverändert.
 
  • Der Netzwerk-Intensivtest Beitrag #6
Ich hab jetzt mal so ein bisschen ausprobiert.

Hier mal ein Testlink: (der Download geht bei mir und sollte bei anderen Kunden auch gehen.)


Dabei werden IPv6-Pakete mit dem UDP über IPv4 gekapselt. Dies geschieht mit Hilfe sogenannter Teredo-Server.

Wenn ich mir jetzt den Log ansehe:
2001:0:5ef5:79fd:186f:192:92a5:4f13 - - [25/Jun/2011:18:29:04 +0200] "GET /css/maps/de_glacier.bsp.bz2 HTTP/1.1" 200 5723020 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0"
#### Hier einmal über die IPv4 abgerufen ###
109.90.176.236 - - [25/Jun/2011:18:32:23 +0200] "GET /css/maps/de_glacier.bsp.bz2 HTTP/1.1" 200 6032720 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0"

Ein Whois auf die IPv6:
Code:
 whois 2001:0:5ef5:79fd:186f:192:92a5:4f13
Abfrage des IPv4-Endpunkts 109.90.176.236 einer Teredo-IPv6-Adresse.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '109.90.0.0 - 109.90.255.255'
inetnum: 109.90.0.0 - 109.90.255.255
netname: UNITYMEDIA-POOL-NET
....
Also kann man jetzt schon ipv6 Adressen erreichen, auch wenn der Traffic bis jetzt noch von Unitymedia getunnelt wird.

Meine Feundin in Ägypten kann auch auf den Server zugreifen:
Code:
whois 2001:0:5ef5:79fb:c81:d89f:d614:5b93
Abfrage des IPv4-Endpunkts 41.235.164.108 einer Teredo-IPv6-Adresse.
% This is the AfriNIC Whois server.
% Note: this output has been filtered.
% Information related to '41.235.0.0 - 41.235.255.255'
inetnum: 41.235.0.0 - 41.235.255.255
netname: Giza-Zone-DSL
descr: Giza-Zone-DSL
descr: TE Data
country: EG
admin-c: TDCR1-AFRINIC
tech-c: TDCR2-AFRINIC
....

Also gehe ich man von aus, dass man schon weltweit auf IPv6-Adressen zugreifen kann, auch wenn der Traffic zur Zeit nur über IPv4 zum Provider hin getunnelt wird.

DNSSEC geht anscheinend auch:
Code:
dig +dnssec www.whitehouse.gov @80.69.100.206
; <<>> DiG 9.7.3 <<>> +dnssec www.whitehouse.gov @80.69.100.206
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 391
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1220
;; QUESTION SECTION:
;www.whitehouse.gov. IN A
;; ANSWER SECTION:
www.whitehouse.gov. 3062 IN CNAME www.whitehouse.gov.edgesuite.net.
www.whitehouse.gov. 3062 IN RRSIG CNAME 7 3 3600 20110627230826 20110624220826 59522 whitehouse.gov. sRauBj31EPYohNRSM8P1G5xR1qOnRHZLOTnrO7HdO3XNmkwiS7tq3Tr/ 4qUeOR2asivz87HwBqEQTvXWWlG941ARWct7cyTq1LzXltqXgGgxOPxT pswjqqhapmk1HtJVfgZekj47tiMZj5QBjqYrb8oxhhkVXQ+iJrKErbi3 uPY=
www.whitehouse.gov.edgesuite.net. 759 IN CNAME www.eop-edge-lb.akadns.net.
www.eop-edge-lb.akadns.net. 75 IN CNAME a1128.h.akamai.net.
a1128.h.akamai.net. 20 IN A 92.122.212.35
a1128.h.akamai.net. 20 IN A 92.122.212.18
;; Query time: 15 msec
;; SERVER: 80.69.100.206#53(80.69.100.206)
;; WHEN: Sat Jun 25 18:45:51 2011
;; MSG SIZE rcvd: 365

Ich denke mal, dass mein Uralt-Router DNSSEC nicht unterstützt.

Quelle: http://www.heise.de/netze/artikel/DNSsec-Router-Inkompatibilitaet-903752.html
Als Nebenprodukt dieser Tests wurde aber festgestellt, dass viele DSL- und WLAN-Router nicht mit DNSsec-Antworten umgehen können. DNSsec ist nicht nur zur Absicherung zwischen Servern gedacht, sondern auch zur Sicherung von Applikationen. Ein Browser zum Beispiel soll so die Echtheit von DNS-Antworten überprüfen können, ist aber darauf angewiesen, dass der vorgeschaltete Router die DNS-Pakete unangetastet durchlässt.

EDIT: Anscheinend sind die beiden Antworten gleich (direkter dns und router)
Code:
diff <(dig +dnssec www.whitehouse.gov @192.168.0.1) <(dig +dnssec www.whitehouse.gov @80.69.100.230)
2c2
< ; <<>> DiG 9.7.3 <<>> +dnssec www.whitehouse.gov @192.168.0.1
---
> ; <<>> DiG 9.7.3 <<>> +dnssec www.whitehouse.gov @80.69.100.230
5c5
< ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45697
---
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55466
18d17
< a1128.h.akamai.net. 6 IN A 92.122.212.35
19a19
> a1128.h.akamai.net. 6 IN A 92.122.212.35
21,22c21,22
< ;; Query time: 9 msec
< ;; SERVER: 192.168.0.1#53(192.168.0.1)
---
> ;; Query time: 11 msec
> ;; SERVER: 80.69.100.230#53(80.69.100.230)

Lediglich die id unterscheidet sich, was das auch immer zu bedeuten hat.
 
  • Der Netzwerk-Intensivtest Beitrag #7
NetBIOS/SMB wird direkt in der FB 6360 gefiltert. Kann man mit dem FB Editor sehen und ggf. abschalten.
 
  • Der Netzwerk-Intensivtest Beitrag #9
NetBIOS/SMB wird direkt in der FB 6360 gefiltert. Kann man mit dem FB Editor sehen und ggf. abschalten.

Eigentlich ziemlich unlogisch, da ohne zutun des Kunden keine Freigaben weiter geleitet werden oder sorgt die Box dafür, dass man direkt mit dem Internet verbunden ist (DMZ)? Naja, mir egal, ich hab die WitzBox zum Glück nicht. Unter anderem leistet sich AVM wieder ein dolles Ding.

Seht selbst: http://www.heise.de/newsticker/meldung/FSFE-wirft-AVM-GPL-Verletzung-vor-1263357.html
 
  • Der Netzwerk-Intensivtest Beitrag #10
NetBIOS/SMB wird direkt in der FB 6360 gefiltert. Kann man mit dem FB Editor sehen und ggf. abschalten.

Das ist hier nicht AVM.

Die 6360 hat ein Kabelmodem und UM wird das wie bei den anderen Kabelmodems blocken.
D.h. im LAN gehen Freigaben, im WAN nicht.
 
  • Der Netzwerk-Intensivtest Beitrag #11
Die Idee ist gut, die Umsetzung aber sehr schlecht.
Ich mag Java jetzt auch nicht besonders, aber viel mehr Möglichkeiten gibts auch nicht.
Was genau stört Dich sonst?

Sicher kann UM auch DNSSEC.
Das würde ich nicht sagen - Blos weil ich zugehörige RRs ausliefere, verstehe ich nicht unbedingt den Inhalt:
Code:
dig @80.69.100.206 www.dnssec-failed.org a
Dazu: http://www.dnssec-failed.org Zitat: "If your computer is using a DNS recursive resolver that has implemented DNSSEC validation, then you should NOT have arrived at this web page."
Aber das ist Dir ja auch bewusst, wir streiten also nur um die Formulierung "UM kann DNSSEC" :)
Alles was DNSSEC aktiviert hat aber deren DNSSEC-Antworten ungültig sind wird mit "Nicht existent" (NXDOMAIN) zurueckgegeben.
SERVFAIL. Und wenn man +cd setzt, kriegt man die Antwort trotzdem.
Das macht es hier Sinn wie UM erstmal vorsichtiger zu reagieren oder wuerdest Du gerne gar keine DNS-Aufloesung der betreffenden DNS-Eintraege haben nur weil der (nicht im UM Einfluss liegende) DNS-Admin der betreffenden Domain Fehler im DNSSEC eingebaut hat oder die notwendigen DNSSEC-Keys abgelaufen sind?
Da stimme ich Dir zu, als Provider wär ich auch vorsichtig. Sinnvoll wäre an der Stelle ein neuer Responsecode gewesen, der dem Benutzer dann mglw. Feedback anbietet.
Allerdings sind fehlerhafte DNS Configs schon vor DNSSEC weitaus geläufiger gewesen als man glaubt... wegen der Redundanz des Systems merken es viele Admins nicht. Ist mir selbst auch schon passiert.
 
  • Der Netzwerk-Intensivtest Beitrag #12
Das würde ich nicht sagen - Blos weil ich zugehörige RRs ausliefere, verstehe ich nicht unbedingt den Inhalt:
Code:
dig @80.69.100.206 www.dnssec-failed.org a
Dazu: http://www.dnssec-failed.org Zitat: "If your computer is using a DNS recursive resolver that has implemented DNSSEC validation, then you should NOT have arrived at this web page."
Aber das ist Dir ja auch bewusst, wir streiten also nur um die Formulierung "UM kann DNSSEC" :)
Es steht auch in der Antwort auf Deiner DNSSEC-Abfrage drin.
Dort geht es um DNSSEC Validation.

DNSSEC und DNSSEC Validation sind technisch etwas anders.

DNSSEC liefert die DNS-Antwort und die fuer DNSSEC zusaetzlich genutzten RRs aus, ohne Validierung.
DNSSEC Validation prueft auch noch.

DNSSEC Validation habe ich oben mit auf Gültigkeit prüfend umschrieben.
Alles was DNSSEC aktiviert hat aber deren DNSSEC-Antworten ungültig sind wird mit "Nicht existent" (NXDOMAIN) zurueckgegeben.
SERVFAIL. Und wenn man +cd setzt, kriegt man die Antwort trotzdem.
Das stimmt, es ist SERVFAIL. NXDOMAIN ist/war ein Bug in aelteren BIND-Versionen bei bestimmten DNSSEC Ressource Record-Typen.

+cd (Checking Disabled) ist genau das oben Beschriebene was UM derzeit macht: DNSSEC ohne Validierung.
 
  • Der Netzwerk-Intensivtest Beitrag #13
  • Der Netzwerk-Intensivtest Beitrag #14
NetBIOS wird wahrscheinlich geblockt. SMB nicht.
Such mal im Forum nach Portsperren.
UM blockt -auch wenn die Hotline es verneint und es erst immer nach schriftlicher Nachfrage doch eingeraeumt wird- ein paar Ports seit Jahren, u.a. RPC/DCOM (135), NetBIOS (137-139) und SMB (445).
 
  • Der Netzwerk-Intensivtest Beitrag #15
Die Idee ist gut, die Umsetzung aber sehr schlecht.
Ich mag Java jetzt auch nicht besonders, aber viel mehr Möglichkeiten gibts auch nicht.
Was genau stört Dich sonst?
Zum Einen Java.

Zum anderen werden die Messungen nur gegen Server der Berkeley University, USA durchgefuehrt.
D.h. die Buffer- und Uplink-Messungen sind hier eher fuer den Allerwertesten, weil sie nicht die fuer Europa sehr oft genutzten Verbindungen widerspiegeln.

Es sei denn jemand surft immer ausschliesslich auf Seiten, die in den USA gehostet werden. Dann kann man das Tool empfehlen.

Von Europa aus waeren fuer die meisten hier Messungen innerhalb Europas - z.B. gegen Server die am DECIX in Frankfurt, am AMSIX in Amsterdam oder am LINX in London angeschlossen sind - viel viel interessanter da an den 3 genannten Internet Exchanges die meisten der europaeischen Provider dranhaengen.

Aber so bekommt man Ergebnisse, deren Messung zwar durchaus richtig ist, aber viele der Gamer verzweifeln laesst ("mein ping ist zu hoch" etc pp.).
 
  • Der Netzwerk-Intensivtest Beitrag #16
Wieso komme ich dann auf meine Windows-Freigaben meines VServers?
Code:
netstat -an
#####
TCP 192.168.0.194:56978 46.4.130.234:445 HERGESTELLT
######


Mein Server im LAN:
Code:
root@kiste:~# nmap -p 135-445 46.4.130.234
Starting Nmap 5.00 ( http://nmap.org ) at 2011-06-27 18:10 CEST
Interesting ports on static.234.130.4.46.clients.your-server.de (46.4.130.234):
Not shown: 309 closed ports
PORT STATE SERVICE
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 3.47 seconds

Port 135 ist wegen Samba geblockt. Wird sicherlich irgendeine Einstellung sein, hat mich auch nicht sonderlich interessiert, da der Dienst normal nur über meinen Tunnel läuft.

UM filtert nichts, was über die drei Ports geht. Ich komme bei auf die Freigaben meines VServers drauf. Um nochmal sicher zu gehen, habe ich mal die Port 135,139 und 4445 auf meinen Server im LAN weitergeleitet.

Server im LAN:
Code:
root@kiste:~# nc -lp 135

Server im Internet:
Code:
echo "Port 135 ist offen" | nc 109.90.176.236 135

Meldung auf dem Server im LAN:
Code:
Port 135 ist offen

Geht auch mit Port 139 und 445. Ausgehend geht es genau so.

Bevor ihr jetzt alle gleichzeitig versucht auf die Freigaben von meinem Server im LAN oder den VServer zu kommen, ich hab ihn wieder deaktiviert. Die Portfreigaben habe ich auch wieder entfernt.

Da man durch UM eine 24er Netzmaske zugewiesen bekommt, besteht die Gefahr das Windows-Freigaben anderer Teilnehmer aus dem gleichen Netz direkt in der Netzwerkumgebung vorzufinden sind. Broadcasts werden hoffentlich von UM auch gefiltert, was dann dieses Szenario verhindern sollte. Einen ähnlichen Fall gab es mal bei mehreren DSL-Anbietern.

Was passieren kann: http://www.golem.de/0707/53628.html
 
  • Der Netzwerk-Intensivtest Beitrag #17
Du redest vom ausgehendem Traffic in Richtung Deines VServers.
Ich rede von eingehendem Traffic zu Deinem UM Anschluss hin.

D.h. falls Du ein Windows 9x oder XP hast, werden vom am UM Anschluss ohne Router direkt am Modem angeschlossenen Windows-PC Deine Freigaben im Internet nicht sichtbar.
Denn diese aelteren Windows-Systeme hatten die Eigenart, Freigaben immer an alle Netzwerk-Adapter zu binden (bei Win9x auch an den DFUe-Adapter) und keine Unterscheidung zu machen was das vom Vertrauens- und damit vom Sicherheitslevel her fuer ein Netzwerk das ist. Letzteres wurde erst ab Vista und neuer realisiert wo man definieren kann was alles in diesem oder jenem Netzwerk moeglich ist.

Kann natuerlich sein, dass UM das mittlerweile nicht mehr macht.

Von UM bekommst Du nicht automatisch eine IP, die immer die Netzmaske /24 hat.
Es gab auch schon Faelle, die von /23 und /22 berichteten.
 
  • Der Netzwerk-Intensivtest Beitrag #18
Geht auch mit Port 139 und 445. Ausgehend geht es genau so.

Ich zitiere mich selbst eigentlich nur ungern.

Vielleicht ist dir der Satz entgangen. Ich hatte den Test natürlich in beide Richtungen gemacht.
Letzteres wurde erst ab Vista und neuer realisiert wo man definieren kann was alles in diesem oder jenem Netzwerk moeglich ist.

Du meinst die Topologieerkennung.

Auf den Broadcast werde ich jetzt nicht mehr eingehen.
 
  • Der Netzwerk-Intensivtest Beitrag #19
Ich habe selbst auch gemerkt, dass in der Vergangenheit Portsperren wieder entfernt wurden. Ich begrüße das ausdrücklich. Man hat ja jetzt das Sicherheitspaket :)
 
Thema:

Der Netzwerk-Intensivtest

Der Netzwerk-Intensivtest - Ähnliche Themen

Unitymedia Erfahrungsbericht 10 Jahre Unity und Wechsel auf Connect-Box: Hallo Forum, hier ein kurzer Erfahrungsbereicht meines Wechsel zur Connect Box. Kurz eine Vorstellung als Einleitung. Ich heiße Markus, bin 43...
Oben