Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
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.
Ahoj, vypozoroval jsem zajimavy problem. Mam kubuntu na domacim pc. Ten je pripojeny pres dva routery wifinou na router s UPC. Pres VPN se pripojuji do prace, kde mam verejnou IP. Pripojenim na VPNku dostanu rozsah z vnitrni site v praci. Muzu tedy primo jit na stroje ve vnitrni siti.
Ve vnitrni siti bezi jeden webovy server, ktery ma DNS adresu web.firma.cz. Ten ma tedy ip 192.168.10.20 a soucasne 188.xxx.xxx.xxx. Verejna DNS ho zna pod tou 188 IP, ale mam na routeru ve vnitrni siti i statickou DNS, kde je pod tou samou adresou jako 192.168.10.20. Takze se na nej dostanu pomoci jeho dns jmena jak z venku, tak zevnitr.
Stava se mi ale, ze kdyz jsem na vpnce a odpojim se, tak potom prestane byt ta IP prace dostupna. Prijde mi, jako by mne zabanoval budto provider upc nebo ten v praci - riomedia. Kdyz jsem zkousel nejake pingy, na vnitrni IP, vratilo se mi obcas neco jako DNS - private.rionet.cz - co to ma znamenat? Ze jsem se pokousel z vnitrni site pristupovat na rozhrani toho pripojeni a posilal jsem pakety na adresu ve vnitrni siti? Neni to nejak hlidane a kdyz prijde vice takovych paketu, tak provider tu IP zarizne? Napada mne, ze by pak mohlo zlobit to pouziti dvou DNSkovych IP. Nebo se mi nejak podela router, co mam doma? Zkousel jsem vsechno resetovat, vypinat, ale nic. Nedostanu se uz potom ani na nastaveni routeru v praci, ani na ten webovy server. Pritom z mobilu, z 3G to normalne jede. A vzdycky se to podela, kdyz jsem na VPNce a pak se odpojim a kliknu do okna, kde jsem mel otevrene HTTPS spojeni na ten webovy server.
Da se nejak odzkouset, kde se to kazi?
Ted jsem odpojeny od VPN a internet mi jede, ale do prace se nepingnu, ani nepripojim.
Směrovací tabulka v jádru pro IP Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní default 192.168.2.100 0.0.0.0 UG 0 0 0 eth0 192.168.2.0 * 255.255.255.0 U 1 0 0 eth0
Směrovací tabulka v jádru pro IP Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní default * 0.0.0.0 U 0 0 0 ppp0 188-175-XX-XXX. private.rionet. 255.255.255.255 UGH 0 0 0 eth0 192.168.2.0 * 255.255.255.0 U 1 0 0 eth0 XX.XXfirma.cz * 255.255.255.255 UH 0 0 0 ppp0Verejna ip adresa firmy byla zmenena na XX, stejne jako domena XXfirma.cz. To je domena, ktera ma A zaznam na IP adresu pripojky. Ted mne napada, nemuze tady v tom zaznamu byt ten problem? Ale v tehle fazi mi vse funguje a do firmy se pignu. Bojim se odpojit od VPNky, at si nebloknu posledni funkcni pripojeni - mobil. Ale budu se muset odpojit
Ja si to myslim taky, ze kdyz se odpojim, chvili to trva, resp. je mozne, ze treba je nekde v cache stara ip? Tzn. pro web mujweb.firma.cz je v tu chvili prirazena adresa 192.168.10.20 ale ja uz jsem ve verejne siti a ne ve VPN, takze on zacne posilat pakety s IP z rozsahu vnitrni site do rozhrani s netem.
Da se tomu nejak zabranit? Traceroute jsem zkousel a nikam se nedoroutuje. A to dokonce ani kdyz vsechno jede. Ping funguje, ale traceroute vyhazuje jenom hvezdicky.
Myslet nestačí. Musíte se tcpdumpem podívat, co vám odchází z počítače.
Cache směrovacích tabulek se automaticky zneplatní, když zmizí pravidlo, přes které packety odcházely. Tedy když ukončíte tunel.
Chybné soukromé a cílové IP adresy se řeší tak, že blokací na routeru, který už nemají opustit. Cílové zvláštními směrovacími pravidly (například ip route add unreachable 192.168.0.0/16, zdrojové firewallem (ale je to složitější, pokud se vám dělá SNAT).
Traceroute pusťte s paremetrem -I, aby použil ICMP.
petr@T400:~$ sudo traceroute -I XX.firma.cz traceroute to XX.firma.cz (188.175.XX.XXX), 30 hops max, 60 byte packets 1 * * * 2 188-175-XX-XXX.client.rionet.cz (188.175.XX.XXX) 36.692 ms 37.258 ms 37.880 msTakhle ? To je ale nejake divne, ne? Nemely by se tam objevit i ty moje routery a IPcko meho domaciho ISP? Jinak tohle je vypis, kdyz nejsem ve VPN.
tcpdump -np -I ROZHRANÍ ukáže hlavičky packetů, co tečou skrz dané síťové rozhraní, nic se nikam neukládá.
Zaměřit byste se měl na to, kterým rozhraním packety zasílané na ten nedostupný stroj odchází (VPN může mít vlastní rozhraní; nepsal jste, jaký druh VPN používáte) a jakou zdrojovou a cílovou IP adresu mají.
Packety odcházející skrze rozhraní VPN by měli mít adresy soukromé, kdežto packety tunelu by měly proudit skrze běžné síťové rozhraní a měly by mít veřejné adresy.
petr@T400:~$ sudo tcpdump -np -I eth0 tcpdump: eth0: That device doesn't support monitor mode petr@T400:~$ sudo tcpdump -np -I ppp0 tcpdump: eth0: That device doesn't support monitor mode petr@T400:~$
Tiskni
Sdílej: