OCCT3D (Open CASCADE Technology) Open Source 8.0 bylo vydáno. OCCT3D (Wikipedie, GitHub) je objektově orientovaná knihovna pro 3D CAD, CAM nebo CAE. Používá se například v softwarech FreeCAD a KiCad.
Ve FreeBSD byla nalezena a již opravena 21letá zranitelnost CVE-2026-42511 v dhclient. Jedná se o vzdálené spuštění kódu (RCE). Útočník mající pod správou DHCP server může získat plnou kontrolu nad systémem FreeBSD pouze jeho připojením k místní síti.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.3. Současně oznámila, že nadcházející větší vydání 24.04-2.0 bude mít modernější webový prohlížeč.
Ploopy po DIY trackballech či sluchátkách představuje nový externí DIY trackpoint se čtyřmi tlačítky Bean. Obsahuje snímač Texas Instruments TMAG5273, spínače Omron D2LS-21 a řadič RP2040, používá firmware QMK. Schémata jsou na GitHubu; sadu lze předobjednat za 69 kanadských dolarů (bez dopravy a DPH).
Mozilla před dvěma týdny na svém blogu oznámila, že díky Claude Mythos Preview bylo ve Firefoxu nalezeno a opraveno 271 bezpečnostních chyb. Včera vyšel na Mozilla Hacks článek s podrobnějšími informacemi. Z 271 bezpečnostních chyb mělo 180 chyb vysokou závažnost, 80 chyb střední závažnost a 11 chyb nízkou závažnost. Celkově bylo v dubnu ve Firefoxu opraveno 423 bezpečnostních chyb. Čísla CVE nemusí být přiřazována jednotlivým chybám. CVE-2026-6784 například představuje 154 bezpečnostních chyb.
Před týdnem zranitelnost Copy Fail. Dnes zranitelnost Dirty Frag. Běžný uživatel může na Linuxu získat práva roota (lokální eskalaci práv). Na většině linuxových distribucí vydaných od roku 2017. Aktuálně bez oficiální záplaty a CVE čísla [oss-security mailing list].
Ačkoli je papež Lev XIV. hlavou katolické církve a stojí v čele více než miliardy věřících po celém světě, také on někdy řeší všední potíže. A kdo v životě neměl problémy se zákaznickou linkou? Krátce poté, co nastoupil do úřadu, musel papež se svou bankou řešit změnu údajů. Operátorka ale nechtěla uvěřit, s kým mluví, a Svatému otci zavěsila.
Incus, komunitní fork nástroje pro správu kontejnerů LXD, byl vydán ve verzi 7.0 LTS (YouTube). Stejně tak související LXC a LXCFS.
Google Chrome 148 byl prohlášen za stabilní. Nejnovější stabilní verze 148.0.7778.96 přináší řadu novinek z hlediska uživatelů i vývojářů. Vypíchnout lze Prompt API (demo) pro přímý přístup k AI v zařízení. Podrobný přehled v poznámkách k vydání. Opraveno bylo 127 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
inet addr:172.16.26.62 Bcast:172.16.26.255 Mask:255.255.255.0 GW: 172.16.26.1
Tomuto připojení jsem nastavil metriku na 1.
U druhého (PF) máme IP:
inet addr:10.109.13.146 Bcast:10.109.13.255 Mask:255.255.255.128 GW 10.109.13.129
Tato IP je jen SNATovaná veřejná UP 81.201.***.** a metriku jsem nastavil na 5.
Můj problém je v tom, že když se pokouším přistupovat na server z venčí (na druhé připojení), tak se na něj nedostanu.
Když přistupuji na to první, tak na to se dostanu.
Dokonce když pingám z jednotlivých zařízení, tak to druhé prostě nefunguje. Stačí ale odebrat defaultní routu prvního a začne fungovat druhé.
Viz:
root@test:~# ping -I eth1 www.seznam.cz
PING www.seznam.cz (77.75.72.3) from 10.109.13.146 eth1: 56(84) bytes of data.
^C
--- www.seznam.cz ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
root@test:~# ping -I eth2 www.seznam.cz
PING www.seznam.cz (77.75.72.3) from 172.16.26.62 eth2: 56(84) bytes of data.
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=1 ttl=246 time=8.51 ms
Routy jsou takovéto:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.26.1 0.0.0.0 UG 1 0 0 eth2
default 10.109.13.129 0.0.0.0 UG 5 0 0 eth1
10.109.13.128 * 255.255.255.128 U 0 0 0 eth1
172.16.26.0 * 255.255.255.0 U 0 0 0 eth2
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
Co dělám špatně?
Díky za odpověď.
Řešení dotazu:
Už vše funguje.
# vytvoreni routovacich tabulek (CS, PF) a rout
$ip route add 172.16.26.0 dev eth2 src 172.16.26.62 table T1
$ip route add default via 172.16.26.1 table T1
$ip route add 10.109.13.128 dev eth1 src 10.109.13.146 table T2
$ip route add default via 10.109.13.129 table T2
# nastaveni rout
$ip route add 172.16.26.0 dev eth2 src 172.16.26.62
$ip route add 10.109.13.128 dev eth1 src 10.109.13.146
# nasteveni defaultni routy
$ip route add default via 172.16.26.1
# nasteveni smerovacich rout (aby slo dovnitr a ven to, jakym interfacem to prislo)
$ip rule add from 172.16.26.62 table T1
$ip rule add from 10.109.13.146 table T2
# prirazeni konexi do tabulek
$ip route add 192.168.1.0 dev eth0 table T1
$ip route add 10.109.13.128 dev eth1 table T1
$ip route add 127.0.0.0/8 dev lo table T1
$ip route add 192.168.1.0 dev eth0 table T2
$ip route add 172.16.26.0 dev eth2 table T2
$ip route add 127.0.0.0/8 dev lo table T2
# nastaveni nexthopu (v pripade vypadku GW)
$ip route add default scope global nexthop via 172.16.26.1 dev eth2 weight 1 nexthop via 10.109.13.129 dev eth1 weight 2
Ovšem místo "rule" jsem psal stále "route" (už je moc hodin, nějak jsem to přehlédl).
Teď vše funguje perfektně
Tak třeba to někomu pomůže!
route, ze kterého v takovém případě není vidět téměř nic?
Je v něm vidět třeba to, že u obou připojení je nastavna defaultní gw, jakou mají metriku a podobně
Je z něj vidět jen obsah tabulky main, žádné další tabulky a žádná pravidla. Takže jakmile další tabulky a pravidla používáte, není z něj vidět skoro nic a nelze na základě něj vůbec odhadovat, jak se pakety routují.
Místo této poznámky jste mohl napsat, že třeba místo route byste očekával ip route
Samotný výstup "ip route show" je sice přehlednější, ale pořád ukazuje jen tabulku main. Takže by to chtělo "ip rule show" a buď obsah všech relevantních tabulek nebo rovnou "ip route show table all" (který je ale dost nepřehledný).
Tiskni
Sdílej: