Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
eth0 Link encap:Ethernet HWaddr 00:0f:ea:66:7f:59
inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20f:eaff:fe66:7f59/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:71337 errors:0 dropped:0 overruns:0 frame:0
TX packets:81112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:25246722 (25.2 MB) TX bytes:77944362 (77.9 MB)
Interrupt:18 Base address:0xc000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:447 errors:0 dropped:0 overruns:0 frame:0
TX packets:447 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22592 (22.5 KB) TX bytes:22592 (22.5 KB)
tap0 Link encap:Ethernet HWaddr 4a:54:74:17:46:53
inet addr:192.168.10.100 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::4854:74ff:fe17:4653/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:297 errors:0 dropped:0 overruns:0 frame:0
TX packets:197 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27178 (27.1 KB) TX bytes:35762 (35.7 KB)
je to server který je za routerem takže je na něj směrovaný port 1194 na kterém mi jede OpenVPN. Nastavení OpenVPN serveru je následující:
mode server port 1194 proto udp dev tap0 tls-server reneg-sec 3600 ca ca.crt cert neco.crt key neco.key dh dh1024.pem ifconfig 192.168.10.100 255.255.255.0 ifconfig-pool 192.168.10.20 192.168.10.21 255.255.255.0 push "route 192.168.1.0 255.255.255.0 192.168.10.100" keepalive 120 600 comp-lzo user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 1 mute 20 management localhost 5556Dále pak mám klientskou část která by měla fungovat takto, linux server který se má připojit na tuto VPN a všem ostatní počítačům za sebou poskytnout tunelovanou síť, takže všechno v rozsahu 192.168.1.O/24. Nastavení tohoto serveru je: OpenVPN
client dev tap1 proto udp remote IP_OpenVPN_serveru resolv-retry infinite nobind persist-key persist-tun ca neco-ca.crt cert neco.crt key neco.key comp-lzo tls-client verb 1a síť je eth0 veřejná IP a eth1 192.168.2.254/255.255.255.0 Teď k tomu jak se to chová, když to všechno nahodím a přidám toto pravidlo iptables -t nat -A POSTROUTING -o eth0 -s 192.168.2.0/24 -j SNAT --to 192.168.10.20 a mám za tím serverem připojený notebook s linuxem tak si bez problému odpingám server 192.168.1.5, ale když kabel odpojím a nastavím totožné adresy na stolní počítač ve kterém jsou Windows XP tak mi ping na 192.168.1.5 přestane záhadně fungovat, i když kabel vrátím zpět na notebook ze kterého ping fungoval tak už nefunguje. Ping ze serveru je bez problému ale na všem co je za tím ping přestane fungovat po připojení Win XP stanice. Mohl by mi někdo prosím říct v čem je problém? Na počítačích za tím serverem který se připojuje jako klient na OpenVPN server nepotřebuji internet, potřebuji jen tunel do jiné sítě abych měl dostupný samba server. Jen ještě dodám že po připojení Win XP a znefunkčnění pingu a tedy i dostupnosti samba serveru, se v logu nic nezapíše. Děkuji za rady.
80.0.0.0.1 .........80.0.0.2
192.168.0.0 ------172.16.24.1---------172.16.24.2 .......192.168.1.0
PC1 ROUTER1 ROUTER2 PC2
ROUTER1:
route 192.168.1.0 via 172.16.24.2
PC1:
route 192.168.1.0 via default
a naopak..
Na nejkaje nas se vyser a over si vsechno pres ping..
NN
route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 * 255.255.255.0 U 0 0 0 tap0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0a tady z klienta který se k serveru připojuje:
route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 82.100.10.192 * 255.255.255.192 U 0 0 0 eth0 192.168.100.0 * 255.255.255.0 U 0 0 0 tap0 localnet * 255.255.255.0 U 0 0 0 eth1 192.168.1.0 192.168.100.100 255.255.255.0 UG 0 0 0 tap0 default 82.100.10.193 0.0.0.0 UG 100 0 0 eth0podotýkám žě z tohoto klienta jde ping na 192.168.1.5 bez problému, ale zároveň tento klient poskytuje vpn připojení ostatním pc v síti 192.168.2.0/24 ale z těch už ping neprojde, ani na 192.168.100.100 což je druhá strana tunelu, jen na 192.168.100.20, což je klientská strana tunelu.
ip route list 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.5 default via 192.168.1.1 dev eth0 metric 100na druhem který má poskytovat vpn je:
ip route list 82.100.10.192/26 dev eth0 proto kernel scope link src 82.100.10.218 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.20 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.254 192.168.1.0/24 via 192.168.100.100 dev tap0 default via 82.100.10.193 dev eth0 metric 100zadal jsem tedy ip route add 192.168.2.0/24 via 192.168.100.20 tak to napíše RTNETLINK answers: File exists, tak jsem zadal ip route add 192.168.100.102 via 192.168.100.20, 192.168.2.102 je adresa klienta který by se měl mít dostupnou sambu z toho vpn tunelu, a stále nic, nemám odezvu ani na druhou stranu tunelu na 192.168.100.100. Současný stav route je:
ip route list 192.168.2.102 via 192.168.100.20 dev tap0 82.100.10.192/26 dev eth0 proto kernel scope link src 82.100.10.218 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.20 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.254 192.168.1.0/24 via 192.168.100.100 dev tap0 default via 82.100.10.193 dev eth0 metric 100
ip route list 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.100 192.168.2.0/24 via 192.168.100.100 dev tap0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.5 default via 192.168.1.1 dev eth0 metric 100a na klientovi je:
ip route list 82.100.10.192/26 dev eth0 proto kernel scope link src 82.100.10.218 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.20 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.254 default via 82.100.10.193 dev eth0 metric 100a z něj si pingnu jen na vnitřní část tunelu, to je 192.168.100.20 a dál na 192.168.100.100 ne.
cat /etc/openvpn/server.conf mode server port 1194 proto udp dev tap tls-server reneg-sec 3600 ca ca.crt cert c.crt key c.key dh dh1024.pem ifconfig 192.168.100.100 255.255.255.0 ifconfig-pool 192.168.100.20 192.168.100.20 255.255.255.0 #route 192.168.1.0 255.255.255.0 192.168.100.100 #push "route 192.168.2.0 255.255.255.0 192.168.2.20" keepalive 120 600 comp-lzo user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 1 mute 20 management localhost 5556IP serveru je 192.168.1.5 a je za routerem který má proroutovaný port 1194 na 192.168.1.5
ip route list 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.100 192.168.2.0/24 via 192.168.100.100 dev tap0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.5 default via 192.168.1.1 dev eth0 metric 100Na straně klienta: cat /etc/openvpn/klient.conf client dev tap0 proto udp remote veřejná_IP_routeru resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert c.crt key c.key comp-lzo tls-client verb 1 reneg-sec 3600 log-append /var/log/openvpn.log
ip route list 82.100.10.192/26 dev eth0 proto kernel scope link src 82.100.10.218 192.168.100.0/24 dev tap0 proto kernel scope link src 192.168.100.20 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.254 192.168.1.0/24 via 192.168.100.20 dev tap0 default via 82.100.10.193 dev eth0 metric 100potom nahodím na straně serveru ip route add 192.168.2.0/24 via 192.168.100.100 a na straně klienta ip route add 192.168.1.0/24 via 192.168.100.20 tak mi jede ping sem a tam, naprosto všude. Ale pokud na stranu klienta přidám desktop windows XP tak už si na 192.168.100.100 nepingnu a na 192.168.100.20 ano, takže přidám na klienta poskytujícího vpn ip route add 192.168.2.102 via 192.168.100.20 což je IP daného win XP stroje a stále nic. A přestane mi fungovat i ping na 192.168.100.20 i vnitřní síť 192.168.2.254 což je IP eth2 na stroji který má poskytovat VPN. Pokud to pravidlo smažu tak ping na 192.168.100.20 a 192.168.2.254 jede
Tiskni
Sdílej: