Manchmal bemerke ich auf einem Linux-System das folgende seltsame Verhalten:
Ich kann Dinge anpingen und manchmal einige Dienste nutzen, aber die Netzwerkverbindung ist sehr schlecht.
Ich habe beispielsweise jetzt die Verbindung über meinen Laptop ( -j MASQUERADE
) geleitet und dabei Folgendes beobachtet: Wenn ich eine kleine TCP-Verbindung herstelle (der Server sendet mir wenige Daten), läuft es ab:
# nc 86.57.151.3 80
GET /404
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
/proc/net/ip_conntrack hat, tcp 6 431998 ESTABLISHED src=192.168.99.9 dst=86.57.151.3 sport=49104 dport=80 src=86.57.151.3 dst=93.125.21.218 sport= 80 dport=49104 [ASSURED] mark=0 use=2
bevor ich „GET /404“ eingegeben habe.
Aber wenn ich eine große Verbindung herstelle:
root@localhost:~# nc 86.57.151.3 80
GET /
Es bleibt hängen. Bevor ich „GET /“ eingebe, wird wie üblich ESTABLISHED ASSURED angezeigt, aber nachdem ich die Eingabetaste drücke, wechselt es zu tcp 6 0 CLOSE_WAIT src=192.168.99.9 dst=86.57.151.3 sport=56991 dport=80 src=86.57.151.3 dst=93.125.21.218 sport=80 dpo rt=56991 [ASSURED] mark=0 use=2
. Es wird kein Paket mit empfangen. Wenn ich schließlich Strg+C drücke, sendet es FIN an den Server und Wireshard beschwert sich, dass das FIN des Servers „nicht in der richtigen Reihenfolge“ ist. Als ob das Antwortpaket irgendwo verloren gegangen wäre.
Wenn ich dasselbe vom Router aus mache nc 86.57.151.3 80
, GET /
funktioniert es.
Wie kann man den Fehler beheben?
Antwort1
Dies ist irgendwo das Problem mit MTU und gefilterten ICMP-Nachrichten.
Umgehungsmöglichkeiten bestehen darin, die MTU auf dem Clientgerät einzustellen oder TCP MSS Clamping auf dem Router zu verwenden:
iptables -t mangle -A FORWARD -o ppp4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu