Squeak (Wikipedie), open source implementace programovacího jazyka a prostředí Smalltalk, byl vydán ve verzi 6.1. Přehled novinek v poznámkách k vydání.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Zapscape aneb CVE-2026-64561. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala 6 let (od července 2020 do července 2026).
Počítačová hra Knytt napsaná v Multimedia Fusion 2 byla vydána před 20 lety. Při této příležitosti byl dnes představen moderní port (YouTube) této plošinovky na současné operační systémy pod názvem Knytt Classic. Je zdarma k dispozici na Steamu a GOG.com.
Americká technologická společnost Meta Platforms představila nový model umělé inteligence (AI) Muse Glimmer. Model je menší než přední modely AI od konkurence a má běžet přímo na počítačích uživatelů. Meta model zpřístupní jako open source, tedy otevřený software. Nový model je navržen tak, aby zvládal takzvané agentní úkoly na počítačích se spotřebitelskou grafickou kartou. Klade si tak za cíl uspokojit poptávku po systémech AI, které běží přímo na zařízeních uživatelů.
V pátek 28. srpna 2026 se v pražském Karlíně uskuteční již osmý Mobilní Hackday. Akce začne v 10:00 a potrvá až do večera. Setkání proběhne v prostorách SUSE Linux, s.r.o. na adrese Křižíkova 148/34, Praha 8 – Karlín. Nejbližší zastávkou je Křižíkova, kam se lze dostat tramvají i metrem. Na programu budou například novinky z posledních měsíců, možnosti, jak si zjednodušit práci s LLM/AI, a také nová linuxová distribuce BengalOS, včetně … více »
Jakub Vrána vydal Adminer ve verzi 6.0.0 s více než 130 změnami: "Většina změn vznikla s asistencí Claude Opus 5. Někteří lidi se bojí, že AI asistence může kód zamořit technickým dluhem. To je jistě pravda, pokud vývojář všechny změny bezduše odbouchne Enterem. Ale pokud si pořádně projde plán, vyjedná v něm změny a pak totéž udělá i s vygenerovaným kódem, kvalita kódu stoupne a technický dluh naopak klesne. Je to jako párové programování s
… více »Sam Aaron vydal novou major verzi 5.0.0 aplikace Sonic Pi (Wikipedie) určené také pro výuku programování pomocí skládání hudby. Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
U příležitosti 30. výročí vydání počítačové hry Quake byla vydána nová epizoda s názvem Dawn of the Machine (Steam).
Vládní CERT upozorňuje (𝕏) na sérii bezpečnostních záplat (CVSS 9.9) v produktech Cisco řešících kritické zranitelnosti umožňující obejití autentizace, eskalaci oprávnění, vzdálené spuštění kódu a odepření služby. Úspěšné zneužití může útočníkům umožnit získat neoprávněný přístup k dotčeným systémům, kompromitovat zařízení Cisco Catalyst SD-WAN a Cisco IOS XE, spustit libovolný kód, zpřístupnit citlivé informace nebo narušit dostupnost postižených systémů.
Soud v americkém státě Nové Mexiko ve čtvrtek nařídil internetové společnosti Meta Platforms zaplatit 567 milionů dolarů (téměř 12 miliard Kč) za újmy, které její platformy působí mladým lidem. S přihlédnutím k dřívějšímu verdiktu tak má společnost celkem zaplatit 942 milionů dolarů, což je malý zlomek jejího ročního výnosu, který loni činil 60 miliard dolarů. Čtvrteční verdikt firmě také nařizuje, aby změnila způsob, jakým její
… více »PC_HOME (192.168.2.4) --> Router_HOME (192.168.2.1) -- > INTERNET --> Mikrotik_router(192.168.200.254) --> OpenVPN_server (192.168.200.108)Zde jsou konfigurační soubory openVPN: server.conf
port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh1024.pem mode server tls-server server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.200.0 255.255.255.0" route-up "route delete -net 10.8.O.O/24" route-up "route add -net 10.8.0.0/24 tunO" route 192.168.200.0 255.255.255.O keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log log /var/log/openvpn/openvpn.log verb 3client.ovpn
client dev tun proto udp remote ip_addr_Mikrotik 1194 resolv-retry infinite nobind persist-key persist-tun ca c:\\key\\ca.crt cert c:\\key\\client1.crt key c:\\key\\client1.key comp-lzo verb 3Port 1194 je na Mikrotiku NATován na adresu 192.168.200.108 v lokální síti za Mikrotikem. Spojení na OpenVPN server se mi provede bez problémů, ale nemohu si pingnout na žádnou adresu v lokální síti 192.168.200.0, kromě adresy 192.168.200.108. Ta funguje bez problémů. Hraji si s tím 3 dny. Pročetl jsem kde co, ale nějak se mi nedaří zprovoznit. Ještě připojuji routovací tabulky: OpenVPN server:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 192.168.200.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.200.254 0.0.0.0 UG 0 0 0 eth0Klient:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
===========================================================================
Seznam rozhraní
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff d3 93 db bc ...... TAP-Win32 Adapter V8
0x10004 ...00 11 2f d6 85 72 ...... Marvell Yukon Gigabit Ethernet 10/100/1000Ba
se-T Adapter, Copper RJ-45
===========================================================================
===========================================================================
Aktivní směrování:
Cíl v síti Síťová maska Brána Rozhraní Metrika
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4 20
10.8.0.4 255.255.255.252 10.8.0.6 10.8.0.6 30
10.8.0.6 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.8.0.6 10.8.0.6 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.2.0 255.255.255.0 192.168.2.4 192.168.2.4 20
192.168.2.4 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.2.255 255.255.255.255 192.168.2.4 192.168.2.4 20
224.0.0.0 240.0.0.0 10.8.0.6 10.8.0.6 30
224.0.0.0 240.0.0.0 192.168.2.4 192.168.2.4 20
255.255.255.255 255.255.255.255 10.8.0.6 10.8.0.6 1
255.255.255.255 255.255.255.255 192.168.2.4 192.168.2.4 1
Výchozí brána: 192.168.2.1
===========================================================================
Trvalé trasy:
Žádné
Děkuji za nakopnutí.
float mssfix 1500Bez těchto direktiv si nemohu pingnout ani 192.168.200.108.
tcpdump -i eth0 host 192.168.200.25 -na dostal jsem vypis
testVPN:~ # tcpdump -i eth0 host 192.168.200.25 -n 10:14:05.017133 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 197036 win 64135 10:14:05.018890 IP 192.168.200.108.22 > 192.168.200.25.4208: P 197168:197316(148) ack 781 win 9648 10:14:05.019168 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 197316 win 65535 10:14:05.020865 IP 192.168.200.108.22 > 192.168.200.25.4208: P 197448:197596(148) ack 781 win 9648 10:14:05.021145 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 197596 win 65255 10:14:05.022882 IP 192.168.200.108.22 > 192.168.200.25.4208: P 197728:197876(148) ack 781 win 9648 10:14:05.023255 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 197876 win 64975 10:14:05.024851 IP 192.168.200.108.22 > 192.168.200.25.4208: P 198008:198156(148) ack 781 win 9648 10:14:05.025122 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 198156 win 64695 10:14:05.026869 IP 192.168.200.108.22 > 192.168.200.25.4208: P 198288:198436(148) ack 781 win 9648 10:14:05.027168 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 198436 win 64415 10:14:05.027973 IP 192.168.200.108.22 > 192.168.200.25.4208: P 198436:198584(148) ack 781 win 9648 10:14:05.028868 IP 192.168.200.108.22 > 192.168.200.25.4208: P 198584:198732(148) ack 781 win 9648 10:14:05.030875 IP 192.168.200.108.22 > 192.168.200.25.4208: P 198864:199012(148) ack 781 win 9648 10:14:05.031150 IP 192.168.200.25.4208 > 192.168.200.108.22: . ack 199012 win 65535 ... 1582 packets captured 3799 packets received by filter 553 packets dropped by kernelPak jsem pustil
tcpdump -i tun0 host 192.168.200.25 -na dostal jsem vypis
testVPN:~ # tcpdump -i tun0 host 192.168.200.25 -n tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 10:14:15.887394 IP 10.8.0.6 > 192.168.200.25: ICMP echo request, id 512, seq 41496, length 40 10:14:16.703103 IP 10.8.0.6.1439 > 192.168.200.25.8888: S 3397256682:3397256682(0) win 16384 < mss 1368,nop,nop,sackOK> 10:14:19.713153 IP 10.8.0.6.1439 > 192.168.200.25.8888: S 3397256682:3397256682(0) win 16384 < mss 1368,nop,nop,sackOK> 10:14:21.394136 IP 10.8.0.6 > 192.168.200.25: ICMP echo request, id 512, seq 43288, length 40 10:14:25.717094 IP 10.8.0.6.1439 > 192.168.200.25.8888: S 3397256682:3397256682(0) win 16384 < mss 1368,nop,nop,sackOK> ... 30 packets captured 60 packets received by filter 0 packets dropped by kernelBohužel tcpdump nepoužívám a jaksi mi nedochází význam některých výstupů. Může poprosit o jejich dekódování popř. uvést správné parametry ke zjištění relevantních dat? Adresa 192.168.200.108 je adresa OpenVPN v lokální síti a adresa 192.168.200.25 je PC v lokální síti. Děkuji.
port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key # This file should be kept secret dh /etc/openvpn/dh1024.pem mode server tls-server server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.200.0 255.255.255.0" route-up "route delete -net 10.8.0.0/24" route-up "route add -net 10.8.0.0/24 tun0" keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log log /var/log/openvpn/openvpn.log verb 3
"0"v
/proc/sys/net/ipv4/ip_forwardVzdy musim pak davat rucne
echo 1 > /proc/...je to mozne nejak zajistit natvrdo, nebot co jsem vysledoval, tak to dela pri rekonfiguraci sitove karty nebo restartu firewallu. Pripominam, ze vse to jede na OpenSuSE 10.1. Po techto peripetich jsem schopen si pres VPN pingnout vsechno v siti 192.168.200.0/24, ale nemohu se pripojit na zadne sluzby na jednotlivych PC. Napr. na IP 192.168.200.25 vzdalenou plochu (podotykam, ze je povolena, nebot pres PPTP, pres ktere se taky nekdy pripojuji to funguje) a napr. na adrese 192.168.200.1 mi zase bezi VNC server, ktery taky normalne funguje. Naopak, kdyz se chci pripojit na vzdalenou plochu te masine kterou pristupuji do site 192.168.200.0/24, tak si v pohode na adrese 10.8.0.6, ktera je po pripojeni pres OpenVPN pridelena, spustim Vzdalenou plochu. Zrejme bude neco spatne nastaveno nekde na firewallu, ale bohuztel nevim kde. Firewall na OpenVPN serveru je vypnuty. Firewall Mikrotik by mel byt eliminovat tim, ze to bezi pres tunel OpenVPN a na lokalnich stanicich neni na obou strnach nepomuze ani vypnuty firewall (MS Windows XP) Po spusteni tcpdump dostanu nasledujici:
testVPN:/etc/openvpn # tcpdump -ni eth0 host 192.168.200.25 and port 3389 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:13:34.591367 IP 10.8.0.6.4011 > 192.168.200.25.3389: S 1216581081:1216581081(0) win 16384 < mss 1368,nop,nop,sackOK> 15:13:37.473343 IP 10.8.0.6.4011 > 192.168.200.25.3389: S 1216581081:1216581081(0) win 16384 < mss 1368,nop,nop,sackOK> 15:13:43.444803 IP 10.8.0.6.4011 > 192.168.200.25.3389: S 1216581081:1216581081(0) win 16384 < mss 1368,nop,nop,sackOK> 3 packets captured 6 packets received by filter 0 packets dropped by kernelDiky.
net.ipv4.ip_forward = 1ale nějak to nepomohlo. Při restartu se to opet v /proc/sys/net/ipv4/ip_forward nastavilo na "0". Co jsem vysledoval, tak to dělá to při startu a ukončeni firewallu. Díky
. route 10.8.0.0 255.255.255.0 push "route 192.168.200.0 255.255.255.0"a nastavím pouze
push "route 192.168.200.0 255.255.255.0 10.8.0.1 tun0"tak se mi VPN vubec nepřipojí. Jinak, že to mám doma na interním PC za routerem v síti 192.168.2.0/24 je vcelku jedno. Pokouším se přes VPN připojit i notebookem přes Dial-up a taky se stejným problémem. Pingnu si vše v síti 192.168.200.0/24, ale nemohu se připojit na žádnou službu na PC v té síti (SSH, VNC, TS apod.) Naopak však ano, ze sítě 192.168.200.0/24 (konkrétně z PC 192.168.200.25) se bez problému dostanu na vzdálenou plochu notebooku připojeného pře s VPN a Dial-up. Jinak nyní částečně funkční konfigurace je tato: server.conf (openSuSE 10.1)
port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key # This file should be kept secret dh /etc/openvpn/dh1024.pem mode server tls-server server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt route 10.8.0.0 255.255.255.0 push "route 192.168.200.0 255.255.255.0" keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log log /var/log/openvpn/openvpn.log verb 6client (MS Windows XP + SP2)
tls-client dev tun proto udp remote xxx.xxx.xxx.xxx 1194 pull ca c:\\key\\ca.crt cert c:\\key\\client1.crt key c:\\key\\client1.key resolv-retry infinite nobind persist-key persist-tun comp-lzo verb 3Díky
echo 1 > /proc/sys/net/ipv4/ip_forward) a zároveň nahodil maškarádu (iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE). A funguje. Proč to tak je nevím (nechtěl by se někdo vyjádřit?).
PS: Omlouvám se za reinkarnaci starého dotazu, ale tenhle jsem při hledání řešení objevil jako první, takže je solidní možnost, že to pomůže i někomu jinému.
Tiskni
Sdílej:
