Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Společnost Škoda Auto zveřejnila na Printables bezplatné 3D modely příslušenství do svých vozů (držáky na nápoje, pomůcky pro vedení kabelů, mincovníky, háčky na USB kabely a čepice pro kapsy na zadních stranách opěradel sedadel, držáky na telefony a úchyty pro horní upevnění bezpečnostních pásů).
ip tunnel add 6to4 mode sit remote any local [VerejnaIP] ip link set 6to4 up ip addr add 2002:[VerejnaIP-HEX]::1/16 dev 6to4 ip -6 route add default via ::192.88.99.1 dev 6to4Bohužel ale nefunguje, ping6 na cokoliv nejde. Zkoušel jsem i zadat
local 192.168.1.2 (diskuse zde). Pokud tuto část vynechám (v některých návodech není), píše mi první příkaz ioctl: No buffer space available.
Jak zprovoznit 6to4 za NATem? Pokud by to nešlo, v odkazované diskusi někdo napsal, že by šla adresa proroutovat do vnitřní sítě. Toto příliš nechápu, jak by se to na modemu udělalo?
Řešení dotazu:
ping6 např. na ipv6.google.com routeru funguje a pomocí radvd se přiřazují počítačům adresy. Na těchto počítačích také jde ping6 ipv6.google.com. Bohužel ale weby stále ukazují, že IPv6 nemám. A ping6 na některé nefunguje. Jestli jsem si dobře všiml, ping6 nefunguje na adresy začínající 2001:. Kde může být problém?
Konfigurace sítě na OpenWRT:
config 'interface' 'wan'
option 'ifname' 'eth0.1'
option 'peerdns' '0'
option 'proto' 'pppoe'
option 'username' 'o2'
option 'password' 'o2'
option 'ipv6' '1'
option 'defaultroute' '1'
config 'interface' '6to4'
option 'proto' '6to4'
Konfigurace radvd:
interface br-lan
{
MaxRtrAdvInterval 30;
IgnoreIfMissing on;
AdvSendAdvert on;
prefix 0:0:0:1::/64
{
AdvValidLifetime 300;
AdvPreferredLifetime 120;
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface pppoe-wan;
};
};
root@pikalek-router:~# ip -6 route
::/96 via :: dev 6to4-6to4 metric 256 mtu 1280 advmss 1220 hoplimit 0
2002:xxxx:xxxx:1::/64 dev br-lan proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
2002::/16 dev 6to4-6to4 proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 0
2000::/3 via ::192.88.99.1 dev 6to4-6to4 metric 1 mtu 1280 advmss 1220 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev br-lan proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0.0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0.1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev 6to4-6to4 proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 0
root@pikalek-router:~# ifconfig 6to4-6to4
6to4-6to4 Link encap:IPv6-in-IPv4
inet6 addr: 2002:xxxx:xxxx::1/16 Scope:Global
inet6 addr: ::xx.xxx.xxx.xxx/128 Scope:Compat
UP RUNNING NOARP MTU:1280 Metric:1
RX packets:264 errors:0 dropped:0 overruns:0 frame:0
TX packets:309 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:180966 (176.7 KiB) TX bytes:34809 (33.9 KiB)
tpikalek-desk:/home/tpikalek # ip -6 route
2002:53d0:32c1:1::/64 dev eth0 proto kernel metric 256 expires 294sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via fe80::e046:bcff:feb2:b232 dev eth0 proto kernel metric 1024 expires 84sec mtu 1500 advmss 1440 hoplimit 64
tpikalek-desk:/home/tpikalek # ifconfig eth0
eth0 Link encap:Ethernet HWadr xx:xx:xx:xx:xx:xx
inet adr:192.168.2.11 Všesměr:192.168.2.255 Maska:255.255.255.0
inet6-adr: 2002:xxxx:xxxx:1:219:66ff:feea:3f9c/64 Rozsah:Globál
inet6-adr: fe80::219:66ff:feea:3f9c/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:15473 errors:0 dropped:0 overruns:0 frame:0
TX packets:16146 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 délka odchozí fronty:1000
RX bytes:10020760 (9.5 Mb) TX bytes:2071360 (1.9 Mb)
Přerušení:42 Vstupně/Výstupní port:0x4000
Směrovací tabulka vypadá dobře. (Přesvědčit se můžete příkazem ip route get CÍLOVÁ_ADRESA.) Navíc vám fungují i jiné rozsahy.
Spíš bych viděl chybu ve firewallu. Propouštítě v IPv4 řetězci INPUT všechny packety protokolu IPv6? Díval jste se tcpdumpem, jestli odchozí požadavky ICMP echo skutečně odcházejí tunelem a jestli vám odpovědi přicházejí?
Nakonec místo anycastové brány můžete zkusit nějakou unicastovou adresu, čímž můžete vyloučit chybu v odchozím směru. (Na konci tohoto zápisku jsou nějaké a odkazy na další seznamy.)
Samozřejmě chybu v CZ.NIC vyloučit nemohu, nicméně mám dojem, že jejich bránu momentálně používám, a vše mi funguje.
Tiskni
Sdílej: