Dotaz: tunnelbroker.net (IPv6) s radvd

[Petr Maleček]

Přílohy:

• ipv6-ra-cli.png (96020 bytů)
• lan-br0.png (177314 bytů)
• ipv6-dev.png (125363 bytů)
• ipv6-route.png (143779 bytů)

Ahoj všem, potřeboval bych poradit, kde dělám chybu.

Mám tunel od výše uvedeného poskytovatele, nastavený na mém serveru, který je za NATem, ale v rámci DMZ, takže vše směrované na něj.

Tunel jsem nastavil podle návodu na stránkách tunnelbrokeu, takže ze serveru jako takového například google pingnu.

PING google.com(prg03s10-in-x0e.1e100.net (2a00:1450:4014:80a::200e)) 56 data bytes
64 bytes from prg03s10-in-x0e.1e100.net (2a00:1450:4014:80a::200e): icmp_seq=1 ttl=121 time=3.33 ms
64 bytes from prg03s10-in-x0e.1e100.net (2a00:1450:4014:80a::200e): icmp_seq=2 ttl=121 time=3.59 ms
64 bytes from prg03s10-in-x0e.1e100.net (2a00:1450:4014:80a::200e): icmp_seq=3 ttl=121 time=3.23 ms
64 bytes from prg03s10-in-x0e.1e100.net (2a00:1450:4014:80a::200e): icmp_seq=4 ttl=121 time=3.21 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 3.211/3.339/3.592/0.167 ms

Problém ale nastává ve chvíli, kdy nastavím radvd daemona, aby rozdával IPky v rozsahu, který mám přidělen.

Služba IP z daného rozsahu rozdává OK, ale nefunguje routování.

Síťové rozhraní na serveru má tuto vnitřní adresu:

inet6 fe80::265e:beff:fe57:f18b  prefixlen 64  scopeid 0x20<link>

Síťová zařízení v síti obdrží tuto adresu jako adresu routeru. Ovšem, nedokáží ji pingnout. V ip6tables nejsou žádná pravidla (čili nic, co by mu mělo bránit odpovědět).

Napadá vás, na co zapomínám? Postupoval jsem pomocí tohoto návodu.

V příloze přikládám obrázek IP, které dostal klient (bílé pozadí), pak snímky IP síťového rozhraní (br0), tunelového rozhraní a routy pro IPv6.

Díky

---

---

Odpovědi

[Petr Maleček]

Ještě doplním, že pokus o ping interní IPv6 adresy (br0, což je síťové rozhraní pro přístup do sítě/netu) z klientské strany končí takto:

ping6 fe80::265e:beff:fe57:f18b
PING6(56=40+8+8 bytes) fe80::83b:6bf:74d3:3ad0%en0 --> fe80::265e:beff:fe57:f18b
ping6: sendmsg: No route to host
ping6: wrote fe80::265e:beff:fe57:f18b 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::265e:beff:fe57:f18b 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::265e:beff:fe57:f18b 16 chars, ret=-1
^C
--- fe80::265e:beff:fe57:f18b ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

V rámci localhostu na serveru samozřejmě tato IPv6 pingnout jde.

[Petr Maleček]

Ví server, jak (kterým síťovým zařízením) by mohl routovat do té vnitřní sítě?

ip -6 route add 2001:470:6f:11a::/64 dev br0

Pro jistotu bych zkontroloval ip -6 route show table all; některý software (například IPSec frameworky typu StrongSwan a kdoví, možná i některý tunnel broker) má ve zvyku schovávat („svá“) routovací pravidla do nestandardních tabulek.

Mimochodem, jestli ten poskytovatel přiděluje jenom /64 rozsahy, je to dobrý důvod utíkat od něj pryč tempem gepardím. Normální poskytovatelé mají dávat /48; což je takový základ / zlatý standard. Naprosté minimum je (dejme tomu) /62. Pokud jde o /64, něco takového je dost těžko použitelné pro nasazení jiná než triviální a člověk řeší (nesmyslné) dilemma, jestli (a) nemít žádné interní routování ani víc podsítí (aby byl k dispozici celý /64 rozsah) nebo (b) zrušit podporu IPv6 pro klientská zařízení s Androidem (protože pro ně je /64 minimum).

[Petr Maleček]

Nabízí /64 i /48, mám to řekněme na 10 zařízení, tak jsem myslel, že mi /64 stačí. Jinak děkuji za vyřešení, daný příkaz můj problém vyřešil, asi jsem na tu routu nějak zapomněl

[Petr Maleček]

Tak budu muset najít asi jiného poskytovatele tunelu pro IPv6, protože třeba Seznam se nanačte korektně, chybí spousta obsahu (převázně obrázků).

Petr@Petr-MBP ~ % traceroute6 d32-a.sdn.cz
traceroute6: Warning: lb.sdn.cz has multiple addresses; using 2a02:598:a::79:195
traceroute6 to lb.sdn.cz (2a02:598:a::79:195) from 2001:470:6f:11a:d16a:9f3d:c698:6ab9, 64 hops max, 12 byte packets
 1  tunnel778912-pt.tunnel.tserv27.prg1.ipv6.he.net  2.103 ms  2.919 ms  2.013 ms
 2  tunnel778912.tunnel.tserv27.prg1.ipv6.he.net  8.054 ms  7.202 ms  7.523 ms
 3  * *^C
Petr@Petr-MBP ~ % 

Jiné weby fungují normálně :(

[czjaromir]

Já lama tak jako když už náhodou píšu něco jako html stránky tak rozuhodně neuvažuju (myslím) v ip v6. Tam bude asi někde problém.

[Peter Golis]

Web kodér nepotrebuje uvažovať v IPv6. Ale keby správca servera d32-a.sdn.cz zapol IPv6, tak by to možno aj fungovalo.

[Petr Maleček]

Ten server ale IPv6 má, jen odmítá vracet obsah, což je divné.

PING d32-a.sdn.cz(2a02:598:2::1195 (2a02:598:2::1195)) 56 data bytes
64 bytes from 2a02:598:2::1195 (2a02:598:2::1195): icmp_seq=1 ttl=59 time=3.45 ms

[Peter Golis]

Asi tá služba poskytujúca webové komponenty nepočúva na IPv6. Ale, ...

[Andrej]

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.

[Petr Maleček]

Díky za radu, já osobně používám stále iptables, ip6tables a aktuálně se tak nějak odmítám učit něco jiného, protože k tomu nemám důvod, když původní varianta naprosto vyhovuje. Teď je tu tedy jiná situace a třeba mě to donutí.

nftables jsem tedy doinstaloval a končím touto hláškou, syntax zatím neovládám, tak přikládám:

/etc/nftables.conf:10:51-56: Error: syntax error, unexpected string, expecting - or number
                type filter hook forward priority filter; policy accept;
                                                                ^^^^^^

[Hovno]

Možná to chce místo filter číslo 0. (Andrej moc pije a občas mu to takhle ujede.)

[Radek]

K čemu chceš ipv6? Když to není nativní, tak přes brokery to jde delší trasou, ím pádem horší odezvou a s nižší přenosovou rychlostí (když teda nemáš doma pod 100mbit), navíc to po cestě občas zkriplý mtu a je potřeba si to vyladit.

[Radek]

zkriplí

[Petr Maleček]

Přes klasický 6to4 je to opravdu šílené pomalé, ale tunel 6in4 od toho tunnelbrokeru rychlostně dával kolem 350Mbit, což není špatné. Šlo mi víceméně o vyzkoušení, jinak mám linku 2.5Gbit. Samozřejmě bez IPv6 přežiju.