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.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
-P PREROUTING ACCEPT -P INPUT ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A PREROUTING -d PubIP1 -i eth1 -j DNAT --to-destination 192.168.0.248 -A POSTROUTING -s 192.168.0.248 -o eth1 -j SNAT --to-source PubIP1 -A POSTROUTING -o eth1 -j SNAT --to-source PubIP2eth1 je rozhraní do internetu a má dvě veřejné adresy PubIP1 a PubIP2, vnitřní síť je 192.168.0.0/24, na stroj 192.168.0.248 se dělá IP fowarding.
Po provedení nějakých, většinou ručních úprav (s následným zapsáním pravidel do konfiguráku (u mne /etc/sysconfig/iptables)) jsem zjistil, že některá spojení do internetu nejsou NATovaná a pakety odchází s privátní IP (v tomto případě ze stroje IP=192.168.0.248 na cíl odcházely UDP pakety na dstport 5060 s jeho původní privátní adresou 192.168.0.248). Ale pakety ze stejného stroje 192.168.0.248 na jiné cíle v internetu (vč. jiného stroje s kterým se komunikovalo také přes UDP) byly překládané správně, na source adresu PubIP1. Restart iptables (včetně 'ip link set eth1 down/up') nepomohl, restart celého firewallu ano.
Zdá se, jako kdyby se nějak pamatovala předchozí spojení a pokračovalo se v nich či co. Je možné, že by např. conntrack table takhle ovlivňovala netfilter (asi jsem ji mohl zkusit flushnout pomocí conntrack, ale nenapadlo mne to a byl kvalt)?
Nebo je to způsobeno něčím jiným? Myslím, že už se mi to stalo (že jsem viděl z internet rozhraní odcházet neNATované pakety) jednou, dvakrát i v minulosti, okolnosti byly podobné (nat table i jednodušší (jen jeden SNAT), problém nastal také po nějakých mých vrtáních se v netfilter pravidlech) a řešil jsem to stejně blbě jako teď, restartem stroje.
Teď to bylo na FW s jádrem 3.19.5-100.fc20.x86_64 a iptables 1.4.19.1.
- flush všech tabulek - výmaz všech pravidel - výmaz všech uživatelem definovaných chainů - vynulování paket/byte čítačů všech chainů - nastaví politiky všech chainů na ACCEPT - provede unload kernel modulů souvisejících s netfiltrem (netuším jak moc dobře, můžu se na to mrknout večer)Takže, co může způsobit to, že navzdory SNAT pravidlu v nat POSTROUTING chainu se toto na některé pakety neaplikuje, ani po restartu firewallu (a po restartu systému je vše OK)? Mohly by to způsobit z nějakého důvodu neuloadované síťové moduly jádra?
nat se aplikují jen na pakety, které jsou (z pohledu conntracku) "NEW". Takže jestliže už máte v conntrack tabulce nějaké položky a přidáte nové pravidlo, může se stát, že se na pakety odpovídající těm stávajícím položkám neaplikuje, protože jsou "ESTABLISHED". Zkuste, jestli pomůže "conntrack -F".
Proto byl dotaz spíš teoretický - co může v běžícím systému způsobit, že po restartu iptables se jeho pravidla obecně neaplikují?
Restart/stop iptables ve Fedoře se mj. pokouší udělat rmmod x_tables, nf_nat a nf_conntrack modulů a modulů na nich závislých, měl jsem tedy za to, že tím také zaniknou všechny položky v conntrack table. Asi nejpravděpodobněji ale vypadá možnost, že se ve scriptu z nějakého důvodu nf_conntrack nepovede unloadnout, a v conntrack table zůstane info o daném spojení (neNATovaném, třeba z toho důvodu, že vzniklo během předchozího (re)startu iptables v době, kdy nat table ještě nebyla kompletní), souhlasíte? Nebo je ještě jiná možnost, jak se to může stát?
Na ten flush conntrack table jsem nevzpomněl, zkusím - jestli to zase někdy nastane.
Pokud skript opravdu unloadne všechny relevantní moduly, tak ta varianta, že conntrack položka vznikla v okně mezi natažením modulu a přidáním NAT pravidla, mi zní jako docela pravděpodobné vysvětlení. Pak by asi bylo vhodné na konec skriptu nastavujícího firewall přidat flushnutí conntracku.
Je to ale dvousečné. Dokážu si třeba představit situaci, kdy mám existující TCP spojení ven a aplikační data proudí jen směrem dovnitř (HTTP stahuje velký soubor, případně SSH spojení se spuštěným příkazem generujícím výsup). Pak se pakety zvenku budou zahazovat a zevnitř nikoho nenapadne nějaké poslat, takže spojení po nějakém čase umře (pokud bude REJECT, pak umře hned). Ono se asi celkově při návrhu toho skriptu předpokládá, že se bude spouštět při startu, ne za běhu systému, kdy už tam probíhá nějaká komunikace.
CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_ZONES=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=y CONFIG_NF_CONNTRACK_IPV4=ytj. nf_conntrack a nf_conntrack_ipv4 jsou v jádře, ne jako moduly, a tudíž conntrack table se nevyprázdní.
Zásadní je samozřejmě to, že jsem s existujícími spojeními v conntrack table a jejich ovlivňováním iptable pravidel vůbec nepočítal, moje chyba. Díky za nakopnutí!
Tiskni
Sdílej: