Poslední příspěvky1
Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu
« Poslední příspěvek od Michal Šmucr kdy Dnes v 01:10:12 »O.K. tak si sám napíšu update.
Vrtalo mi to hlavou a ozkoušel jsem si to na Mikrotiku s VDSL modemem v bridge režimu (O2, Cetin).
PPPoE klient nastavený na MTU 1492, to chodilo podle předpokladu dobře.
Vyzkoušel jsem si všechny zmíněné scénáře
- Nenastavovat nic dál, nechat to na dynamické zjišťování PMTU až ke klientovi
ICMPv6 je ve výchozím nastavení RouterOS povolené, zpráva packet too big (PTB) prochází na stanice.
První spojení se nenaváže, ale vytvoří se záznam v lokální routovací tabulce s menším MTU pro hosta venku (server). Dá se v Linuxu ověřit přes ip -6 route show cache. Další spojení pak proběhne v pohodě s použitím nové MTU.
Horší pak je, jak se tohle chování projeví se standardními aplikacemi. Chrome i FF dlouho čeká na timeout s chybou, nebo se musí načítání stránky přerušit a refreshnout. Druhé spojení pak načte základní stránku, ale pak se typicky čeká znovu (další servery s reklamou, skripty, diskuzí atp.), takže zas přerušit a dát refresh. Totéž pak třeba telefon s iOSem. Prakticky nepoužitelné.
To btw. vysvětluje i to zdánlivě divné chování, co popisoval tazatel. Není to tak, že by to chodilo v konkrétním browseru a jiném ne. Pokud to zkouší nejprve v jedné aplikaci, tak se to nenačte, ale udělá se PMTU záznam a v druhé, co zkouší později, už to pak po dobu jeho platnosti záznamu chodí.
- MSS clamping
Na RouterOS jsem to naklikal v GUI pro mangle tabulku a forward chain. Případně přes konzoli něco jako:
Tohle zafunguje vcelku spolehlivě a vyřeší problémy s načítáním většiny stránek.
Nevýhoda je, že to logicky funguje jen na TCP spojení. UDP spojení to neřeší, nemají MSS field.
Takže by se muselo spoléhat na to, že ty aplikace, co UDP používají, si vyřeší reconnect po zjištění PMTU (viz předchozí způsob). Nevím například, jak to je s aktuálním použitím QUIC/HTTP3, co běží přes UDP, jaké mají servery MTU, a jestli je dobré na tenhle workaround spoléhat do budoucna.
- snížení inzerovaného MTU v RA (ND) na 1492
To samozřejmě řeší komunikaci všemi protokoly, aby to prošlo přes WAN síť, a funguje spolehlivě. Nevýhoda už tu byla předtím zmíněná, pokud spolu klienti komunikují v LAN mezi sebou po IPv6, používají také menší MTU.
Otázka je, jak velký je tohle prakticky problém.. za mě je to pořád preferovaná varianta, jak to řešit pro většinu menších sítí.
Takže - pick your poison. A víceméně mi to odpovídá na otázku, proč třeba někteří výrobci SOHO routerů/modemů, které jsem viděl, měli ve výchozím nastavení všechno naráz - bylo povolené ICMPv6, MSS clamping a ještě k tomu replikovali MTU od upstream linky v RA.
Vrtalo mi to hlavou a ozkoušel jsem si to na Mikrotiku s VDSL modemem v bridge režimu (O2, Cetin).
PPPoE klient nastavený na MTU 1492, to chodilo podle předpokladu dobře.
Vyzkoušel jsem si všechny zmíněné scénáře
- Nenastavovat nic dál, nechat to na dynamické zjišťování PMTU až ke klientovi
ICMPv6 je ve výchozím nastavení RouterOS povolené, zpráva packet too big (PTB) prochází na stanice.
První spojení se nenaváže, ale vytvoří se záznam v lokální routovací tabulce s menším MTU pro hosta venku (server). Dá se v Linuxu ověřit přes ip -6 route show cache. Další spojení pak proběhne v pohodě s použitím nové MTU.
Horší pak je, jak se tohle chování projeví se standardními aplikacemi. Chrome i FF dlouho čeká na timeout s chybou, nebo se musí načítání stránky přerušit a refreshnout. Druhé spojení pak načte základní stránku, ale pak se typicky čeká znovu (další servery s reklamou, skripty, diskuzí atp.), takže zas přerušit a dát refresh. Totéž pak třeba telefon s iOSem. Prakticky nepoužitelné.
To btw. vysvětluje i to zdánlivě divné chování, co popisoval tazatel. Není to tak, že by to chodilo v konkrétním browseru a jiném ne. Pokud to zkouší nejprve v jedné aplikaci, tak se to nenačte, ale udělá se PMTU záznam a v druhé, co zkouší později, už to pak po dobu jeho platnosti záznamu chodí.
- MSS clamping
Na RouterOS jsem to naklikal v GUI pro mangle tabulku a forward chain. Případně přes konzoli něco jako:
Kód: [Vybrat]
/ipv6 firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes
protocol=tcp tcp-flags=synTohle zafunguje vcelku spolehlivě a vyřeší problémy s načítáním většiny stránek.
Nevýhoda je, že to logicky funguje jen na TCP spojení. UDP spojení to neřeší, nemají MSS field.
Takže by se muselo spoléhat na to, že ty aplikace, co UDP používají, si vyřeší reconnect po zjištění PMTU (viz předchozí způsob). Nevím například, jak to je s aktuálním použitím QUIC/HTTP3, co běží přes UDP, jaké mají servery MTU, a jestli je dobré na tenhle workaround spoléhat do budoucna.
- snížení inzerovaného MTU v RA (ND) na 1492
To samozřejmě řeší komunikaci všemi protokoly, aby to prošlo přes WAN síť, a funguje spolehlivě. Nevýhoda už tu byla předtím zmíněná, pokud spolu klienti komunikují v LAN mezi sebou po IPv6, používají také menší MTU.
Otázka je, jak velký je tohle prakticky problém.. za mě je to pořád preferovaná varianta, jak to řešit pro většinu menších sítí.
Takže - pick your poison. A víceméně mi to odpovídá na otázku, proč třeba někteří výrobci SOHO routerů/modemů, které jsem viděl, měli ve výchozím nastavení všechno naráz - bylo povolené ICMPv6, MSS clamping a ještě k tomu replikovali MTU od upstream linky v RA.
