Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
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.
Když jsem začal před pár týdny experimentovat s IPv6, začaly mi docházet některé věci, především ta, že IPv4 je zbytečně složité a že čím dřív přejde internet na IPv6, tím bude má práce síťového administrátora jednodušší. Ostatně o IPv6 už jsem zde jeden zápisek zvěřejnil.
IPsec na IPv6
- podrobnější článek o rozdílu IPsec na IPv4 a IPv6. Hlavní myšlenka článku: "VPN pro IPv6 neexistuje".
IPv4 nefunguje! Ať žije IPv6!
- dřívější zápisek v mém blogu.
Na svém routeru mám nainstalovaný systém OpenWrt. Kdysi jsem experimentoval na tomto routeru s IPsec, ale poněkud jsem pohořel. Ze dvou důvodů:
Potřeboval jsem propojit sítě 10.10.1/24 a 10.100.1/24. I když mám na svém routeru veřejnou IP adresu, ke svému ISP jsem připojený přes PPTP a spojovací síť je, jak na potvoru, 10.10.1/24.
I když se mi kvůli IPv4 nepodařilo napojit šifrovaně na síť 10.10.1/24, dokázal jsem udělat šifrovaný kanál na síť s jinou, nekolidující adresou. Tam se ukázalo, že výkon mého zařízení s OpenWrt je hrubě nedostatečný. Přenosy byly až k nepotřebě pomalé.
Na jiném routeru (mírně rychlejší CPU, větší flash) jsem se k IPsec vrátil. Nainstaloval jsem si nejnovější verzi OpenWrt (BackFire) - s IPv6 jsem problémy nezaznamenal, pouze u IPsec na IPv6 nepamatovali a musel jsem si balík ipsec-tools opatchovat a přeložit ručně.
U IPv6 naprosto nehrozí konflikt adresy s mým ISP - zádrhel, který mi znemožnil nastartovat IPsec na routeru, zcela zmizel. S podivem se neobjevily ani nejmenší problémy s výkonem. Buď je výkon novějšího software vyšší v několika řádech, nebo je několikařádový rozdíl mezi procesorem 200 MHz a 266 MHz.
IPv6 komunikace mezi oběma propojovanými sítěmi mi pochopitelně fungovala už před zprovozněním IPsec, pomocí IPsec komunikaci pouze zabezpečím.
Tiskni Sdílej:
"Pro prenosy mezi pobockama nastavime sifrovany tunel?" nebo "Pro prenosy mezi pobockama nastavime VPN?".
"Spojíme ty sítě pomocí VPN?" (ipv4 - kombinace šifrování, tunelování, routování a natu, složité tak, že to potřebuje vlastní jméno)
"Zapneme mezi těmi sítěmi šifrování?" (ipv6 - jednoduché tak, že lze označit obecným pojmem "šifrování")
V IPsec znamená režim "tunnel" jen to, že se zašifrují i hlavičky. Česky: "šifrováním jsme skryli i adresy".
Ke svému ISP jsem připojený přes PPTP, to je taky šifrovaný tunel. Je mi ukradené tomu "nějak říkat", pro mě to je "připojení".
Až bude "šifrování" v IP znamenat "IPsec zapnuto", nebude potřeba tomu říkat jménem.
Dneska VPN zahrnuje velkou skupinu různých postupů a produktů, které se většinou ani nepoužívají kvůli zabezpečení.
V IPsec znamená režim "tunnel" jen to, že se zašifrují i hlavičky.Pokud vim, tak i v IPsec znamena tunnel rezim vicemene to same, jako v jakykoliv jinem tunelovem protokolu - tedy vytvoreni virtualni linky pomoci zapouzdreni celych paketu. Oproti prostemu sifrovani je mozne skrz takovou linku routovat.
Proč vytvářet nějakou speciální "linku" kvůli zabezpečení, když cesta už existuje a stačí jen zapnout šifrování?Ale ta linka (tunel) se nevytvari kvuli zabezpeceni! Tunely neslouzi primarne kvuli zabezpeceni, ale kvuli uplne jinym vecem (primarne ruznym formam uprav routovani). Proto se take casto pouzivaji i nesifrovane, nezabezpecene tunely (treba GRE). Samozrejme, pokud potrebuju pouze zajistit sifrovane spojeni, pak nepotrebuju zadnou tunelovaci technologii, ale casto clovek potrebuje neco jineho. Napriklad: - propojeni oddelenych siti pouzivajicich ULA adresy (kvuli multihomingu). - propojeni oddelenych siti na L2 urovni. - pouzivan adres z jine site, nez pres kterou jsem fyzicky pripojen (napr, kvuli multihomingu nebo mobilite nebo proste proto, ze potrebuju pripojit celou sit a fyzicky ISP me poskytl jen /128). ... Me pro zmenu prijde, ze nemate predstavu, k cemu vsemu se pouzivaji (at uz sifrovane nebo nesifrovane) tunely resp. VPN. Zdaleka ne jen kvuli bezpecnosti.
Říkám: "Pro zabezpečení přenosů VPN netřeba" a vy na to: "Ale tunel se dá použít i na úplně jiné věci".Ten clanek (a predchozi prispevky) rika ale neco jineho - "v IPv6 VPN netreba" a demonstuje to tim, ze VPN neni treba pro zabezpeceni prenosu, ja na to "v IPv6 sice neni VPN treba pro zabezpeceni prenosu, ale VPN se pouziva i na spoustu jinych veci, proto je v IPv6 VPN potreba taky". Neboli nedorozumeni mohlo vznikout pouzivanim prilis bombastickych tvrzeni.
I v tomto případě je šifrování jen zabezpečením existující cesty a speciální "linku" tvořenou pomocí VPN nepotřebujeTu virtualni linku potrebuju uz jen kvuli tomu, abych na ni mohl pusit OSPF. I kdyz je pravda, ze v tomto pripade by asi stacilo mit OSPF jen na opticke linke a zbytek nechat na defaultni route, cistci reseni by asi ale bylo mit OSPF na obou.
Proč vytvářet nějakou speciální "linku" kvůli zabezpečení, když cesta už existuje a stačí jen zapnout šifrování?Ale ta linka (tunel) se nevytvari kvuli zabezpeceni!
Ta linka se především vůbec nevytváří. Ta linka už existuje.
Ta linka se především vůbec nevytváří. Ta linka už existuje.linka (ve smyslu ptp spoj tvarici se vicemene jako jeden hop, fungujici vicemene na linkove urovni, transparentne bez ohledu na zdrojove a cilove adresy) neexistuje, existuje akorat cesta vedouci skrz nekolik (obvykle cizich) routeru.
Při použití certifikátů má každý uzel svůj pár klíčů a ten může používat pro komunikaci se všemi ostatními."Všichni ostatní" jsou v tomto případě jeden uzel - brána druhé LAN. Kompromitace jednoho uzlu tedy vždy znamená odhalení veškeré šifrované komunikace. Jaký je tedy v tomto případě praktický a bezpečnostní rozdíl mezi certifikáty a PSK?