Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Pro upresneni:
Potrebuji nektere pakety routovat jinudy nez zbyle. Muj napad tedy byl:
iptables -t mangle -A OUTPUT [popis-paketu] -j ROUTE --gw jinam
Jenze navic potrebuji zaridit, aby zdrojova adresa paketu byla ta patrici onomu sitovemu rozhrani kde sidli jinam
. Defaultne se ovsem pouzije adresa patrici druhemu sitovemu rozhrani, kam se routuje vsechno ostatni...
nat
v POSTROUTING
pomoci -j SNAT
nebo -j MASQUERADE
vice v manu
--gw
použít i --oif
?
OUTPUT
v tabulce MANGLE
, už je o směrování rozhodnuto.
mangle.OUTPUT
, a pakety jsou sice směrovány správně (tj. označkované jdou jinudy než neoznačkované), ale všem zůstává původní zdrojová adresa (jako by označkované nebyly). Použití SNAT
sice problém zdrojové adresy řeší, ale moc uspokojivé řešení to není, lepší by byl Fast NAT, kdyby fungoval. Také by bylo dobré zjistit, co všechno ze zvolené položky směrovací tabulky se ještě při tom "druhém průchodu" ignoruje.
src
té položky, a to i když jsem ho zadal explicitně při jejím přidávání pomocí 'ip route add
'. Paket sice odešel přes druhou gateway, ale se zdrojovou adresou odpovídající té původní. To se u průchozích paketů, značkovaných v mangle.PREROUTING
, neděje.
src primo nemeni zdrojovou ip adresu. Pouze upravuje chovani routingu tak, jako by zdrojova adresa byla src. (Coz je uzitecne prave pro lokalne generovane pakety, ktere nemaji zadnou zdrojovou adresu).
S takovým výkladem nemohu souhlasit, podle dokumentace (i podle mých zkušeností) parametr src
určuje preferovanou zdrojovou adresu, tedy zdrojovou adresu, která se přiřadí, není-li zdrojová adresa předem určena jinak (např. u forwardovaných paketů, paketů patřících do existujícího flow nebo paketů, kde si o konkrétní zdrojovou adresu řekla aplikace). Tento parametr nemůže ovlivnit chování routingu, protože se k němu dostaneme teprve v okamžiku, kdy už routing vybral optimální směrovací položku (takže už není co ovlivňovat).
Delat NAT jsem take zkousel, nicmene to nechtel a nechtel natovat. Predpokladam proto, ze se vzdy aplikovalo pouze jedno pravidlo z iptables...
BTW, nevite nekdo tu banalni vec (ktera je asi tak banalni, ze jsem ji nikde nenasel), jak se aplikuji v iptables pravidla? Je mi jasne, ze vyhovuje-li nejake pravidlo nejakeho chainu, dalsi pravidla uz se v nem netestuji. Co ale jine chainy? A jine tabulky?
Tiskni Sdílej: