mtu

Die böse MTU oder warum keiner mit mir sprechen will

Man kennt das vor allen Dingen als DSL-Nutzer, man will eine Webseite besuchen und es kommt einfach nix, andere Webseiten funktionieren dagegen problemlos. Oder vielleicht ein anderes Phänomen, die Verbindung ist immer schön schnell, außer, wenn man selbst mal einen Upload macht (z.B. E-Mail versenden), der will einfach nicht. Schuld an diesen Problemen ist die MTU und alles, was damit zusammenhängt. Betroffen sind in der Regel nur Leute, die einen eigenen Router benutzen, auf Einzelplatzsystemen, die eine direkte Verbindung zum Internet haben, kommt so etwas eher selten vor. Warum das so ist, erfährt man, wenn man weiterliest. :-)

Es gibt keine einheitliche MTU für alle

Die MTU (Maxmimum Transmission Unit) gibt die maximale Größe eines Datenpakets in Bytes an, die über eine Netzwerkschnittstelle bzw. der dazugehörigen Leitung übertragen werden kann. Da es im Internet schrecklich viele verschiedene Leitungen mit schrecklich vielen verschiedenen daran angeschlossenen Übertragungsschnittstellen und -protokollen gibt es keine einheitliche MTU für alle, jede Leitung hat eine eigene MTU.

Wir stellen uns also vor ein Datenpaket geht auf Reisen von unserem Rechner zu einem beliebigen Webserver, von dem wir eine Webseite haben wollen. Anfragen für Webseiten sind recht klein, das passt meistens in ein einziges Paket. Unser Paket passiert als erstes unsere eigene Netzwerkschnittstelle, die eine gewisse MTU hat, wobei das eine normale Ethernet-Netzwerkkarte sein kann an einem Ethernet-LAN oder eine Ethernet-Netzwerkkarte an einem DSL-Modem oder ein altes analoges Modem oder eine ISDN-Karte oder... Wenn man einmal mit Aufzählungen anfängt, hat man verloren.

Ok, durch unsere Netzwerkschnittstelle gequetscht landet es normalerweise beim Router des Internet-Providers, bei dem wir uns eingewählt haben. Ist für DSL und für diverse andere Übertragungstechniken nicht korrekt der Begriff der Einwahl, aber ist ja erstmal Wurst, wir wollen die Sachlage nicht unnötig komplizieren. So ein Router ist eine Kiste, der verschiedene Netzwerke miteinander verbindet und Pakete weiterleitet, damit sie irgendwann mal ihr Ziel erreichen, sozusagen ein Verkehrsleitsystem, damit sich Datenpakete nicht verlaufen. Ich meine jetzt nicht, den Router, den man evtl. zuhause stehen hat, der Router vom Internet-Provider steht, wer hätte das gedacht, beim Internet-Provider im Rechenzentrum.

Dieser Router hat ebenfalls Netzwerkschnittstellen, durch die eine bekommt er unser Paket, durch eine andere Netzwerkschnittsstelle verlässt das Paket den Router, die wieder eine gewisse MTU hat, die unterschiedlich zu der sein kann, die die Netzwerkschnittstelle am eigenen Computer hat. Dann geht es so weiter von Router zu Router, alle Netzwerkschnittstellen, die dabei passiert werden, können verschiedene MTUs haben.

Irgendwann erreicht dann unser armes Paket, was schon durch so viele Netzwerkschnittstellen und Kabels gequetscht wurde den Webserver, der dann die Anfrage auswertet und eine Antwort, z.B. eine Webseite schickt. Webseiten sind in der Regel etwas größer und passen nicht mehr in ein Paket, man stößt an die maximale Paketgröße und muss mehrere Pakete verschicken. Wohlgemerkt, an dieser Stelle ist die maximale Paketgröße (MTU) für die Netzwerkschnittstelle des Webservers relevant, nicht die von den Routern dazwischen und auch nicht die von uns daheim. Relevant an dieser Stelle ist die maximale Paketgröße der Netzwerkschnittstelle des Webservers. Die des Webservers. Nicht die der Router dazwischen und auch nicht der von uns. Nicht der von uns, nicht der von den Routern dazwischen, sondern... genau, der Netzwerkschnittstelle vom Webserver.

Meistens treten auf dem Rückweg Probleme auf

