Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Bylo vydáno do češtiny přeložené číslo 717 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
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
Řešení dotazu:
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.
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@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ě :(
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
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
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).
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./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
.
/etc/nftables.conf:10:51-56: Error: syntax error, unexpected string, expecting - or number
type filter hook forward priority filter; policy accept;
^^^^^^
Tiskni Sdílej: