Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
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: