Administrace komentářů

Tak tohle bych zase hned z kraje nesváděl na poskytovatele.

Problém je zpravidla v MTU 1480. Za to (tunelový) poskytovatel nemůže. To chce buď mít nativní IPv6 s MTU 1500 a pak všechno jde, jak má, nebo u tunelu zkusit drobný trik pro případy, že některé stroje po cestě mají problém s ICMPv6 a/nebo s různými detaily NDP. Typický symptom bývá, že

• relativně malá data (která se vejdou do paketu a/nebo jdou ze serverů s ultrakonzervativně malým MSS) fungují zdánlivě v pohodě, zatímco
• velká data, velmi často obrázky z obrázkových serverů, které chtějí využít každý byte standardní MTU / MSS, buď nepřijdou vůbec, nebo přijdou s obrovskými prodlevami, jako by to jeden tahal krávě z prdele.

V té souvislosti bych se ještě pozastavil nad touto částí původního dotazu:

V ip6tables nejsou žádná pravidla (čili nic, co by mu mělo bránit odpovědět).

1. Nic takového dnes neexistuje. ip6tables se používaly v minulém desetiletí nejpozději. V tomto desetiletí máme nftables (příkaz nft). A právě tam by občas nějaká pravidla měla být.
2. Zkusil bych, jen tak pro zajímavost, dát do /etc/nftables.conf něco jako

   table inet filter {
   	chain forward {
   		type filter hook forward priority filter; policy accept;
   		oif "he-ipv6" tcp flags syn tcp option maxseg size set rt mtu
   	}
   }
   

   a pak bych na to zavolat nftables -f /etc/nftables.conf.

Ještě další otázka je, jestli je vůbec 1480 správné číslo. 1480 je obvykle u 6to4. Brokeři s jinými (složitějšími) protokoly můžou mít všemožné různé hodnoty typu 1460, 1420, …, 1280 atd. atp. Doporučuji dohledat MTU v dokumentaci poskytovatele tunelu. Taky není od věci trochu experimentovat s ping -s.