Ich untersuche derzeit Netzwerkprobleme im LAN eines Freundes (wieder). Die Internetverbindung ist sehr langsam und unzuverlässig und manchmal funktionieren Dienste einfach nicht.
Ich habe den Verkehr eine Zeit lang mit Wireshark überwacht. Schließlich bin ich auf ein reproduzierbares Problem gestoßen, einen git pullOver ssh, der nicht funktionierte. So sah das Wireshark-Protokoll aus git pull:
Die TCP-Neuübertragungen beginnen immer, wenn der Schlüsselaustausch eingeleitet wird. Entweder empfängt der Server das Paket von meinem Computer nicht oder mein Computer erhält seine Antwort nicht. Ich habe das Gefühl, dass die Ursache dafür auch die Ursache für alle anderen Netzwerkprobleme des LAN ist.
Mir ist aufgefallen, dass 1514alle fehlerhaften Pakete hier eine Paketlänge von haben, wobei das Nichtfragmentierungsbit gesetzt ist, aber der Router des LANs ist für eine MTU von konfiguriert 1492. Ich kann den Router nicht für eine MTU größer als konfigurieren 1500. Könnten die Pakete zu groß sein, sodass sie am Router hängen bleiben?
Außerdem scheinen hauptsächlich sichere Verbindungen (https, ssh) betroffen zu sein, aber auch diese können immer größere Paketgrößen erfordern.
Ich habe nicht viel Erfahrung mit Netzwerken und hoffe daher, dass einige von Ihnen mit mehr Erfahrung dies besser verstehen.
Bearbeiten: Gerade eben git pullfunktioniert es wieder einwandfrei. Die MTU-Konfiguration kann nicht die Ursache der Probleme sein...
Antwort1
Große Pakete mit „Nicht fragmentieren“ sind normal. So führt das Betriebssystem die MTU-Erkennung durch – anstatt das Netzwerk die Pakete still und leise fragmentieren zu lassen, erwartet es die Rückgabe eines ICMP-Fehlers „Fragmentierung erforderlich“ (der die richtige MTU enthalten würde).
Wenn Sie sehen, dass große Pakete erneut übertragen werden, bedeutet dies, dass ein Router in der Mitte falsch konfiguriert ist und die ICMP-Fehlerpakete entweder blockiert oder sie bei Bedarf nicht sendet.
Antwort2
Ich denke, es kommt zu einer doppelten Bestätigungnurwenn der Empfänger eine Lücke in den Sequenznummern sieht, bedeutet dies, dass ein Paket auf dem Weg dorthin verloren gegangen ist; das Problem beginnt also in der Richtung von 192.168.0.8 zum Remote-Server. Die Tatsache, dass trotz mehrerer erneuter Übertragungen keine Bestätigungen (nicht einmal doppelte Bestätigungen) zurückkommen, bedeutet wahrscheinlich, dass in dieser Richtung etwas völlig schiefgelaufen ist. (Es könnte bedeuten, dass die Remote-Seite nicht senden kann, aber das ist weder mit der doppelten Bestätigung von vorhin noch mit der Fin-Bestätigung später konsistent. Es würde bedeuten, dass es 2 Probleme statt 1 gibt.)
Hier sind ein paar Ideen:
- Wenn die Verbindung über ein schlechtes öffentliches WLAN oder 3G erfolgt, kann es zu kurzen Zeiträumen mit 100 % Paketverlust kommen. Überprüfen Sie dies, indem Sie gleichzeitig einen anderen Dienst verwenden und prüfen Sie, ob dieser ebenfalls vom Ausfall betroffen ist.
- Es gibt protokollbewusste Firewalls, die möglicherweise eine Weile brauchen, um herauszufinden, was Sie tun, bevor sie entscheiden, Pakete auf einer bestimmten Verbindung zu verwerfen. Betreibt Ihr Freund eine exotische Firewall, die ausgeschaltet werden könnte? Hat der ISP Nutzungsregeln?
- Versuchen Sie, die Treiber zu aktualisieren oder von einer Linux-Live-CD zu booten, und prüfen Sie, ob das Gleiche passiert. Versuchen Sie, andere Aspekte der Verbindung zu ändern und andere Dienste zu verwenden, um den Fehler einzugrenzen.