Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
Servant
) poskytuje určité služby, které jsou využívány z dalších serverů. Druhý (říkejme mu Host
) je hostitelským serverem pro provoz virtuálních serverů založených na OpenVZ.
Oba tyto stroje mají dvě síťové karty, přičemž přes eth0 se oba připojují do vnější sítě (1.2.3.0/24), zatímco přes eth1 se připojují do vnitřní sítě (192.168.1.0/24). Tzn. pro přesnější představu: mám několik serverů, každý z nich je ve dvou sítích, které se liší tím, že jedna je pouze pro komunikaci mezi nimi navzájem, druhá je určena pro komunikaci s vnějším světem.
Na serveru Host
dále běží nějaké VPS, pro účely tohoto dotazu je jeden, kterému budu říkat prostě Vps
. Až na to, že nemá své vlastní železo, je to server jako všechny ostatní v síti, takže i tento server je připojen do vnější i vnitřní sítě a využívá služby ze serveru Servant
.
Tzn. v souhrnu síťová konfigurace vypadá nějak takhle:
Servant 192.168.1.1 1.2.3.1 Host 192.168.1.2 1.2.3.2 Vps 192.168.1.3 1.2.3.3A teď ten slavný problém. Když se z
Vps
připojím na Servant
skrze vnitřní síť (tzn. příkazem ssh user@192.168.1.1
), připojení sice proběhne, ale na stroji Servant se pak příkazem who
dozvídám, že nejsem připojený z adresy 192.168.1.3, ale z 1.2.3.3. Tzn. pakety určené pro vnitřní síť putují po té vnější, což je problém z mnoha důvodů.
Podle mého dosavadního zkoumání problém může souviset s tím, že OpenVZ přiřazuje jednotlivým VPS adresy s netmaskou /32, takže se na cestě mezi venet0 na Host
a fyzickým rozhraním nějak blbě upraví a nasměrují se špatně.
Přiznám se, že mi ne zcela dochází, jak to, že se na vnější síti vůbec podaří najít správný server, takže ani moc dobře nevím, kam šáhnout a co změnit, aby se pakey poslušně odebíraly ven přes eth1.
Určitým nápadem je znásilnit OpenVZ, aby nastavovalo masku /24, všude se ale doporučuje tuhle věc nedělat (bohužel bez vysvětlení). Další možností by mohlo být nějaké veselé nastavení iptables, které by vynutilo směrování odpovídajících paketů na eth1.
Nejdřív jsem se ale chtěl zeptat, jestli někdo neřešil něco podobného, abych nevynalézal kolo se spoustou vedlejších efektů. P5edem dík za všechny odpovědi.
takze jenom kratce - vnet je na vz nejvetsi zlo. daleko jednodussi je vzdy pouzit bridge, sit se pak chova tak jak jeden ceka, tj: vzctl set 20 --netif_add eth0,00:DE:AD:BA:BE:00,vzeth0,00:DE:AD:BA:BE:01 --save vytvori eth0 v kontextu 20, druhy konec interfacu se jmenuje vzeth0 (prida se do bridge vmbr0 ktery jiz musi existovat) a v kontejneru nastavit spravne /etc/network/interfaces. dale je treba vytvorit /etc/vz/vznet.conf a v nem mit EXTERNAL_SCRIPT="/usr/local/sbin/vznetaddbr konteiner se pote po startu prida do bridge 'vmbr0' (ten si musis udelat, nabridgovat kam potrebujes) vice navod na http://wiki.openvz.org/Virtual_Ethernet_device mimochodem v tvem pripade by nebylo od veci mozna v ct0 pouzivat tagovane vlan, neni treba pak mit 2 sitovky. tagovane vlany jsou v kazdem ohledu sitove zarizeni.
Tiskni
Sdílej: