Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
wan: eth0 - 192.168.14.50/24 wan: eth1.100 - 10.10.10.50/24 lan: eth2 - 172.16.123.1/24 lan: eth2.200 - 172.16.200.1/24 gw: via 10.10.10.1 dev eth1.100z oboch wan sa da dostat na internet (ak na routri zmenim default gw na 192.168.14.1, tak to funguje). klienti su nat-ovani a vsetko funguje ok (maju pristup do internetu). co ale potrebujem je, aby klienti zo siete 172.16.200.0/24 (eth2.200) boli routovani do internetu cez wan eth0 (brana 192.168.14.1), teda nie cez default gw 10.10.10.1. pridal som:
# echo 100 vlan200 >> /etc/iproute2/rt_tables # ip rule add from 172.16.200.0/24 table vlan200 # ip route add default via 192.168.14.1 table vlan200funguje to, teda klient zo siete 172.16.200.0/24 je routovany cez eth0, ale len do chvile, kym ho z routra nepingnem (alebo ked z klienta pingnem router). v tom momente sa klient nevie dostat na internet a router-klient sa navzajom nevedia pingnut. v dumpe vidim arp requesty, kde klient zistuje mac adresu routra, resp.: - ked pingam z routera klienta alebo naopak, tak na routri vidim, ze klient sa snazi zistit mac adresu routra, ALE router mu neodpovie - ked na routri z arp tabulky vymazem klientsku IP adresu a potom z routra pingnem klienta, tak router zisti mac adresu klienta, posle icmp echo request, echo reply dorazi az na router, ALE ping hlasi 100% stratu a klient po par sekundach strati z arp tabulky zaznam pre IP routera - ked na routri z arp tabulky vymazem klientsku IP adresu a potom z klienta pingnem router, tak na routri vidim arp request z klienta, ALE router mu neodpovie vdaka.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
vlan200 zduplikovat routu pro 172.16.200.0/24 a 192.168.14.0/24 (automaticky se vytvářejí jen v tabulce main, na kterou ale pro pakety se zdrojovou adresou ze 172.16.200.0/24 vůbec nedojde). A pro jistotu bych ještě zkontroloval, že je vypnutý RP filter.
ip route add 172.16.200.0/24 src 172.16.200.1 dev eth2.200 table vlan200sa to rozbehlo. ak tomu spravne rozumiem, tak prikaz
ip rule add from 172.16.200.0/24 table vlan200sposobi, ze ak pride nieco zo siete 172.16.200.0/24, tak sa pozrie do tabulky vlan200? a v nej bola definovana len default gw a teda router vlastne nevedel, kam ma poslat odpoved? nemal potom pokracovat dalsimi tabulka, napr. main, kde je ta ista routa a pouzit ju? teraz mi aj dava zmysel, preco ping do netu z klienta fungoval - na L2 vrstve komunikacia fungovala, ciel bol na internete, tak router paket poslal cez default routu podla tabulky vlan200. ale zahada je, preco to prestalo fungovat po pingnuti klienta-routra medzi sebou a klient uz router na L2 vrstv nevidel.
ak tomu spravne rozumiem, tak prikazip rule add from 172.16.200.0/24 table vlan200sposobi, ze ak pride nieco zo siete 172.16.200.0/24, tak sa pozrie do tabulky vlan200?
Ano. Pravidla se vyhodnocují v pořadí podle priority (to je to číslo, které "ip rule show" píše na začátku řádku), dokud se podle některého nerozhodne, co s paketem.
a v nej bola definovana len default gw a teda router vlastne nevedel, kam ma poslat odpoved?
Problém je právě v tom, že věděl: protože tam byla jenom default route, tak se všechno routovalo podle ní (včetně toho, o co by se jinak postaraly automaticky vytvořené položky v tabulce main).
nemal potom pokracovat dalsimi tabulka, napr. main, kde je ta ista routa a pouzit ju?
Pouze v případě, že by v tabulce vlan200 žádnou vyhovující routu nenašel (nebo by ta nejlepší byla typu throw), pokračoval by dalším pravidlem. To, že routa s delším prefixem má přednost, platí jen v rámci jedné tabulky, ne mezi tabulkami.
Problém je právě v tom, že věděl: protože tam byla jenom default route, tak se všechno routovalo podle nítak by som zo siete 172.16.200.0/24 nemal pingat ani 10.10.10.0/24, pretoze v tabulke vlan200 ma momentalne routovanie pre siet 172.16.200.0/24 a default gw.
Tiskni
Sdílej:
