Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
A -- VPN -- B -- VPN -- Cnebo takto,
-- A
VPN -- B
-- C
Veta "stroje z jiných sítí nevidím" znamna co presne? Routing mas v poradku? Traceroute vypada jak? Ping se dostane kam az? Pakety jsou zahazovane kde presne?
Vypadá to, že se OpenVPN naučí, kde laptop je a už „nepustí“.VPN ma prece session, ktera se s odpojenim rozpadne. Log VPN klienta vypada jak? Nema OS jen problem s ostranenim docasnych cest z routing tabulky?
Tazatal zmiňuje TAP rozhraní což by snad mělo být propojení ekvivalentní bridge a nikoli routeru (TUN)?
Přesně tak. Jinak by to ani nedávalo smyslu (cílem je, aby zůstaly zachovány IP adresy a laptop byl dosažitelný na své IP adrese nezávisle na tom, kde se nachází - což logicky za pomoci TUN nejde...). Mimoto tam jede VOIP, takže stejně jiná volba není reálná...
Schéma propojení by neškodilo.
sice se nezdá, že by na tom tak záleželo, ale tady to je:
-- router/klient - síť B
síť A - router/server -- VPN --
-- router/klient - síť C
Problém ale nastává při jakémkoliv přenosu laptopu z jakékoliv sítě A,B,C do sítě jiné.
VPN ma prece session, ktera se s odpojenim rozpadne.Jaké odpojení? Ty sítě jsou připojeny pořád, jenom se mezi nimi přenáší laptop.
Log VPN klienta vypada jak?Co by tě konkrétně zajímalo?
Nema OS jen problem s ostranenim docasnych cest z routing tabulky?Ale to s routováním nemá nic společného, jasně píšu, že se jedná o TAP, nikoliv TUN. (Spíš se jedná o jakousi vnitřní "ARP" tabulku OpenVPN, podle které OpenVPN ví, kdy má v bridgi směřovat packety pro tu či onu MAC adresu do té, či které sítě...)
Skriptem, po připojení do sítě restartovat službu ...
koukni do (pro inspiraci) /etc/network/if-up.d
Když se noteboku před připojením do druhé sítě přepíše MAC u adaptéru na jinou, tak může s ostatními sítěmi komunikovat úspěšně (bez restartu OpenVPN)?Hm, no to by asi šlo, ale je to teda dost rovnák na vohejbák... Jestli nebude jednodušší, abych se nakonec povrtal ve zdrojácích OpenVPN
Jak bys řešil, aby laptop automaticky rozeznal, ve které síti se nachází a podle toho nastavil MAC? Momentálně používám NetworkManager kvůli uživatelskému komfortu v jiných sítích, nedovedu si moc představit, že by ho šlo jednoduše k tomu ohnout...
Ve společné síti je jediný (nezávislý) DHCP server?Ne, každá síť má vlastní, DHCP packety na TAP rozhraní blokuji přes ebtables.
Ne, každá síť má vlastní, DHCP packety na TAP rozhraní blokuji přes ebtables.
Obávám se, že to je příčina.
Když stroj rozesílá ethernetové rámce, bridge po cestě se učí, na které lince viděly jakou zdrojovou adresu. Když pak mají přeposlat rámce učený pro ni, tak aby se ušetřilo, tak přepošlou jen tu zapamatovanou linku.
Když stroj přenesete, tak bridge se magicky nedozví, že mají naučenou informaci zahodit. Buďto se čeká na vypršení časového limitu, nebo musí danému bridgi projít pod rukama rámec z nové linky.
Kdybyste neblokovat DHCP dotazy, tak stroj po připojení pošle broadcastový dotaz (pozor na úsporné DHCP klienty, které začínají unicastovým prodloužením staré adresy), který se rozleze po celé síti, a všechny bridge se tak naučí nové umístění. Ve vašem případě se ale tak stane jen v oblasti omezené ebtables.
Je třeba si také uvědomit, že OpenVPN, také nějak implementuje bridge. Jestli ovšem se chová jako úsporný switch, nebo jako broadcastující hub, o tom dokumentace mlčí.
Napadla mne i možnost zda nemůže jít o dlouhý timeout MAC záznamů v LAN switchích, ale to nejde dohromady s uvedeným řešením problému pomocí restartu OpenVPN serveru. Leda že by při restartu OpenVPN došlo k dočasné deaktivaci síťového rozhraní a jeho LAN portu ve switchi s navázanou invalidací záznamů MAC. V tom to asi nebude.
Chtělo by to na síťových rozhraních fyzických/virtuálních trasovat ARP atd. Kdo poslední to ignoruje(zahodí).
Ano, ARP používá broadcast. (Doteď jsme si mohli myslet, že máte IPv6, kde se na to používá multicast.) Ježe my nevíme, co s tím laptopem děláte. Třeba ho uspíte a spánek (asi chybně) se nezapočte do životnosti záznamů. Třeba jste narazil na jinou chybu v Linuxu. Třeba laptop mezi tím vůbec nemá potřebu komunikovat, takže se žádný ARP packet nevyšle.
Každopádně si budete muset sednout s tcpdumpem na jednotlivých linkách a zjistit, kde se vám rámce ztrácejí, či kam jinam tečou. A začít opravdu můžete s ARP. Nástroj arping znáte?
Tak si po presune pozri, kto ma kde nacachovanu tvoju MAC adresu.Kde bych se měl podle tebe podívat?
Mozno by pomohlo skratit aging na bridgoch.Ten nepřesáhne 300 sekund, můj problém trvá v řádu dní, takže tím to nebude.
Tiskni
Sdílej: