Re: Domain nicht mehr erreichtbar

Dirk Kring <dirk.kring@xxxxxxxx>:
Daniel Krebs <tonne@xxxxxxxxx> wrote:

Dirk Kring <dirk.kring@xxxxxxxx> wrote:

Denkst Du an fragmentierte Packete?
Daniel

ja

Dann solltest Du es dem OP auch erklären :-)

PMTUD ist ein Mechanismus (irgendwann in den 80er Jahren eingefuehrt
im Internet), um die unterste Grenze der maximalen Groesse eines
IP-Paketes (also TCP, UDP oder ICMP) zu bestimmen, die ueber einen
bestimmten Pfad (also dem Weg von Rechner A [dem Client] zu Rechner B
[dem Webserver in Irland]) moeglich ist zu bestimmen.

Wenn alles Ethernet (oder transparent dazu) waere, ware diese PMTU
1500 Byte. Aber es gibt neben PPPoE noch andere
Datenuebertragungstechnologien mit einer geringeren MTU, z.B. ATM und
eben auch PPP ueber analog/ISDN Modemlinks.

[Es werden hier keine Pakete mit irgendwelchen Fuellbytes erzeugt,
sondern die ganz normalen Datenpakete, die von der Anwendung erzeugt
werden, werden in die entsprechend grossen IP Pakete zerteilt]

PMTUD funktioniert so: es wird ein Paket mit der groesse der MTU des
lokalen Interfaces verschickt (z.B. 1500 byte bei einem Ethernet-
nterface oder Airport) und darin das sog. "don't-fragment" Flag
gesetzt, was Router die das Paket ueber einen Link mit geringerer MTU
transportieren muessten anweist, dieses Paket nicht in passendere
Fragmente zu zerlegen (was die normal machen wuerden), sondern ein
ICMP Paket zurueckzuschicken, in dem z.B. Steht "dein paket ist zu gross,
es muesse 1452 byte gross sein, dann koennte ich es weiterleiten!".
Daraus entnimmt der IP Stack des Senders nun diese neue MTU und
verschickt jetzt das naechste Paket in 1452 Byte Stuecken wieder mit
dem DF-Flag versehen. Gibt es hinter dem ersten Router noch einen
weiteren mit einer noch kleineren MTU z.B. ein ISDN-PPP-Router mit
984 Byte MTU, so geht das Spiel mit dieser MTU groesse weiter bis
der eigentlich Zielrechner erreicht wird. Damit steht dann z.B. fest,
dass der Weg zum Zielrechner Pakete von maximal 984 Byte
unfragmentiert transportieren kann.
Ab diesem Zeitpunkt verwendet dein Rechner diesen Wert als MTU fuer
alle Pakete, die zu diesem Zielrechner geschickt werden sollen.

Das ganze dient einem Zweck: Router im Internet vom Aufwand des
Fragmentierens zu entlasten.

Notwendig ist dabei, das ICMP Pakete (also die Pakete, in denen die
Router unterwegs dem Sender mitteilen, wie gross er seine Pakete
machen soll) nicht irgendwo von kaputten Firewalls weggeworfen werden
("WEil ICMP ja soooooo Boehse ist, hab isch von Kumpel gehoert!!11elf")

Was hier in diesem Fall nun passiert ist vermutlich folgendes:
(und der OP ist daran voellig Unschuldig und kann nichts dagegen
machen ausser sich beim Betreiber des Webservers beschweren)

Der Webserver in Irland moechte ganz normal PMTUD zum Mac des OP
machen (fuer den HTML Inhalt, den er seinem Browser schickt).

Da der Webserver wohl mehr als 1500 byte HTML-content hat, und der
Webserver vermutlich ueber Ethernet angebunden ist, geht das gleich
mit 1500 Byte grossen Paketen los (direkt nach dem TCP SYN/ACK
Handshake, worin noch keine Daten uebertragen werden).

Er schickt also ein Paket von 1500 Byte Groesse und mit der Anweisung
es nicht zu fragmentieren (DF-Flag gesetzt) auf die Reise zum OP.

Spaetestens der PPP-Access-Router beim ISP des OP (also das Teil, mit
dem sein Modem redet) kann aber keine 1500 Byte grossen Pakete ueber
die PPP-Modemleitung schicken, weil da z.B. nur 984 Byte reinpassen
auf einmal (eine haeufige MTU bei PPP over ISDN). Er schmeisst das
HTTP-Antwortpaket also weg und erzeugt eine ICMP Fehlermeldung, die er
brav an den Webserver zurueck schickt (darin steht: "Dein Paket soundso
ist zu gross, bitte entferne das DF flag oder mach deine Pakete
maximal 984 Byte gross!").
Die Supertoole, von Supertollen Admins "konfigurierte" Firewall vor
dem Webserver schmeisst jetzt aber vermutlich alle ICMP Pakete weg
(nicht nur die von Ping verwendeten ICMP Echo pakete, sondern auch
diese notwendigen ICMP Fehlermeldungen), womit der Webserver niemals
mitbekommt, dass seine Pakete zu gross sind, und er ewig und drei Tage
auf irgendeine Rueckmeldung wartet. (ok, er wiederholt das Schicken
dieses Paketes meistens drei bis 10 mal (je nach Betriebsystemhersteller)
und wartet ein paar Minuten. Dann gib er auf.)

Das ist also ein typischer Fall von sich-in-die-eigenen-Fuesse-schiessen.

Ausser kruden Hacks auf seiten des OP (MSS-Clamping, dass zumindest
den TCP Part des IP-Stacks des Webservers dazu bringen *kann* (nicht
muss!), keine Pakete von mehr als der MSS-Grosse (plus 40 Byte) zu
erzeugen, womit der PMTUD-Mechanismus des IP-Stacks niemals groessere
Pakete zur Verfuegung hat, PMTUD also garnicht Stattfindet) bleibt
nur die Beschwerde beim Betreiber dieses Webservers bzw. der
Vorgeschalteten Firewall.

Bei GMX hatte letzteres ja funktioniert.

Daniel

Er sagt, er geht mit einem Modem rein, da spielt das meiner Meinung nach
keine Rolle. Nur bei DSL - sprich PPPoE, da sollte dann die MTU-Größe

Falsch.

gleich kleiner 1492 sein.

Was glaubst du denn, hat ein PPP Interface auf einem asynchronen
seriellen Link fuer eine MTU? Werte von 252 oder 432 sind dort nicht
unueblich. (Damit man halbwegs ertraegliche Latenzen hinbekommt).

Da die default Windowsize von modernen TCP/IP Stacks (z.B. dem auf dem
Irischen Webserver bei den Spastikern die zu daemlich sind die
Grundlagen von IP zu verstehen, aber sich Einbilden einen Paketfilter
konfigurieren zu koennen) bereits groesser ist als die auf seriellen
PPP Links (ISDN/Analog Modem) ueblichen MTU Groessen, kann hier
schon von vorneherein keine Kommunikation funktionieren.

Und auch wenn der OP einfach PMTUD abschaltet auf seiner Seite
(sprich: Seine Pakete werden nicht laenger mit "don't fragment"
markiert, bei Mac OS X geht das per Kommando (im Terminal)
sudo sysctl -w net.inet.tcp.path_mtu_discovery=0
wird ihm das vermutlich nicht allzuviel helfen, da er keinen Einfluss
auf den Webserver nehmen kann, der sicherlich PMTUD betreiben moechte
(default heutzutage), aber von seiner eigenen vorgeschalteten Firewall
daran gehindert wird.

Er koennte jetzt noch mit TCP-MSS Manipulationen dafuer sorgen, dass
der WWW-Server garnicht erst auf die Idee kommt, groessere TCP Pakete
zu generieren (das was T-Offline Kunden ueblicherweise bei PPPoE
machen), muss hier aber einen fuer seine Modemverbindung passenden
Wert der MSS-Groesse verwenden (MTU - 40). Wie das bei Mac OS X geht,
weis ich allerdings nicht.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
.

Relevant Pages