Gelöst
Packet Filtered -- telekom.de und manche andere Seiten nicht erreichbar
vor 7 Jahren
Liebe Telekom-Community,
ich habe seit ein paar Tagen ein seltsames Problem mit meinem Internetzugang. Die Telekom-Hotline und der technische Support konnten mir nicht weiterhelfen. Daher versuche ich es einmal hier.
Problembeschreibung
Zahlreiche Internetseiten sind für mich nicht mehr erreichbar, darunter auch telekom.de. Rufe ich die Webseite mit Firefox auf, erhalte ich nur eine weiße Seite und ein Warte-Symbol, sonst passiert nichts. Andere Seiten, wie zum Beispiel tagesschau.de funktionieren jedoch hingegen einwandfrei. Witziger weise ist es mir daher nur möglich mittels des Tor-Browsers auf dieses Forum zuzugreifen. Das ganze begann vor etwa einer Woche, bis dahin funktionierte alles einwandfrei. Ich habe an meiner Konfiguration in der Zwischenzeit nichts geändert.
Ein Ping auf die Telekom-Seite ergibt folgendes:
root@gateway:~# ping www.telekom.de PING www.telekom.de (46.29.100.76) 56(84) bytes of data. From 87.190.235.69 (87.190.235.69) icmp_seq=1 Packet filtered From 87.190.235.69 (87.190.235.69) icmp_seq=5 Packet filtered From 87.190.235.69 (87.190.235.69) icmp_seq=7 Packet filtered ^C --- www.telekom.de ping statistics --- 7 packets transmitted, 0 received, +3 errors, 100% packet loss, time 6082ms
Man beachte die hohe Verlustrate und dass eine andere IP als die angepingte antwortet. Ein Ping auf die Tagesschau-Seite funktioniert hingegen wie gewünscht:
root@gateway:~# ping www.tagesschau.de PING e8178.e6.akamaiedge.net (23.51.114.159) 56(84) bytes of data. 64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=1 ttl=61 time=3.94 ms 64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=2 ttl=61 time=3.95 ms 64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=3 ttl=61 time=4.14 ms 64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=4 ttl=61 time=3.93 ms 64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=5 ttl=61 time=3.92 ms ^C --- e8178.e6.akamaiedge.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 3.924/3.979/4.145/0.115 ms
Konfiguration
Ich habe einen Glasfaser-Anschluss und einen „ DeutschlandLAN IP“-Vertrag. Um mich mit dem Internet zu verbinden, benutze ich einen als Router konfigurierten PC unter Debian GNU/Linux. Das Glasfasermodem ist direkt mit der Netzwerkkarte eth0 verbunden. Ich wähle mich direkt über PPPoE ein. Hier eine übersicht über die relevanten Abschnitte der Konfigurationsdateien.
/etc/network/interfaces:
auto eth0 iface eth0 inet manual auto eth0.7 iface eth0.7 inet manual auto ppp0 iface ppp0 inet ppp provider telekom post-up echo "1" > /proc/sys/net/ipv4/ip_forward post-up iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE pre-down iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE pre-down echo "0" > /proc/sys/net/ipv4/ip_forward
/etc/ppp/peers/telekom:
plugin rp-pppoe.so eth0.7 noipdefault defaultroute usepeerdns persist user "ZENSIERT@t-online.de" noauth noaccomp
Der Verbindungsaufbau scheint auch reibungsfrei zu funktionieren. Der entsprechende Abschnitt aus /var/log/syslog:
May 26 15:01:12 gateway pppd[1860]: PPP session is 83 May 26 15:01:12 gateway pppd[1860]: Connected to dc:38:e1:17:10:c4 via interface eth0.7 May 26 15:01:12 gateway pppd[1860]: Using interface ppp0 May 26 15:01:12 gateway pppd[1860]: Connect: ppp0 <--> eth0.7 May 26 15:01:12 gateway pppd[1860]: Remote message: SRU=100000#SRD=200000# May 26 15:01:12 gateway pppd[1860]: PAP authentication succeeded May 26 15:01:12 gateway pppd[1860]: peer from calling number DC:38:E1:17:10:C4 authorized May 26 15:01:12 gateway pppd[1860]: local IP address 80.ZEN.SIE.RT May 26 15:01:12 gateway pppd[1860]: remote IP address 62.155.241.158 May 26 15:01:12 gateway pppd[1860]: primary DNS address 217.0.43.33 May 26 15:01:12 gateway pppd[1860]: secondary DNS address 217.0.43.17
Default route und DNS-Server werden auch korrekt eingetragen:
root@gateway:~# route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 62.155.241.158 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 root@gateway:~# cat /etc/resolv.conf nameserver 217.0.43.33 nameserver 217.0.43.17 root@gateway:~#
Meine Diagnose und der technische Support
Vor ein paar Wochen erhielt ich einen Brief, dass mein Anschluss „umgestellt“ werde. Für mich würde sich nichts ändern, lediglich das Internet sei für ein paar Stunden nicht verfügbar. Seit diesem Umstellungstermin besteht das Problem. An meiner Konfiguration habe ich nichts geändert. Da einige Seiten funktionieren und ich dank Tor auch im Internet surfen kann, liegt das Problem scheinbar im Netz der Telekom und nicht bei mir. Ich habe bereits eine andere Netzwerkkarte ausprobiert, allerdings auch ohne Erfolg.
Ich habe eine Störungsmeldung aufgegeben, letzten Endes wurde mir gesagt, dass auf Seiten der Telekom keine Störung vorliege und ich mich an den kostenpflichtigen Support wenden solle. Die Störungsmeldung wurde daraufhin einfach geschlossen. Ich habe mich auch an den kostenpflichtigen technischen Support gewendet, dort wurde mir dann lediglich gesagt, dass Linux nicht unterstützt werde. Aber wie gesagt, so weit wie ich das sehe liegt das Problem ohnehin nicht auf meiner Seite. Bevor ich mich nun noch mal eine Stunde von Hotline zu Hotline hangele, stelle ich meine Frage mit detaillierten Informationen nun einfach hier. Ich wäre froh, wenn mir jemand helfen könnte.
1275
8
Das könnte Ihnen auch weiterhelfen
vor 5 Jahren
3771
2
4
vor 7 Jahren
@Dr. Arno Nym
Ist mir bis jetzt noch gar nicht aufgefallen, aber beim ping habe ich das identische Problem:
Im Browser, hier chrome, kann ich aber die telekom.de Seite ganz normal öffnen.
6
Antwort
von
vor 7 Jahren
@Dr. Arno Nym
Das eine Seite auf ICMP Pakete nicht antwortet ist doch völlig normal und bedeutet für sich alleine genommen gar nichts.
Solange die Seite auf die eigentlichen Protokolle antwortet ist alle normal.
Das eine andere IP als die gepingte antwortet ist auch nichts ungewöhnliches.
www.telekom.de ist mit Sicherheit ein Loadbalancer und nicht ein Rechner mit einer IP.
Je nach eingesetztem Verfahren kann da auch ein anderer Server antworten
Antwort
von
vor 7 Jahren
Hallo liebe Community,
vielen Dank für Eure Hilfe. Ich habe tatsächlich vom gateway selbst aus immer nur gepingt und gedacht, dass das immer funktionieren müsste. @Stefan: vielen Dank. Ist mir schon fast peinlich, darauf hätte ich auch selbst kommen müssen. Auf Grund Deines Hinweises habe ich einfach mal lynx auf dem gateway installiert und konnte damit die Telekom-Seite auch besuchen.
Das Problem lag letzten endes an den MTU-Einstellungen. Und zwar an denen der Clients im meinem Netzwerk, und nicht an der zum Modem! Egal was ich als MTU an der Verbindung zum Modem oder beim pppd angegeben habe, das änderte nichts. Aber sobald ich die MTU der Clients in meinem Netzwerk auf 1492 herabgesetzt habe, funktionierte wieder alles.
Ist dies ein Bug? Ich dachte immer, dass das ip_forwarding und das masquerading zu große Pakete aus dem internen Netzwerk "aufgestückelt" ans Modem durchreichen würde.
Antwort
von
vor 7 Jahren
@Dr. Arno Nym
Da macht dein Router etwas noch nicht korrekt.
Für IPv4 ist bei meinen clients die MTU auf 1500 gesetzt.
Für IPv6 hängt es vom Router ab, ein Speedport setzt die MTU auf 1492, eine Digitalisierungsbox auf 1500.
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 7 Jahren
Hallo liebe Community,
vielen Dank für Eure Hilfe. Ich habe tatsächlich vom gateway selbst aus immer nur gepingt und gedacht, dass das immer funktionieren müsste. @Stefan: vielen Dank. Ist mir schon fast peinlich, darauf hätte ich auch selbst kommen müssen. Auf Grund Deines Hinweises habe ich einfach mal lynx auf dem gateway installiert und konnte damit die Telekom-Seite auch besuchen.
Das Problem lag letzten endes an den MTU-Einstellungen. Und zwar an denen der Clients im meinem Netzwerk, und nicht an der zum Modem! Egal was ich als MTU an der Verbindung zum Modem oder beim pppd angegeben habe, das änderte nichts. Aber sobald ich die MTU der Clients in meinem Netzwerk auf 1492 herabgesetzt habe, funktionierte wieder alles.
Ist dies ein Bug? Ich dachte immer, dass das ip_forwarding und das masquerading zu große Pakete aus dem internen Netzwerk "aufgestückelt" ans Modem durchreichen würde.
0
Uneingeloggter Nutzer
Frage
von