Die Host, von denen mein Exim (und wahrscheinlich auch die anderer Kunden) blocken erlauben allesamt keine Pings (sowohl von vdserver aus, als auch von meinem DSL-Anschluß). Zum überprüfen empfehle ich:
"grep timeout /var/log/exim/mainlog" . 

Eine Lösung wäre für mich wahrscheinlich mit IPTABLES PMTU zu setzen. Das erlaubt mir der Kernel aber nicht:

Das wäre dieser Befehl: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu

Siehe "man iptables":

This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:

http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#PMTUD

Warum muß man die MTU Größe anpassen, wenn Paketfilter eingesetzt werden?
    Man darf nicht planlos ICMP sperren, dann gibt es die Probleme nicht mehr. Der Hintergrund ist eigentlich ganz einfach: Path MTU Discovery.

    Wenn man ein IP Paket auf die Reise schickt, dann kann es passieren, daß unterwegs die Leitungs-MTU kleiner wird und das Paket nicht mehr durchpaßt. Normalerweise zerlegt der Router, dem das passiert, das IP Paket in Fragmente und schickt die durch. Einfach, trival, funktioniert.

    Manchmal will man das nicht, so daß man ein "Don't Fragment" Bit im IP Header setzen kann, wenn das Paket nicht zerlegt werden darf. In dem Fall schickt der Router, dem das trotzdem passiert, ein ICMP 'Destination unreachable: Fragmentation needed, but DF set.' an den Absender zurück. Der weiß nun, daß es nicht geklappt hat.

    Nun hat jemand sich vor einigen Jahren gedacht, daß es prima wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle Pakete mit gesetztem DF Bit gesendet. Kam von einem Router eine ICMP Fehlermeldung zurück, dann hat er die in der Fehlermeldung mit angegebene maximale Größe der Strecke genommen und nur für diese Verbindung kleinere Pakete gesendet. Das Ganze nennt man PMTUD.

    Darüberhinaus gibt es Buffergrenzen, die ein IP-Stack vorhält, wenn er TCP-Segmente verarbeitet. Um der Gegenseite mitzuteilen, welche maximalen Segmentgrößen er verträgt, setzt er beim Verbinungsaufbau (SYNC) die Option TCPMSS (TCP Maximum Segment Size).

    Irgendwann beobachtete jemand anderes, daß die "dünneren" Leitungen, die also kleinere MTUs haben, meist beim Endpunkt einer Verbindung stehen und dachte sich, man könne die Buffergrenzen des TCP Stacks ebenfalls als Obergrenze der MTU interpretieren. Der Gedanke allein ist derartig schwachsinnig, daß es schmerzt: Hier wurde Kausalität und Korrelation verwechselt. Man setzt nämlich die Puffergrenzen so, daß sie in der lokalen Umgebung sinnvoll sind, und das ist zufällig die LeitungsMTU am nächsten Interface, weil ja einkommende Pakete eh' nicht größer sein können. Das sagt natürlich gar nichts über die MTU der Leitungen zwischen den Endgeräten aus, besonders, da die allerletzte Strecke meist ein "dickes" Ethernetinterface ist.

    Kurz gesagt hat sich der Letztgenannte also eine Modifikation des TCP/IP Stacks dahingehend einfallen lassen, daß der den TCPMSS Parameter als Startwert für PMTUD nimmt.

    Neu in dem Szenario sind jetzt die strunzdämlichen Paketfilter-Admins, die ICMP als Angriff werten und abschalten. Danach geht nichts mehr, wenn einer von beiden PMTUD probiert. Die Pakete können grundsätzlich nicht durchkommen, weil die Fehlermeldungen weggeworfen werden. Und anstatt nun einfach PMTUD abzuschalten, so daß es gar keine Fehlermeldungen mehr gibt, setzt man die MTU auf dem Interface so geschickt niedrig, daß die ausgehenden Pakete grundsätzlich klein genug sind, um überall durchzukommen. Außerdem signalisiert man mit TCPMSS der Gegenstelle, doch bitte kleine Pakete zu senden. Das ist zwar ineffizient, aber es gibt keine Fehlermeldungen mehr, die von dem strunzdämlichen Paketfilter-Admins des Serverproviders weggeworfen werden könnten.

    Anstatt den Wunsch der betreffenden Firma zu respektieren und die Webseiten links liegen zu lassen, setzen die Leute ihre MTU auf den Interfaces herab und produzieren so kleinere Buffer im TCP-Stack, der von anderen Systemen bequem überschrieben werden kann, so daß man sich selbst eine Sicherheitslücke baut und von der Kommunikation mit anderen Systemen ausschließt. Es sei denn, man sagt die kleinere MTU /allen/ Geräten im lokalen Netz, auch dem Server. Oder man sagt seinem Außenrouter, er möge doch bitte die TCPMSS Optionen, so sie mal gesetzt sind, an die MTU der Außenleitung anpassen. Das nennt man MSS-Clamping. Es funktioniert dann aber nur für TCP Verbindungen, die man selbst mit TCPMSS Optionen begann. UDP und andere Protokolle sind davon unberührt.
]]]

Wo kann ich meinen Rechner scannen lassen?
    Es gibt einige frei zugängliche Scanner. U.a.:

        * http://webscan.security-check.ch/ scant den Anfragenden, ist leicht verständlich und durchaus gehoben.
        * http://check.lfd.niedersachsen.de/start.php
        * http://www.linux-sec.net/Audit/nmap.test.gwif.html basiert auf nmap und man kann in Grenzen eigene Optionen angeben.
        * http://mirror.ping.de:8888/#portscan bietet nmaps TCP-, SYN- und NULL-Scan.
        * http://www.securityspace.com/sspace/index.html Unter "Free Trial Audit" gibts einen sehr umfangreichen Scan gegen E-Mail-Adresse einmal gratis.
        * https://freescan.qualys.com/ scant beliebige IP-Adressen gegen E-Mail-Adresse, verschweigt in der kostenlosen Version allerdings Details über gefundene schwere Sicherheitslücken. 
[[[
Ist NAT ein ausreichender Schutz für Surfer?
    Adressumsetzung (NAT) wurde entwickelt, um Kommunikation zwischen Anwendungen auch dann zu ermöglichen, wenn die Adressen der Gegenstellen nicht direkt gegenseitig erreichbar sind.

    Die meisten Anwendungen verwenden nicht allein eine Verbindung, die von dem Surfersystem zum jeweiligen Server aufgebaut wird, sondern eine Vielzahl von unterstützenden Diensten und damit auch unterschiedlichen Protokollen. Die Richtung dieser unterstützenden Verbindungen ist dabei oft auch vom Server zum Client(Surfer).

    Erreicht einen NAT-Router ein Paket für eine umgesetze Adresse, so wird er versuchen, irgendwie den eigentlichen Empfänger zu erraten und das Paket zuzustellen. Das gilt insbesondere dann, wenn der NAT-Router keine intime Protokollkenntnis der Anwendung hat. Oft besteht keine Chance für den NAT-Router, selbst bei Kenntnis des Protokolls, den Empfänger sicher zu ermitteln. Dann wird mittels einer Heuristik der Empfänger erraten. Dies gilt insbesondere bei verschlüsselten Verbindungen und verbindungslosen Protokollen.

Quellel:

http://www.debianhowto.de/

Ein Host zum testen wäre mxpool01.ebay.com (mx1.sjc.ebay.com) [66.135.197.7] 

http://alive.znep.com/~marcs/mtu/  Path MTU Discovery and Filtering ICMP

IP-Adresse

Linux/Internet/Mail/Exim4 (last edited 2010-01-07 14:56:47 by DetlevLengsfeld)