Tja, da hab ich doch gleich mal probieren müssen, was da dran ist und habe mal Pings losgeschickt:
muenster:~# ping -s 1400 www.strato.de PING www.strato.de (192.67.198.33): 1400 data bytes 1408 bytes from 192.67.198.33: icmp_seq=0 ttl=245 time=159.6 ms 1408 bytes from 192.67.198.33: icmpseq=1 ttl=245 time=157.3 ms 1408 bytes from 192.67.198.33: icmpseq=2 ttl=245 time=327.5 ms 1408 bytes from 192.67.198.33: icmpseq=3 ttl=245 time=160.3 ms 1408 bytes from 192.67.198.33: icmpseq=4 ttl=245 time=159.0 ms --- www.strato.de ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 157.3/192.7/327.5 ms muenster:~# ping -s 1500 www.strato.de PING www.strato.de (192.67.198.33): 1500 data bytes --- www.strato.de ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss
Was passiert hier? Ich schicke Pakete mit 1400 Byte und 1500 Byte Länge. Die mit 1500 Byte werden an unserem Router - ein Router der Telekom mit einer DSL-Festanbindung - sauber fragmentiert und eben als Fragmente verschickt:
goggle# tcpdump -i ppp0 icmp tcpdump: listening on ppp0 09:29:01.223186 62.153.201.130 > 62.226.72.1: (frag 33019:28@1480) 09:29:01.316521 62.153.201.130 > 62.226.72.1: icmp: echo request (frag 33019:1472@0+) 09:29:01.316707 62.153.201.130 > 62.226.72.1: (frag 33019:8@1472+) 09:29:01.317017 62.226.72.1 > 62.153.201.130: (frag 14273:36@1472) 09:29:01.317148 62.226.72.1 > 62.153.201.130: icmp: echo reply (frag 14273:1472@0+)
So sieht das zum Beispiel aus wenn ich meine Kiste zu Hause anpinge. Worauf deutet das hin? Ich würde mal darauf tippen das Strato eine Firewallstrategie hat, bei der transparente Firewalls vor den Strato-Servern stehen. Und da gehen wohl Fragmente verloren. Möglicherweise machen die das, weil TCP/IP-Fragmente bei Angriffen gerne benutzt werden, weil Fragmente mit falschen Headerdaten gerne TCP/IP-Stacks zum Absturz bringen. Trotzdem würde ich mal sagen das das ein klarer Konfigurationsfehler bei Strato ist. Zumindestens riecht es stark danach ...