Jetzt wird der Rückweg angetreten und wir stellen uns vor, dass diese Pakete nun auf dem Rückweg durch alle Netzwerkschnittstellen der Router unterwegs problemlos durch passen, also deren jeweilige MTU nicht überschreiten. Wir stellen uns weiter vor, dass der Router bei unserem Provider nun feststellt, dass die Netzwerkschnittstelle mit der Leitung zu uns nach Hause eine kleinere MTU hat, als die Pakete groß sind - die Pakete passen einfach nicht am Stück durch.

Was macht der Router? Er zerstückelt das Paket in mehrere Teile, so dass die Teilpakete so groß sind wie die MTU der Netzwerkschnittstelle, an der die Leitung zu uns nach Hause hängt, so dass die Pakete letztlich doch ankommen. Diese Teilpakete nennt man Fragmente.

Das doofe ist, dass dieses Zerteilen für Router Aufwand bedeutet und auch nicht jeder will aus sicherheitstechnischen Gründen mit Fragmenten, so heißen diese Teilpakete, hantieren, weil es unter Umständen lustige Effekte geben kann, wenn man Fragmente zulässt. Ist aber für den Heimbereich eher unwichtig. Also hat man sich einen Mechanismus einfallen lassen, damit Pakete nicht mehr weiter zerteilt werden müssen.

Pakete zerteilen ist aufwendig. Die Lösung: Das Don't-Fragment-Bit

Ein Datenpaket besteht aus den Steuerdaten der Kommunikationsprotokolle, den so genannten Headern, und den eigentlichen Nutzdaten. In diesen Headern ist für das Protokoll IPv4 ein Bit definiert worden, dass angibt, ob ein Paket zerteilt werden darf oder nicht. Jeder, der Pakete erzeugt, darf sich aussuchen, ob er seine Pakete unterwegs zerteilen lassen möchte, falls es notwendig wird oder eben lieber nicht. Um das anzuzeigen, setzt man im Steuerdatenteil (Header) des Kommunikationsprotokolls IPv4 dieses ominöse Bit oder eben nicht, was heißt, dass an einer bestimmten Stelle im Paket eine binäre 1 steht (genau, oder eben nicht, sondern eine binäre 0 dort steht). Dieses Bit heißt auch Don't-Fragment-Bit oder kurz DF-Bit. Wenn es gesetzt ist, also eine binäre 1 an einer vorher vereinbarten Stelle im Datenpaket steht, dann darf dieses Paket nicht zerteilt werden, ansonsten schon.

Ein Router ist wie gesagt eigentlich ganz dankbar, wenn er keine Pakete zerteilen muss, das liegt denen nicht so gut und außerdem muss irgendein Idiot (meist ein anderer Router) diese Fragmente auch wieder zu Paketen zusammensetzen, das liegt denen erst recht nicht gut. Besser ist es, wenn Pakete erst gar nicht unterwegs zerteilt und wieder zusammengesetzt werden müssen, sondern nur weitergeleitet bzw. verworfen werden müssen.

Und weil das so ist hat man sich gedacht, dass es doch ganz nett wäre, wenn standardmäßig in allen Paketen, die man so auf Weltreise schickt dieses DF-Bit setzt, also Pakete nicht mehr zerteilt werden, wenn sie mal irgendwo nicht am Stück durchpassen.

Werden Pakete verworfen, bekommt man eine ICMP-Nachricht

Das ist jetzt ganz schön, aber das Dumme ist, dass das auf der anderen Seite auch heißt, dass Pakete, die auf ihrem Weg durchs Internet irgendwann mal eine Stelle passieren, an der das Paket größer ist als die dort maximale Paketgröße (der MTU), verworfen werden. Und jetzt? Nun, der Router, dem das Paket nicht passt, schickt nun eine Nachricht zurück mit dem schönen Protokoll ICMP (damit kann man auch Ping machen), dass das Paket bei ihm nicht durch die Leitung passt mit einem Vermerk dabei, welche Paketgröße ihm denn genehm wäre.

Wenn diese Nachricht bei uns ankommt (und das ist sehr wichtig, dass sie ankommt, sonst weiß man ja nicht, warum es hakt), dann kann der eigene Computer passende kleinere Pakete schicken, so dass dann unsere Datenpakete überall durch passen, ohne weiter zerteilt werden zu müssen, was wir mit dem gesetzten DF-Bit untersagt haben.

Wenn man sich jetzt fragt, warum man denn auf dem Bildschirm noch nie solche Nachrichten gesehen hat, muss man sich übrigens keine Sorgen machen, diese Nachrichten verarbeitet das jeweilige Betriebssystem (Linux, Windows, BSD und andere) automatisch, als Benutzer sieht man davon genau gar nix. Wenn man aber mal einen Sniffer wie Ethereal benutzt, kann man sich grafisch mal solche Pakete angucken - man kann mit Ethereal Fehler im Netzwerk aufspüren oder einfach mal sich anschauen, wie die einzelnen Pakete, bestehend aus den verschiedenen Steuerdaten der Protokolle und den eigentlichen Nutzdaten aussehen, um etwas zu lernen.

Wir wissen nun, wie Path-MTU-Discovery funktioniert

Dieses gerade beschriebene Verfahren heißt übrigens Path-MTU-Discovery, was nichts anderes heißt, dass die maximale Paketgröße eines Kommunikationspfades ermittelt wird, damit gesendete Pakete ohne weiter zerteilt werden zu müssen überall durch passen. In der Regel wird genau dieses Verfahren verwendet bei der Kommunikation per Internet. Nebenbei sei noch erwähnt, dass es im Internet keine festen Pfade für Datenpakete gibt, theoretisch kann jedes Paket einen anderen Weg nehmen, so dass eigentlich die Idee zu Path-MTU-Discovery, also der Ermittlung der maximal zulässigen Größe eines Datenpakets für einen bestimmten Kommunikationspfad schwachsinnig ist, denn wenn jedes Paket einen anderen Weg nimmt, hat die in einem Schritt ermittelte maximale MTU für das nächste Datenpaket gar keine Bedeutung mehr, weil ja ein anderer Weg genommen wird. Funktioniert aber trotzdem, weil meistens die Leitungen am Ende eines Kommunikationspfades Probleme machen und die ändern sich eben nicht. Außerdem gibt es auch in der Praxis eine gewisse Stabilität bei den benutzen Datenpfaden, die man aber theoretisch eigentlich nicht voraussetzen darf. Diese Anmerkung darf man gerne wieder vergessen, wenn man will, da sie für das Verständnis der MTU-Problematik nicht relevant ist.

Jetzt fangen die Probleme an

Jetzt gibt es aber ein Problem, dieses Problem heißt Paketfilter. Ein Paketfilter ist ein Programm, dass sich Pakete (meist auf Routern) anguckt, die über eine Leitung hereinkommen und nach Regeln, die der Mensch, der den Paketfilter eingestellt hat, Pakete weiterleitet oder eben verwirft. Zweck dieser Geschichte soll grob gesagt sein, Netzwerke vor einem Teil von Angriffen zu schützen - eigentlich ein sehr nützliches Werkzeug.

Aber auch nützliche Werkzeuge können in den Händen von wenig erfahrenen Administratoren (so schimpft man die Leute, die so ein Zeug wie Paketfilter einstellen, immer viel Kaffee trinken und arme Benutzer anschreien oder anderweitig bestrafen) sehr unnützlich werden, z.B. wenn der betreffende Administrator denkt, dass die eben besprochene Nachricht, die ein Router losschickt, wenn ein Paket nicht durch die Leitung passt, gefährlich wäre. Ja, solche Administratoren gibt es und ist anzunehmen, dass die Evolution solche Administratoren auch noch eine ganze Weile bereitstellt. Als ich begann mich mit Netzwerken zu beschäftigen, hätte ich übrigens genau den gleichen Fehler gemacht, aber zum Glück war ich nie für einen Router zu dieser Zeit verantwortlich.

Das eigentliche Problem sind also falsch konfigurierte Paketfilter

Werden diese wichtigen Nachrichten also weggeschmissen, funktioniert die Verbindung zwischen den beiden Kommunikationspartnern nicht bzw. unter Umständen nur stockend. Ja, das ist ziemlicher Mist und es gibt nun verschiedene Möglichkeiten das Problem zu lösen bzw. teilweise zu lösen und/oder zu verlagern:

Lösungsweg 1:

Stelle finden, wo das Paket weggeschmissen wird, meistens an den Enden eines Kommunikationspfades, also entweder bei uns selbst oder beim letzten Router vor dem Kommunikationspartner. Waren wir selber so schlau uns mit einem Paketfilter auf unserem eigenen Router ins Knie zu schießen, kann man das Problem einfach lösen, indem man den Paketfilter passend konfiguriert. Übrigens blockiert man mit einem Paketfilter auf dem eigenen Router nur den Hinweg der Datenpakete, sprich unsere Rechner im eigenen lokalen Netzwerk bekommen keine (ICMP-)Nachricht von unserem eigenen Router, dass sie bitte kleinere Pakete senden soll. Ist der Rückweg der Datenpakete betroffen, wird diese Nachricht nicht von unserem Router erzeugt, sondern von dem beim Internet-Provider und geht natürlich auch nicht an unsere Adresse, sondern an die unseres Kommunikationspartners - wir sehen also gar nichts davon. Ist also der Rückweg der Datenpakete betroffen, muss man mal versuchen irgendwie den Administrator des letzten Routers vor unserem Kommunikationspartner ausfindig zu machen und den davon überzeugen, dass ICMP-Nachrichten keine bösen Sachen sind.

Daraus leitet sich unmittelbar Lösungsweg 2 ab:

Falls man keine Lust hat den Admin zu überzeugen bzw. dieser sich nicht überzeugen lässt, Kommunikation mit dem Kommunikationspartner als unerwünscht katalogisieren und in Zukunft einfach unterlassen.

Lösungsweg 3:

DF-Bit nicht mehr setzen und damit kein Path-MTU-Discovery machen; Pakete werden bei Bedarf weiter zerteilt und gut is. Manche Paketfilter hauen aber fragmentierte Pakete in die Tonne und besonders Router-freundlich ist das auch nicht. Auf der anderen Seite wird mit der MSS bei TCP (muss man jetzt noch nicht verstehen, mehr dazu später) schon (eher zufällig) dafür gesorgt, dass möglichst wenig fragmentiert werden muss - im Endeffekt ist in der Praxis diese Lösung also gar nicht wirklich schlecht. Falls es jedoch auf dem Rückweg hapert (und das ist meistens so), muss man die Gegenstelle überzeugen das DF-Bit nicht zu setzen. Das kann man technisch leider aber nicht und man muss also den Admin der Gegenstelle kontaktieren, dass der das einstellt. Wieso fällt mir eigentlich wieder Lösungsweg 2 ein?

Lösungsweg 4:

Prinzipiell kleinere Pakete senden. Man kann natürlich die eigene MTU auf den Heimrechnern (nicht auf dem eigenen Router) so klein drehen, dass alle Pakete, eigentlich immer überall durch passen. Das ist eigentlich keine tolle Lösung, weil man erstens damit die maximale Nutzdatenübertragung pro Zeiteinheit senkt und unter Umständen sich eine Sicherheitslücke einhandelt, aber es funktioniert meist problemlos. Das Herabsetzen der MTU hört sich logisch und einfach an, ganz so einfach ist aber das warum nicht, denn meistens klemmt gar nicht der Hinweg zu unserem Kommunikationspartner, sondern der Rückweg - trotzdem hilft das Herabsetzen der eigenen MTU auch für den Rückweg. Klingt komisch, ist aber so.

Warum hilft es denn nun die eigene MTU zu verkleinern? Ein kleiner Einschub

Betroffen von dieser MTU-Geschichte sind meist DSL-Nutzer, dass bestimmte Verbindungen nicht funktionieren. Ursache für das MTU-Problem sind wie gesagt unwissende Administratoren, aber es gibt 2 Gründe, warum DSL-Nutzer häufiger betroffen sind.

Warum ist das so? DSL-Nutzer haben oftmals einen DSL-Router und damit ein lokales Netzwerk (LAN) und die MTU für DSL-Leitungen mit 1492 Bytes (in der Regel ist das der Wert, kann aber auch nach oben oder unten abweichen) geringfügig kleiner, als die aller anderen Router und Server im Internet, welche meist minimal eine MTU von 1500 Bytes auf den Netzwerkschnittstellen haben. Engstelle ist also die eigene Leitung. Warum wird diese Kombination in Verbindung mit unwissenden Administratoren zum Problem?

Im Kommunikationsprotokoll TCP gibt es ein Feld, in dem die maximale Größe für TCP-Pakete angegeben ist. Um das jetzt mit den Kommunikationsprotokollen wie TCP und IPv4 auf die Reihe zu kriegen, muss man wissen, dass es mehrere Kommunikationsprotokolle gibt, die verschiedene Aufgaben haben und jeweils in Paketen einen Steuerdatenteil haben und einen Nutzdatenteil und diese Protokolle ineinander eingepackt werden. Verwirrt? Macht nix, ein kleines Bild, um das zu verdeutlichen hilft vielleicht.

Wichtig ist auch nicht zu verstehen, wofür welches Kommunikationsprotokoll gut ist, sondern wichtig ist nur, dass es eben wie dieses DF-Bit auch noch andere Steuerdaten u.a. von anderen Protokollen gibt und dass es diese Verschachtelung von Protokollen gibt, wobei jedes Protokoll eigene Steuerdaten (Header) hat.

Ok, also nochmal zusammenfassen: Es gibt irgendwo im Steuerdatenteil des Protokolls TCP eine Stelle, wo man die maximale Größe eines TCP-Paketes eintragen kann und die verschiedenen Protokolle werden ineinander verpackt. Warum soll man das mit der Verpackung wissen? Weil die maximale Größe eines TCP-Pakets ungleich der maximalen Größe eines kompletten Datenpakets ist, weil der TCP-Teil eben nur ein Teil des gesamten Datenpakets ist. Also einfach nochmal auf dieses Bild schauen.

Die MTU begrenzt die Größe eines gesamten Datenpakets (eigentlich die Größe des Datenpakets abzüglich des Headers der Netzzugangsschicht, aber das ist jetzt nicht so wichtig), jetzt kann man die verschiedenen Header-Größen der diversen Kommunikationsprotokolle abziehen, die ja ineinander verpackt sind und kommt dann irgendwann bei einer maximalen Größe eines TCP-Paketes an, dass in diesem ganzen Datenpaket drinsteckt. Puh, ist das heute wieder kompliziert.

Was wichtig ist, ist die Erkenntnis, dass zwar MTU und maximale TCP-Paketgröße (MSS - Maximum Segment Size) unterschiedlich sind, aber bei uns zuhause zumindest sich durch einen konstanten Wert unterscheiden, nämlich der Byte-Anzahl, auf die man kommt, wenn man die Größen der ganzen Protokoll-Header zusammenrechnet bis man beim Protokoll TCP landet, ausgenommen dem Header der Netzzugangsschicht (also z.B. Ethernet), der fehlt nämlich schon bei der MTU. Also konkret in diesem Fall ist die Rechnung nicht so schwer, nämlich MTU - IPv4-Header - TCP-Header = MSS.

Ein Feld für die MTU gibt es übrigens nicht, aber wir wissen jetzt, dass es eine Verbindung zwischen MSS (maximale TCP-Paketgröße) und MTU (maximale Paketgröße) gibt. Kurzum: In TCP-Paketen steht zumindest beim Verbindungsaufbau einer Kommunikation mit einem Kommunikationspartner die MSS drin, diese landet auch beim Kommunikationspartner und der richtet sich danach, was in dieser MSS drin steht und sendet zurück TCP-Pakete, deren Größe nicht größer als die MSS des Paketes auf dem Hinweg war.

Also beeinflusst man mit der MTU am eigenen Rechner die maximale Größe eines TCP-Paketes (MSS); schraubt man die MTU herunter, schraubt man auch die MSS herunter. Die MTU steht nicht in den Paketen, wohl aber die MSS. Die MSS landet beim Kommunikationspartner, er beachtet diese und schickt passend kleine Pakete zurück.

Jetzt sind wir fast da: In einem gewöhnlichen lokalen Netzwerk (LAN) benutzt man Ethernet. Ethernet hat eine MTU von 1500 Bytes, wie gesagt alle Server und Router im Internet haben auch (mindestens) eine MTU von 1500 Bytes. Für DSL benutzt man auch Ethernet, allerdings stülpt man da noch ein Protokoll drüber, das schimpft sich PPPoE und hat einen Header mit einer Größe von 8 Bytes. Also hat so ein DSL-PPPoE-Dings eine MTU von 1500 Bytes - 8 Bytes = 1492 Bytes. Das ist dann in der Regel die Engstelle, weil alle Welt eigentlich sonst Pakete mit einer maximalen Größe von 1500 Bytes durch die Gegend schickt.

Sendet jetzt so ein Rechner im eigenen Netzwerk eine Anfrage los, so wird die MSS natürlich entsprechend der MTU für Ethernet gesetzt, was aber leider genau 8 Bytes zu groß für DSL mit PPPoE ist, nämlich MTU für Ethernet (1500 Bytes) abzüglich der Größe eines IP-Headers + TCP-Headers, das sind 40 Bytes mindestens, ergibt eine MSS von 1460 Bytes. Diese "zu große" MSS (in Wirklichkeit ist diese MSS natürlich nicht zu groß, sondern genau richtig, nur in diesem Fall funktioniert dieser eher zufällige Mechanismus dann nicht mehr, dass die MSS hilft die passende maximale Größe für ein Paket auf dem Rückweg zu setzen) führt dann dazu, dass die Gegenstelle eben zu große Pakete zurückschicken und diese am Ende nicht mehr durch unsere etwas "dünnere" DSL-Leitung durch passen, weil dieser doofe PPPoE-Header eben 8 Bytes klaut. Der Router beim Provider schickt also eine Nachricht los, bitte kleinere Pakete zu schicken, aber die wird ja wie oben erläutert von unwissenden Administratoren mit Paketfiltern weggefiltert und die Kommunikation funktioniert nicht.

Schraubt man jetzt auf den Rechnern im lokalen Netzwerk die MTU auf 1492 Bytes herunter, obwohl sie eigentlich mit 1500 Bytes für Ethernet sinnvoll gesetzt ist, so wird dadurch die MSS beeinflusst und auf dem Rückweg passen, weil die Gegenstelle die MSS beachtet, die Pakete auch wieder durch unsere DSL-Leitung.

Hat man keinen DSL-Router und schließt seinen Rechner direkt am DSL-Modem an, so wird natürlich direkt die MSS passend gesetzt, weil die MTU ja eben nur auf maximal 1492 Bytes stehen kann bei DSL mit PPPoE und das Problem tritt nicht auf - zumindest nicht bei Kommunikation, in der das Protokoll TCP verwendet wird.

Lösungsweg 5:

Man nutzt das gerade beschriebene Verhalten mit der MSS, ändert aber nicht die MTU auf den Rechnern im LAN, sondern sagt dem eigenen (DSL-)Router, dass er heimlich die MSS in den TCP-Paketen ändern soll, das nennt sich dann MSS-Clamping. Nein, man soll nicht die MTU auf dem Router herunterstellen, dadurch kann man nämlich die MSS der Pakete, die der Router nicht selbst erzeugt, nicht ändern. MSS-Clamping ist ein gesonderter Mechanismus und kann beispielsweise auf einem Linux-Router mit iptables konfiguriert werden oder in dem PPPoE-Treiber. Damit kann man das Kommunikationsproblem auch (teilweise) umgehen. Lösungsweg 5 ist praktisch die automatische Variante von Lösungsweg 4. Vorzuziehen ist natürlich Lösungsweg 5 vor Lösungsweg 4, weil man nur an einer Stelle, nämlich dem Router schrauben muss. Die Rechner im LAN muss man nicht anfassen und die MTU bleibt auf den Rechnern im LAN weiterhin auf den für Ethernet sinnvollen wert, nämlich 1500 Bytes.

Probleme mit den einzelnen Lösungen:

Es gibt neben dem Protokoll TCP auch noch andere Protokolle, die dieses Feld der MSS alle nicht kennen. Somit sind Lösungsweg 4 und 5 nur Teillösungen. Da aber das Protokoll TCP sehr häufig genutzt wird (WWW, E-Mail, News, etc.), fällt das dem ein oder anderen gar nicht auf, dass es nur eine Teillösung ist. Auch helfen diese Lösungen 4 und 5 nicht, würde die Engstelle nicht am Ende der Leitung sitzen, sondern mittendrin, weil ja dann die MSS nicht passend zur Engstelle gesetzt würde, kommt aber so gut wie nie vor. Auch kann die Größe der Header größer sein, als oben im Rechenbeispiel angenommen - dann funktioniert das ganze natürlich auch nicht mehr. Lösung 1 und 2 dagegen lösen das Problem fast vollständig, mit Lösung 3 holt man sich unter Umständen neue Probleme ins Haus der Gestalt, dass manche Paketfilteradmins fragmentierte Pakete wegschmeißen (was auch leicht bescheuert ist, man könnte sie lieber zusammensetzen und dann darauf filtern), fragmentieren ist aber die sauberste Lösung von allen - leider kommt man aber von Lösung 3 meistens ganz schnell zu Lösung 2, weil ja in der Regel der Rückweg der Datenpakete nicht funktioniert.

Ein paar praktische Tipps:

Natürlich gibt es für den ein oder anderen Lösungsweg auch noch praktische Tipps zur Umsetzung, die MTU-Mini-FAQ kann da recht nützlich sein.