Ein Phänomen ist geblieben: wireguard-Verbindungen bei 1&1 werden über die Zeit unbrauchbar.
Irgendwie ändert sich die MTU, aber Path MTU Discovery kann das nicht kompensieren, so dass zwar ping mit kleinen Paketen weiterhin geht, aber tcp z.B. ssh hängen bleibt.
thomas@witz:~> ping -M do -s 1232 fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970
PING fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970(fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970) 1232 Datenbytes
1240 Bytes von fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970: icmp_seq=1 ttl=62 Zeit=45.1 ms
1240 Bytes von fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970: icmp_seq=2 ttl=62 Zeit=43.4 ms
1240 Bytes von fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970: icmp_seq=3 ttl=62 Zeit=47.0 ms
1240 Bytes von fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970: icmp_seq=4 ttl=62 Zeit=46.2 ms
^C
--- fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970 ping-Statistik ---
4 Pakete übertragen, 4 empfangen, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 43.415/45.429/46.993/1.335 ms
thomas@witz:~>
thomas@witz:~> ping -M do -s 1233 fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970
PING fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970(fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970) 1233 Datenbytes
^C
--- fd18:c4a8:f1ea:0:da3a:ddff:fe97:e970 ping-Statistik ---
6 Pakete übertragen, 0 empfangen, 100% packet loss, time 5115ms
thomas@witz:~>
normal ist, dass ping -M do -s 1314
geht