Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
Ahoj , Kdysi dávno jsem rozjel routovanou OVP a teď se předělávala síť a nemůžu to dát znovu dohromady. Používám tunel přes TUN adaptér a režim server - klient. TUN má nastavení inet 10.0.1.1 peer 10.0.1.2/32 scope global tun0 Dále pak mám IPTABLES -A FORWARD -i tun0 -s 10.0.1.0/24 -o eth0 -j ACCEPT -A FORWARD -i eth0 -o tun+ -j ACCEPT cat /proc/sys/net/ipv4/ip_forward 1 Na klienta pushuji mode server tls-server dev tun port 1194 proto udp server 10.0.1.0 255.255.255.0 persist-tun persist-key ifconfig-pool-persist ips.txt push "route 10.10.40.0 255.255.255.0" route 10.0.10.0 255.255.255.0 - """" toto nevím proc už tam mám """""" #client-config-dir ccd #duplicate-cn client-to-client keepalive 10 120 ETH0 mám přes DHCP s nastavením 10.10.40.30 a GW 10.10.40.1 což je router Routovací tabulka zde bude někde asi zakopaný pes : 10.0.1.2 * 255.255.255.255 UH 0 0 0 tun0 10.0.1.0 10.0.1.1 255.255.255.0 UG 0 0 0 tun0 10.0.1.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 10.0.10.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 10.10.40.0 10.10.40.30 255.255.255.0 UG 0 0 0 eth0 10.10.40.0 10.10.40.1 255.255.255.0 UG 0 0 0 eth0 10.10.40.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 10.10.40.1 0.0.0.0 UG 0 0 0 eth0 Situace je taková , že klient se připojí do VPN a vidí až adaptér 10.10.40.30 , ale nevidí dále do sítě Na routeru mám přidanou routu 10.0.1.0 přes 10.10.40.30 Při dnešních pokusech se mi podařilo pingnout z vnitřni sítě klientský PC ve VPN na 10.0.1.6 avšak už nevím při jakých routáchProsím o radu bude to asi jen nějaká drobná blbost. Ještě zmíním, že oproti minulé konfiguraci tu máme nově VLANy. ALe když ten jeden směr už jel, tak si myslím, že to nemá vliv, ale jsou chybně routy na VPN serveru. Děkuji Roman
Řešení dotazu:
route 10.0.10.0 255.255.255.0Doporucuji ICMP + tcpdump a projit celou cestu.
ANO VPN server je ve vnitřní síti 10.10.40.0 jehož adresa je 10.10.40.30 ještě podotknu , že je na switchi nastaven port pro VPN server jakožto untagged s PVID 40 tedy VPN server je ve VLAN ID 40 ! Nemůže nakonec být problém skutečně problém s VLAN ? routy jsem promazal. 10.0.1.2 * 255.255.255.255 UH 0 0 0 tun0 10.0.1.0 10.0.1.1 255.255.255.0 UG 0 0 0 tun0 10.0.1.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 10.10.40.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 10.10.40.1 0.0.0.0 UG 0 0 0 eth0
Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 eth0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0take by som skusil vyhodit tieto zaznamy
10.0.1.0 10.0.1.1 255.255.255.0 UG 0 0 0 tun0 10.0.10.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 10.10.40.0 10.10.40.30 255.255.255.0 UG 0 0 0 eth0 10.10.40.0 10.10.40.1 255.255.255.0 UG 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0aj vsetky ine zaznamy ohladom siete 10.0.10.0/24
Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.2 * 255.255.255.255 UH 0 0 0 tun0 10.0.1.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 10.10.40.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 10.10.40.1 0.0.0.0 UG 0 0 0 eth0 Stále se dostanu jen na adresu eth0 Jaký vliv má na openVPN to, že lokální síť je v VLAN ID 40 ? Děkuji
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz