Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
Úřad pro ochranu hospodářské soutěže zahajuje sektorové šetření v oblasti mobilních telekomunikačních služeb poskytovaných domácnostem v České republice. Z poznatků získaných na základě prvotní analýzy provedené ve spolupráci s Českým telekomunikačním úřadem (ČTÚ) ÚOHS zjistil, že vzájemné vztahy mezi operátory je zapotřebí detailněji prověřit kvůli možné nefunkčnosti některých aspektů konkurence na trzích, na nichž roste tržní podíl klíčových hráčů a naopak klesá význam nezávislých virtuálních operátorů.
Různé audity bezpečnostních systémů pařížského muzea Louvre odhalily závažné problémy v oblasti kybernetické bezpečnosti a tyto problémy přetrvávaly déle než deset let. Jeden z těchto auditů, který v roce 2014 provedla francouzská národní agentura pro kybernetickou bezpečnost, například ukázal, že heslo do kamerového systému muzea bylo „Louvre“. 😀
Z upstreamu GNOME Mutter byl zcela odstraněn backend X11. GNOME 50 tedy poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
Byl publikován plán na odstranění XSLT z webových prohlížečů Chrome a Chromium. S odstraněním XSLT souhlasí také vývojáři Firefoxu a WebKit. Důvodem jsou bezpečnostní rizika a klesající využití v moderním webovém vývoji.
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.3.0. Přehled novinek v poznámkách k vydání.
Organizace Open Container Initiative (OCI) (Wikipedie), projekt nadace Linux Foundation, vydala Runtime Specification 1.3 (pdf), tj. novou verzi specifikace kontejnerového běhového prostředí. Hlavní novinkou je podpora FreeBSD.
Nový open source router Turris Omnia NG je v prodeji. Aktuálně na Allegro, Alternetivo, Discomp, i4wifi a WiFiShop.
addr: 2002:4e6c:6cbb::1/16
Moje veřejka je 78.108.108.187, defaultní routa pro IPv6 je nastavena:
default via ::192.88.99.1 dev sit0 metric 1024
Router normálně překládá DNS adresy, i rozdává adresy počítačům v síti (přes radvd), ale ping neprochází, data netečou (ani z routeru, ani z PC v síti).
Ping (přes IPv4) na 192.88.99.1 funguje, ale přes IPv6 už ne.
ping6 ::192.88.99.1
PING ::192.88.99.1 (::192.88.99.1): 56 data bytes
^C
--- ::192.88.99.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Stejně tak jakákoli jiná adresa:
ping6 ipv6.abclinuxu.cz
PING ipv6.abclinuxu.cz (2a03:b780:1:4:216:3eff:fe00:a37): 56 data bytes
^C
--- ipv6.abclinuxu.cz ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Nenapadá někoho, kde by mohl být problém?
Jak jsem psal, na serveru kde mám stejnou konfiguraci (jen jinou veřejnou IPv4, tudíž i blok IPv6) vše funguje bezvadně.
Jinak na firewallu mám protokol 41 povolen.
Díky za případné rady!
PING 2002:4e6c:6cbb::1(2002:4e6c:6cbb::1) 56 data bytes From 2a00:1238:0:ff04::1 icmp_seq=1 Destination unreachable: No route From 2a00:1238:0:ff04::1 icmp_seq=2 Destination unreachable: No route From 2a00:1238:0:ff04::1 icmp_seq=3 Destination unreachable: No route From 2a00:1238:0:ff04::1 icmp_seq=4 Destination unreachable: No route From 2a00:1238:0:ff04::1 icmp_seq=5 Destination unreachable: No route PING info.nix.cz(info.nix.cz) 56 data bytes 64 bytes from info.nix.cz: icmp_seq=1 ttl=59 time=4.17 ms 64 bytes from info.nix.cz: icmp_seq=2 ttl=59 time=5.22 ms 64 bytes from info.nix.cz: icmp_seq=3 ttl=59 time=9.49 ms
2002:51c9:387e::
Je to můj server (10 metrů od routeru, stejná linka internetu, jen jiná veřejka).
PING 2002:4e6c:6cbb::1(2002:4e6c:6cbb::1) 56 data bytes 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=1 ttl=57 time=4.08 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=2 ttl=57 time=4.10 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=3 ttl=57 time=3.99 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=4 ttl=57 time=3.98 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=5 ttl=57 time=3.92 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=6 ttl=57 time=3.94 ms 64 bytes from 2002:4e6c:6cbb::1: icmp_seq=7 ttl=57 time=3.97 ms
Potvrzuji, že ze 6to4 je ten stroj dostupný. Takže protokol 41 mu obecně prochází. Jestli mu funguje i ping na 192.88.99.1, tak i čtyřkový anycast má správně směrovaný.
Takhle to vypadá, že jeho 6to4 bráně nefunguje nativní IPv6. Doporučuji pomocí IPv6 traceroute z jeho stroje zjistit, kam až se dostane, aby lokalizoval problém. Z rovna tak může pomocí různých looking glasses (například) vyzkoušet, jestli mu na stroj přichází dotazy z nativního IPv6, případně z který autonomních systémů mu to nefunguje.
Já mám poslední dobou zkušenost, že ze 6to4 není dostupné www.potaroo.net, kam si web APNICu chytře umístil měřící skripty, a podle všeho je to problém někde blízko serveru v Austrálii.
Takhle to vypadá, že jeho 6to4 bráně nefunguje nativní IPv6.To by zřejmě neodpovídala na IPv6 pingy, viz níže.
I brána může být jednosměrná a odpověď může jít jinou cestou.
Zkoušel jste trasovat (pomocí TTL)? Mně to funguje příkladně. Při TTL 6 dostanu odpověď z anycastové brány:
root@album:~ # ping6 -n ::192.88.99.1 -c 1 -t 6 PING ::192.88.99.1(::192.88.99.1) 56 data bytes 64 bytes from ::192.88.99.1: icmp_seq=1 ttl=63 time=24.2 ms
a na svém routeru vidím:
16:55:39.061325 IP 94.113.216.134 > 192.88.99.1: IP6 2002:5e71:d886:1:5246:5dff:fe8e:a186 > ::192.88.99.1: ICMP6, echo request, seq 1, length 64 16:55:39.073804 IP 192.88.99.1 > 94.113.216.134: IP6 ::192.88.99.1 > 2002:5e71:d886:1:5246:5dff:fe8e:a186: ICMP6, echo reply, seq 1, length 64
Když totéž zkusím s TTL o jedno nižší, tak na routeru vidím chybovou ICMPv4 zprávu od CZ.NICu:
16:57:55.405773 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
94.113.216.134 > 192.88.99.1: IP6 (hlim 4, next-header ICMPv6 (58) payload length: 64) 2002:5e71:d886:1:5246:5dff:fe8e:a186 > ::192.88.99.1: [icmp6 sum ok] ICMP6, echo request, seq 1
16:57:55.434202 IP (tos 0x0, ttl 252, id 32206, offset 0, flags [none], proto ICMP (1), length 96)
91.210.16.3 > 94.113.216.134: ICMP time exceeded in-transit, length 76
IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
94.113.216.134 > 192.88.99.1: IP6 (hlim 4, next-header ICMPv6 (58) payload length: 64) 2002:5e71:d886:1:5246:5dff:fe8e:a186 > ::192.88.99.1: ICMP6, echo request, seq 1
V mém případě mám router pět hopů od brány CZ.NICu a další skok je na pracovní stanici, odkud jsem pouštěl ping.
Takto můžete zjistit, jestli se vám packety dostanou na bránu.
Ještě můžete zkusit místo anycastové brány nějakou konkrétní. Například jednu dobu jsem používal britskou 85.116.1.22. (Nevím, jestli ještě funguje.) Tak si můžete otestovat příchozí směr. (I když to jste už mohl udělat pomocí looking glass, co jsem zmiňoval dříve.)
PING 2002:4e6c:6cbb::2(2002:4e6c:6cbb::2) 56 data bytes From 2002:4e6c:6cbb::1 icmp_seq=1 Time exceeded: Hop limit From 2002:4e6c:6cbb::1 icmp_seq=2 Time exceeded: Hop limit From 2002:4e6c:6cbb::1 icmp_seq=3 Time exceeded: Hop limit From 2002:4e6c:6cbb::1 icmp_seq=4 Time exceeded: Hop limit From 2002:4e6c:6cbb::1 icmp_seq=5 Time exceeded: Hop limitPřekročený hop limit obvykle znamená cyklení.
2002:4e6c:6cbb::2 je fakt divná, tu nikde definovanou nemám.
Tiskni
Sdílej: