Seit einigen Monaten habe ich mit regelmäßigen Internetausfällen zu kämpfen, die alle Geräte in meinem lokalen Netzwerk betreffen und mich zwingen, mein Kabelmodem aus- und wieder einzuschalten. Heute habe ich festgestellt, dass ich dieses Problem – oder ein ähnliches mit denselben Symptomen – reproduzieren kann, indem ich ein Spiel mit Blizzards Battle.net installiere.
Es geht nicht nur darum, meine Bandbreite auszulasten, denn
- der Download selbst stoppt ebenfalls,
- es passiert auch, wenn die Download-Geschwindigkeit begrenzt wird,
- und es löst sich nicht automatisch, wenn der Download pausiert wird – nur ein Neustart des Modems hilft.
Um genau zu sehen, wann meine Internetverbindung ausfällt, führe ich einen einfachen ping 8.8.8.8auf einem separaten Linux-Notebook (ich verwende übrigens Arch), das mit demselben Netzwerk verbunden ist - aber ich kann trotzdem weiter pingen, selbst wenn mein Internet ausfällt! Nur wenn ich den laufendenKlingeln, und wenn ich es neu starte, bekomme ich keine Antworten mehr.
Ich bin ein wenig verblüfft über dieses Verhalten. Ich habe auch versucht, nebeneinander zu laufen ping 8.8.8.8- watch -n1 ping -c 1 8.8.8.8während der ständig laufendeKlingelnDer Prozess läuft weiter,KlingelnProzess regelmäßig neu gestartet durchbetrachtenschlägt fehl, sobald mein Internet ausfällt.
Wie ist das möglich? Es scheint, als ob "aktive Ping-Sitzungen" von meinem Ausfall nicht betroffen sind. Aber bei Ping mit ICMP auf Schicht 3 verstehe ich nicht, warum es einen Unterschied macht, ob manKlingelnLaufen, im Gegensatz zu einem Neuanfang.
Nachdem ich gesehen hatte, dass Battle.net-Downloads dieses Problem ebenfalls verursachen, vermutete ich sofort, dass zu viele P2P-Verbindungen meinen Router verstopfen könnten. Ich bin mir jedoch weder sicher, ob Battle.net tatsächlich P2P verwendet, noch sehe ich auf meinem Router irgendetwas Verdächtiges in Bezug auf aktive Verbindungen (~3.000 bis 4.000 Verbindungen von maximal 15.360), Speichernutzung oder Ähnliches.
Leider kann ich mir die Messwerte meines Kabelmodems nicht wirklich ansehen, da mein ISP keine entsprechende Schnittstelle bereitstellt – das ist auch der Grund, warum ich es im Bridge-Modus betreibe.
Gibt es eine Erklärung für dieses Verhalten?
Bearbeiten: Ich habe mir die ICMP-Nachrichten mit Wireshark angesehen: Der einzige erkennbare Unterschied zwischen den ICMP-Echoanforderungen, die eine Antwort erhalten, und denen, die keine erhalten:
- die ICMP-Kennung ist an den Prozess gebunden; Anfragen des laufendenKlingelnhaben die gleiche ID, Anfragen vom neustartenden Ping bekommen eine neue
- Die Sequenznummer erhöht sich mit jeder Anfrage, die vom laufendenKlingeln, wird aber für den Neustart auf 1 gesetzt
Das ist ein völlig zu erwartendes Verhalten und hilft mir nicht wirklich weiter – warum sollten die Anfragen schließlich unterschiedlich behandelt werden?
Antwort1
Wie ist das möglich? Offenbar sind „aktive Ping-Sitzungen“ von meinem Ausfall nicht betroffen. Aber bei Ping über ICMP auf Schicht 3 verstehe ich nicht, warum es einen Unterschied macht, ob Ping weiterläuft oder neu gestartet wird.
Selbst bei Protokollen ohne expliziten Status wie UDP und ICMP Echo muss Ihr Router seinen eigenen Status für seine Firewall- und NAT-Funktionen beibehalten. (Beispielsweise verfolgt er NAT-Zuordnungen, um zu wissen, an welchen internen Host die Echo-Antwortpakete zurückgesendet werden sollen.) Bei solchen Protokollen legt jedes erste von Ihnen gesendete Paket den Status fest; ein Timeout nach Inaktivität führt dazu, dass es entfernt wird.
Genau wie bei TCP merkt sich die Statustabelle die Quell- und Zielports eines UDP-Paketflusses oder die einzelne „Anforderungs-ID“ eines ICMP-Echoflusses. Obwohl ICMP keine Portnummern hat, haben Echoanforderungen eine ID, die demselben Zweck dient, nämlich Flüsse voneinander zu unterscheiden. (Wenn Sie sich eine Paketaufzeichnung in Wireshark ansehen, werden Sie dies sehen.) Das bedeutet, dass bei jedem neuen pingAufruf ein neuer Statuseintrag hinzugefügt wird.
(Ein praktisches Beispiel: Wenn Sie dies tun, conntrack -Lkönnen Sie die von der iptables/nftables-Firewall Ihres Computers verfolgten Zustände sehen. Diese sind im Grunde dieselben, die die meisten Heimrouter intern verwenden. Beachten Sie das idFeld der ICMP-Echozustände.)
Aus Ihrer Problembeschreibung geht hervor, dass die Statustabelle des Routers tatsächlich durch zu viele „Verbindungen“ voll ist und dass die Firmware so konfiguriert wurde, dass sie keine neuen Status mehr akzeptiert, anstatt alte Status weiterzugeben. (Um fair zu sein, ichdenkendas ist das Standardverhalten von Linux Conntrack?)
Es kann auch sein, dass der problematische Router einen Fehler hat, der ihn daran hindert,ClearingZustände, und sein Speicher füllt sich einfach bis zu einem Neustart; insbesondere, wenn der Router NAT auf Hardwarebeschleunigung auslagert und diese Auslagerung die Zustandsentfernung unterbrochen hat. (Es würde mich überhaupt nicht überraschen, wenn dies der Fall wäre und der ISP ihn nur so programmiert hätte, dass er einmal pro Woche neu startet, was für Gelegenheitsnutzer „gut genug“ wäre.)
Battle.net verwendet heutzutage kein P2P, es ist nur HTTP von einem CDN (obwohl es früher einmal BitTorrent-basiert war), aber estutführen zu einer relativ großen Anzahl paralleler HTTP-Downloads und können sicherlich zum Problem beitragen.
Schließlich ist es, wie in den Kommentaren erwähnt,möglich(obwohl ich nicht sicher bin, ob das wahrscheinlich ist), dass die Firewall Ihres Routers alle Filter- und/oder NAT-Regeln verliert. Das wäre für ein Linux-basiertes Gerät sinnvoll – tatsächlich verarbeitet iptables automatisch NAT für bestehende Zustände, sodass, wenn die ausgehende SNAT- oder MASQUERADE-Regel aus irgendeinem Grund entfernt wird, neue Verbindungen nicht mehr möglich sind, bestehende aber weiterhin funktionieren (sie werden weiterhin gemäß den bereits im Zustand gespeicherten Informationen NAT-getestet).
Wenn Sie keine Lösung finden, ist ein VPN wahrscheinlich eine Problemumgehung – aus Sicht Ihres Routers zählt der gesamte VPN-Tunnel nur als ein Zustand.