O víkendu probíhá na FIT VUT v Brně konference OpenAlt 2026 o otevřeném softwaru a datech, IT bezpečnosti, DIY a IoT. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma. Přednášky lze sledovat i online na VHSky a YouTube.
Qualcomm uzavřel víceletou dohodu se SpaceX. Bude dodávat rádiové technologie, baseband jednotky a software pro plánovanou pozemní 5G síť Starlink Mobile. Výstavba má zahrnovat desítky tisíc základnových stanic v USA. Zahájení nasazování se očekává v roce 2027. Qualcomm dohodu označuje za svůj dosud největší 5G kontrakt.
Google rozšířil Cloud Vulnerability Reward Program. Nově nabízí odměnu až 250 tisíc dolarů za vysoce závažné architektonické bezpečnostní chyby označované jako Root-in-Cloud.
V březnu byla oznámena spolupráce GrapheneOS s Motorolou. Nejnovější vlajka Motorola Signature 27 je první Motorola s oficiální podporou GrapheneOS. GrapheneOS (Wikpedie) je varianta Androidu zaměřující se na bezpečnost a soukromí.
Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Řešení dotazu:
Raději nijak. Doporučuji do vnitřní sítě / stroje dotáhnout IPv6 a vevnitř už rozvést nativně.
Uniká mi totiž, k čemu vám bude hypotetický překlad, když nebudete moci zadat cílovou adresu. Bijekce se mezi množinami s různým počtem prvků (adres) dělá blbě.
Pridavam se k dotazu a pokusim se popsat situace, kdy by to mohlo byt potreba:
Dejv
(1) není problém (pokud se omezíme na omezený počet spojení). Prostě se na NAT64 vyhradí vnitřní rozsah pro SNAT a příchozím IPv6 spojení se přiřadí zdrojová adresa z vyhrazeného rozsahu a cílová se přepíše na adresu vnitřního zařízení. Mapování z cílové adresy zvnějšího IPv6 do vnitřního IPv4 lze udělat algoritmicky například vestavěním IPv4 adresy do IPv6 adresy. Počet spojení bude samozřejmě omezen velikostí vyhrazeného vnitřního IPv4 rozsahu.
(2) je, co tazatel zřejmě chtěl. Vzhledem k tomu, že globální IPv6 adres je mnohem více než soukromých IPv4 adres, není možné zevnitř zahájit komunikaci s kýmkoliv. Buďto se vybere malý IPv6 rozsah, který dá bijektivně namapovat do vnitřního IPv4. To je ale prakticky použitelné jen pro vnitřní kontrolovaná prostředí, kde si toto omezení lze dovolit. V opačném případě musí by se musel zapojit dynamické mapování DNS záznamů do vyhrazeného IPv4 rozsahu a držet DNS a NAT mapování v synchronizaci (a s rozumnou životností). Dříve se věřilo, že to půjde, praxe ukázala, že je to natolik ošklivé, že se toto řešení a tedy i celý bod (2) označil za zhoubný a nepodporovaný (stavěl na tom článek na Lupě, který představoval NAT64).
(3) S NAT64 máte blok veřejných IPv4 adres na které staticky mapuje stejně chudý počet vnitřních IPv6 adres. Zdrojové není problém namapovat algoritmicky, protože vnější IPv4 se do vnitřního IPv6 podprostoru vleze. Daly by se zapojit i vnější transportní adresy, ale dokud se nerozšíří dohledávání serverů přes NAPTR/SRV záznamy na straně klientů, tak to bude komerčně/uživatelsky neprůchodné, protože psát k adrese i číslo portu se nenosí.
(4) není problém. Prostě se veřejný IPv4 algoritmicky namapuje do vnitřního IPv6 podprostoru. Zvenku se pouze naptuje zdrojová transportní v4 adresa. Umí TRT. Nebo jako standardní součást NAT64, kdy se vyhradí blok veřejných IPv4 adres a natuje se z něj. Počet spojení je pak ale omezen na počet vnějších IPv4 adres. TRT obslouží více spojení, protože si vypomůže transportním prostorem.
Tiskni
Sdílej: