Hallo Riven und andere,
es ist nun schon über ein Jahr her, dass der letzte Beitrag geschrieben wurde. Da ich vor ein paar Tagen wieder mit einem ähnlichen Problem konfrontiert war und auch dort Dateiübertragungen via TCP ab einer bestimmten Dateigröße nicht mehr funktionierten, erinnerte ich mich plötzlich wieder an diesen Thread.
Deiner oben zitierten Aussage muß ich insofern widersprechen, als daß FTP ein auf TCP/IP-basierendes Protokoll ist und Probleme mit der Fragmentierung vom IP-Stack und nicht auf FTP-Ebene behandelt werden.
Korrekt, wird von TCP gehandelt. Und genau da (und nicht, wie von mir fälschlicherweise erninnert, bei FTP) liegt der Hase im Pfeffer.
Siehe "Path MTU Discovery" bei Wikipedia (
http://de.wikipedia.org/wiki/PMTUD):
PMTUD (Path Maximum Transmission Unit Discovery) ist ein Algorithmus zum Bestimmen der maximalen Paketgröße, die über eine bestimmte Route im Netzwerk verschickt werden kann, ohne dass Datenpakete fragmentiert werden müssen.
Um die maximale Größe zu bestimmen, die ein Datenpaket haben darf, muss die Stelle der Route gefunden werden, die die kleinsten Datenpakete zulässt. Dazu wird ein IP-Paket versendet, bei dem das DF-Bit (Don’t Fragment) gesetzt ist und welches die Größe der lokal eingestellten Maximum Transmission Unit besitzt.
Kommt das Paket an eine Stelle im Netzwerk, an dem nur eine kleinere MTU verarbeitet werden kann, wird ein ICMP Error Typ 3 Code 4 (Destination Unreachable Fragmentation Needed, DF Set) zurück geschickt, welcher auch die eigene MTU enthält. Der lokale Rechner erhält dieses ICMP-Paket und versendet nun die Nachrichten in der Größe der zurück gelieferten MTU und vermeidet somit die Fragmentierung des Paketes über der gesamten Route.
Werden die ICMP-Typ-3-Code-4-Pakete an einem Punkt der Route gefiltert, zum Beispiel durch ein einfaches „ICMP deny“ auf einer Firewall, kann es zu Übertragungsproblemen kommen, wie im Artikel Maximum Transmission Unit beschrieben.
...und solche Firewalls, die den ICMP filtern, waren früher als "Black Holes" bekannt. Die Thematik wird in der RFC 2923 (
http://tools.ietf.org/html/rfc2923) behandelt:
This shows up as a TCP connection which hangs (fails to make progress) until closed by timeout (this often manifests itself as a connection that connects and starts to transfer, then eventually terminates after 15 minutes with zero bytes transfered). This is particularly annoying with an application like ftp, which will work perfectly while it uses small packets for control information, and then fail on bulk transfers.
Wie ich schon schrieb, fährt das FTP-Protokoll zweigleisig:
- Kleine Pakete für die Steuerinformationen (Kommunikation Server-Client)
- Große Pakete für den eigentlichen Dateitransfer
Der TCP-Stack versucht also, bei Beginn der Übertragung per PMTUD die maximale Pfad-MTU (von Client bis Server) zu ermitteln. Ist ein Black-Hole (Firewall mit aktiviertem ICMP-Filter) dazwischen, bleibt die Antwort aus. Infolge dessen wird vom TCP-Stack die MTU des lokal genutzten Interfaces (z.B. 1500 Bytes bei Ethernet) genutzt.
Eine kleinere MTU auf dem Pfad bis zum Server bleibt somit unentdeckt.
Solange PMTUD aktiv ist, wird bei allen Paketen das "DF"-Flag ("Don't Fragment") gesetzt. Das Problem daran ist, das TCP PMTUD (und damit auch das DF-Flag) nicht ausschaltet, wenn die Antwort von der Gegenstelle aufgrund eines Black Holes ausbleibt.
Für einen Pfad mit existentem Blackhole (Firewall mit ICMP-Filter) heißt das also:
- TCP aktiviert PMTUD und versucht die Pfad-MTU zu ermitteln. Dafür wird das DF-Flag eingeschaltet.
- Das "Black Hole" filtert ICMP und verhindert die Sendung oder Antwort (je nach Fitlterrichtung)
- TCP wartet nach wie vor auf die Antwort, das DF-Flag ist immer noch gesetzt
- Solange noch keine Antwort vorliegt, nimmt TCP die lokale MTU-Einstellung (z.B. 1500 Bytes), was evtl. unbekannterweise zu groß ist
- Jetzt kommt FTP ins Spiel:
- Das FTP-Protokoll baut eine Steuerverbindung zum Server auf. Kein Thema, die Pakete kommen aufgrund der geringen Größe (wenige Bytes) alle durch.
- Jetzt startet ein FTP-Dateitransfer. Das DF-Flag im TCP-Stack ist wegen der fehlenden Antwort noch immer gesetzt und die PMTU ist nicht ermittelt.
- Alle FTP-Pakete, die kleiner sind als die (nicht ermittelte) Pfad-MTU, passieren den Pfad problemlos. Dazu gehören die Pakete der FTP-Steuerung: Client und Server können noch immer problemlos Kommandos und Antworten austauschen.
- Alle FTP-Pakete, die die Pfad-MTU (unbekannterweise) übersteigen, werden wegen des gesetzten DF-Flag gefiltert und erreichen ihr Ziel nicht
- Da die Steuerverbindung immer noch steht, sieht für FTP alles gut aus, nur scheinen die Pakete nicht anzukommen. Die Übertragung der zu großen Pakete läuft ins Timeout.
Der eigentliche Fehler des TCP-Stack liegt darin, dass er nach mehreren Timeouts (solange PMTUD ohne Antwort) die MTU nicht einfach kleiner stellt (auf ein sicheres Maß, z.B. 296 Bytes für PPP).
Insbesondere "verwirft" ein FTP-Server oder -Client keine Datenblöcke. Es kann höchstens vorkommen, daß einzelne Datenblöcke wegen Problemen auf tieferen Ebenen erst gar nicht ankommen und die empfangene Datei deshalb fehlerhaft ist. FTP baut dabei auf die fehlerfreie Übertragung durch die TCP-Schicht.
...absolut korrekt. Ich hatte es dank fehlerhafter Erinnerung auf FTP und nicht auf den TCP-Stack geschoben. Insofern "verschluckt" der FTP-Server oder -Client keine Datenblöcke - vielmehr sind es für den Pfad zu große Pakete, die wegen des noch gesetzten "Don't-Fragment"-Flag vom ersten Netzelement mit einer kleineren MTU als der ankommenden Paketgröße gedroppt werden.
WORKAROUND / HOW TO FIX:
Als Abhilfe für das urspüngliche Problem mag gelten, dass man alle Firewalls, die sich unter eigener Kontrolle befinden, kontrolliert und ggf. das ICMP-Filtern (Ping-Filter) abschaltet. Da manche Traceroute-Imlementierungen ebenfalls PMTUD verwenden, wäre zur Kontrolle ein Traceroute eine Möglichkeit.
Sind die "Black Holes" nicht unter Deiner Kontrolle (also in fremden Segmenten), bleibt nichts anderes, als an den Stellen zu drehen, wo es möglich ist: Von beiden Seiten aus zur jeweils anderen sollte mit dem in der oberen Nachricht angehangenen Programm (oder per Ping mit variierender Paketgröße mit gesetztem DF-Flag) die MTU ermittelt werden. Stehen die beiden Werte fest, nimmt man den Kleineren der beiden und trägt diese selbst ermittelte PMTU als MTU an beiden Endstellen ein. Wenn die beteiligte Software (z.B. VPN-Tunnel) dies zulässt, sollte auch wenn möglich an beiden Endstellen die "Path MTU Discovery" (PMTUD) abgeschaltet werden, da ansonsten immer das DF-Flag gesetzt bleibt.
Es möge mir verziehen sein:
Lieber ne späte Antwort / Richtigstellung als gar keine
Gruß,
ArtExplorer
