Root.cz přes IPv6 se nezobrazí ve Firefoxu

[Grumpa]

Mám router Mikrotik s nastavenou IPv6 a některé weby (root.cz, freebsd.org,...) se ve Firefoxu nenačtou, ale v Chrome ano. Po zobrazení v Chrome se ukáží i ve Firefoxu.

Když použiji router TP-Link Archer C7, tak vše běží bez problému. Tam se dají zapnout nějaké autokonfigurace, takže nevidím dovnitř nastavení.

curl načte http:// bleskově, ale tam je přesměrování na https:// a tam se už zasekne. root.cz

Měl jsem Mikrotika s IPv6 několik let a vše běželo dobře. Teď jsem koupil novější model a současně přešel z WiFi providera na DSL/PPPoE.

Router je dostupný na vnější IPv6 adrese a routuje i na global IPv6 co jsou ve vnitřní síti. Konfigurace by měla být v pořádku.

Nejsem první, kdo se s tím párá: https://www.reddit.com/r/ipv6/comments/qdk8kf/firefox_cant_open_some_ipv6_websites/

Bohužel nevidím řešení. Poskytovatel taky ne, prodejce routeru taky ne.

Děkuji předem za pomoc.

[Reklama]

[M_D]

Co máš nastaveno na tom Mikrotiku pod /ipv6/nd za parametry ohlašované do LAN, zejména parametr mtu (ponížen patřičně o PPPoE záhlaví)? V kombinaci s nějakou blbostí v ipv6 firewallu (zahazující ICMPv6), tak je to dobrý způsob odstřelení provozu.

[Michal Šmucr]

Já bych to tipoval taky na MTU inzerované klientům přes RA z modemu/routeru.
V linuxu je to vidět v /proc/sys/net/ipv6/conf/<iface>/mtu
PPoE musí mít MTU 1492 a IPv6 provoz se nefragmentuje, Google servery chodí vždy, protože mají natvrdo 1280.
Na pokus můžete pak nastavit na síťovce u počítače natvrdo MTU 1492, uvidíte jestli to bude tím. A pak to případně řešit dál.

Nebo něco s DNS (udělal bych asi pár dotazů přes příkaz host s různými DNS servery). Je možné, že třeba jeden z prohlížečů používá DoH přes nějaký veřejný server jako Cloudflare, Google DNS.. atp.

Ale to jsou teď takové výstřely od boku.

[metabug]

Pro IPv6 přes PPPoE je MTU 1452 byte (1500-8-40), viz https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv6

[Michal Šmucr]

Pro IPv6 přes PPPoE je MTU 1452 byte (1500-8-40), viz https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv6

Tohle ale není délka MTU, co se posílá přes ICMPv6 RA.

Délka MTU je pro interface a o úroveň níž na linkové vrstvě L2 - tzn. s PPPoE je to 1500 (standardní délka rámce) - 8 (PPP header) = 1492 B.

A ano pak je tam nad ní L3 IP header (dalších 40 B pro IPv6) a následně na L4 typicky buď TCP (20-60 B) nebo UDP header (8 B). Tím se pak dostáváme k maximální velikost segmentu - MSS.

Jen teď rychle z hlavy. Možná když se zastaví Danny, tak dodá i odkazy na ta správná RFCčka

[Reklama]

[M_D]

Add to očekávání, že na PPPoE bude MTU1492, tak pozor na to - nemusí být. Zvláště pokud tam má Mikrotik, tak pokud při nastavování PPPoE klienta si MTU nenastavil ručně, tak má defaultně: max-mtu (integer; Default: 1460), max-mru (integer; Default: 1460)
Aktuálně platné hodnoty (které si server-klient odsouhlasili) je vidět v statusu toho PPPoE spojení jako MTU a MRU.  Pokud tam mám míň jak 1492, tak bych se i zeptal ISPíka, co max umí jeho síť a dle toho opravil. A nejlépe, zda i podporuje RFC 4638, pak i na PPPoE může být MTU 1500 - když už chceme, aby zaznělo i nějaké RFC. :-)

[Michal Šmucr]

Díky za další info a konečně i nějaké RFCčko

Já se s PPPoE v našich končinách setkával primárně na běžných xDSL připojeních CETINu a tam bylo MTU v podstatě vždycky 1492.

Uvidíme, co napíše tazatel, až si to vyzkouší.. třeba jsme úplně mimo a bude to něčím úplně jiným. Ale já jak slyším, že má někdo IPv6, servery Google chodí, ale nějaké jiné ne, tak mě vždy napadne tenhle problém jako první.

Asi i štěstí, že má router, kde se to dá ovládat. Zažil jsem i modem s routerem, co to posílal vždycky 1500 a nedalo se to nastavit. Jako workaround pak fungovalo to, že když naběhl, tak jsem se tam připojil povoleným telnetem , upravil radvd.conf a restartoval démona. Což vydrželo do dalšího restartu routeru

[jjrsk]

Vzivote sem nevidel ze by problem byl s mtu, ale opakovane sem videl, ze dotycny mel zafirewallovany icmpv6 (protoze na v4 se to tak prece dela) a pak se divil.

[Petr Krčmář]

Jenže to spolu přímo souvisí. Když se někde po cestě ztrácí ICMPv6, tak ke klientovi nedorazí paket Fragmentation needed a ten se nedozví o neprůchodné cestě, kde se mu ztrácí provoz.

Výsledkem je stav, kdy všechno padá do černé díry a vy to nevíte. Nějaký jednoduchý provoz (třeba HTTP s přesměrováním) ale projde, protože to jsou jen maličké pakety. Viz článek Velké trable s malým MTU.

[Grumpa]

Dobrý den. Děkuji za všechny odpovědi.

Připojení je Cetin/GigaNet. ISP jsem zpřístupnil Mikrotika a nic špatného tam nenašel.

V příloze posílám sníme obrazovky s interfaces list z mikrotiku, kde jsou MTU vidět. PPPoE má MTU 1480.

Na bridge, kde se provádí router advertisement v ND nebylo nastaveno nic a výpis /proc/sys/net/ipv6/conf/<iface>/mtu ukazoval 1500. Dal jsem do ND sekce tedy doporučenou hodnotu 1492. Načítání stránek se zlepšilo tak, že stránka se na poprvé nenačte, po kliknutí do adresního řádku prohlížeče a enter se načte většina a po zopakování akce se to donačte celé. Tedy pokrok, ale kousek tomu chybí :-)

ICMP ve firewallu nikdy neblokuji, naopak je to jedna z prvních povolených položek.

Podle toho jak to "funguje" ve Firefoxu to vypadá, jako by síťová komunikace nejdřív někde zabloudila a po opakování požadavku se našla. Odborněji to bohužel říct neumím. Bohužel i pro odeslání tohoto příspěvku jsem musel IPv6 vypnout...

[Michal Šmucr]

Omlouvám se, neznám přesně nastavení na Mikrotiku s PPPoE, ale klientům do sítě by se přes RA nemělo posílat delší MTU než je pak na vnějším rozhraní.
Takže jestli je na PPPoE rozhraní 1480, tak to RA upravte stejně. Nebo naopak v nastavení toho PPPoE klienta zkuste upravit na 1492, protože těch 1480 spíš vypadá jako nějaký konzervativní default v RouterOSu a ISP by mohl umět víc.
Ale možná mě někdo, kdo má víc zkušeností s Mikrotikem opraví nebo doplní.