Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »Článek na blogu APNIC vysvětluje, jak správně vytvářet a používat ASPA záznamy — podepsané objekty v RPKI, které uvádějí, kteří poskytovatelé směrování jsou pro dané autonomní číslo (ASN) oprávněni. Síťoví operátoři je mohou využít k ověřování tras BGP a k odhalování úniků tras či podvržených tras.
Byla vydána (𝕏) verze 8.0.0 open source programu pro prolamování hesel hashcat (GitHub, Wikipedie). Přehled novinek v příspěvku v diskusním fóru a pdf.
Byla vydána (𝕏, Bluesky) nová verze 2026.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 6 nových nástrojů v oficiálním oznámení na blogu.
Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »
-A POSTROUTING -o tun2 -j MASQUERADE
ip route show
default via 89.x.x.1 dev ens3
10.9.0.0/24 via 10.9.0.2 dev tun0
10.9.0.2 dev tun0 proto kernel scope link src 10.9.0.1
10.20.40.0/22 dev tun2 proto kernel scope link src 10.20.40.24
89.x.x.0/23 dev ens3 proto kernel scope link src 89.x.x.13
ip route list table vpn
default via 10.20.40.1 dev tun2
10.20.40.0/22 dev tun2 scope link src 10.20.40.24
V tomto je problem přidávám routy ručně a mění se mně furt ta IP
ip route add 10.20.40.0/22 dev tun2 src 10.20.40.24 table vpn
ip route add default via 10.20.40.1 dev tun2 table vpn
ip rule add from 10.9.0.1/24 table vpn
Mám tedy dva dotazy:
1) řeším to správně, že jsem přidal jen jednu vpn tabulku?
2) jak to zautomatizovat, aby při připojení na VPN se routy nastavili samy, dle IP jaké dostanou. Na VPN server kam se připojuji nemám přístup. Když to nechám na openvpn serveru, tak dá jeho routu na default a vše běží přes VPN
10.9.0.0/24 via 10.9.0.2 dev tun0 ip rule add from 10.9.0.1/24 table vpn ip route add default via 10.20.40.1 dev tun2 table vpnTzn predpokladam, ze tun0 je v rozsahu 10.9 a ta routa je od nej. Pak mas pravidlo, ze vse co je z toho rozsahu ma jit do tabulky vpn. A v ty tabulce mas receno, ze provoz maji jit pres tun2. A co myslis ze se stane, kdyz zahajis komunikace do rozsahu 10.9? Presne to co mas nastaveno, posle se to do routovani podle vpn. A v ty rikas, ze veskerej provoz posles na tun2. Respektive, ti pres ten tun2 samozrejme potece veskera komunikace smerem od klienta. Je to o to veselejsi, ze ty pakety putuji na tu GW co tam mas nastavenou, a pak se vraci zpet. Pokud se ptas proc, tak se zamysli nad tim, kam jinam by asi tak mely putovat, kdyz tam jinou cestu nemas, coz je presne to, co ti tam chybi. --- Dete s tim guuglem dopice!
iptables -t nat -A prerouting -i ens3 -d 10.9.0.0/24 -j SNAT --to 10.20.40.24Bude to take nutne dynamicky menit..
Všechno špatně.
…připojeno do internetu IP 89.x.x.13…
Tady není ani náznak připojení „do internetu“. Jde o připojení do IPv4, který přímo způsobuje všechny popsané problémy s routováním. Nepodařený experiment z roku 1975, omylem zveřejněný, přestal už před rokem 2000 definitivně fungovat — zhruba od té doby se už nedalo normálně routovat odkudkoliv kamkoliv. Proč tohle v roce 2021 ještě někdo používá, to je fakt záhada.
Řešením tedy je (jako vždy) opravdový internet — IPv6.
pak VPN
tun0 - sem se připojují klienti
tun2 - odsud jsem připojen k jinému ISP
V celém tomto popisu není ani jedna zmínka o VPN.
Ne, skutečná VPN nikdy nepoužívá nic takového jako rozhraní tun; to opravdu (ale opravdu (ale opravdu)) ne.
VPN běží na stejném síťovém rozhraní jako kterýkoliv jiný provoz. Démon pro správu klíčů (například StrongSwan) vytvoří mezi dvěma podsítěmi IPSec tunel a jediné, čím se IPSec projevuje (kromě záznamů v routovacích tabulkách) je „zkrácení“ (co do zdánlivého počtu „hopů“, nikoliv času) spojení do „protější“ sítě — dá se tam najednou dostat „jedním hopem“. Žádné virtuální pseudorozhraní k VPN nepatří.
Přítomnost nesmyslů typu tun může znamenat, že zase další uživatel naletěl na Open„VPN“ — béčkovou jednovláknovou dětskou hračku v userspace, která má chybně a nepatřičně „VPN“ v názvu, ač jediné, co opravdu dobře „zvládá“, je zbytečné zpomalení připojení asi tak o desítkový řád ve srovnání s výkonem skutečné VPN (tedy IPSec).
Řešení celého problému — který se tady v poradně objevuje zbytečně stále znova a znova — je tedy jednoduché a pořád dokola stejné: Zaprvé, skutečný internet, tedy IPv6. Pak ve většině případů nebude VPN vůbec potřeba. Zadruhé, pro ty zbývající vzácné případy: skutečná VPN, tedy IPSec, bez matoucích pseudorozhraní typu tun (a s nimi souvisejících problémů s routováním), bez jednovláknových userspace zpomalovačů atd. atp.
Po VPN přenáším prostě 1 Gb/s, což je všechno, co moje současné připojení umí. (10 Gb/s sice můžu mít asi na 3 kliknutí se stále stejnou optikou, ale nechce se mi za to platit cca dvojnásobek, když beztak většina protistran 10 Gb/s stále ještě nedá.)
Open„VPN“ není VPN. Tím by mohla celá úvaha skočit.
Dotazů typu „proč mám na Open‚VPN‘ asi tak desetinu mého gigabitu“ se tady na ABCLinuxu povaluje hodně. Open„VPN“ je prostě jednovláknové béčko v userspace. Možná dá 500 Mb/s, když bude mít velké štěstí na TurboBoost. Možná dá třetinu z toho, pokud ne. Každý paket představuje minimálně 6 context-switchů místo rozumných dvou (a s chytrými scatter-gather triky dokonce v průměru méně). Zoufalství, nouze, zbytečnost. Nebrat. Technologie pro VPN se jmenuje IPSec.
Tiskni
Sdílej: