V Bolzanu probíhá konference SFSCON (South Tyrol Free Software Conference). Jean-Baptiste Kempf, zakladatel a prezident VideoLAN a klíčový vývojář VLC media playeru, byl na ní oceněn cenou European SFS Award 2025 udělovanou Free Software Foundation Europe (FSFE) a Linux User Group Bolzano‑Bozen (LUGBZ).
Open-source minimalistický trackball Ploopy Nano byl po modelech modelech Classic a Thumb Trackball také aktualizován. Nová verze Nano 2 používá optický senzor PAW3222 a k původně beztlačítkovému designu přidává jedno tlačítko, které ve výchozí konfiguraci firmwaru QMK přepíná režim posouvání koulí. Sestavený trackball nyní vyjde na 60 kanadských dolarů (bez dopravy a DPH).
Github publikoval Octoverse 2025 (YouTube), tj. každoroční přehled o stavu open source a veřejných softwarových projektů na GitHubu. Každou sekundu se připojil více než jeden nový vývojář. Nejpoužívanějším programovacím jazykem se stal TypeScript.
Kit je nový maskot webového prohlížeče Firefox.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
Úřad pro ochranu hospodářské soutěže zahajuje sektorové šetření v oblasti mobilních telekomunikačních služeb poskytovaných domácnostem v České republice. Z poznatků získaných na základě prvotní analýzy provedené ve spolupráci s Českým telekomunikačním úřadem (ČTÚ) ÚOHS zjistil, že vzájemné vztahy mezi operátory je zapotřebí detailněji prověřit kvůli možné nefunkčnosti některých aspektů konkurence na trzích, na nichž roste tržní podíl klíčových hráčů a naopak klesá význam nezávislých virtuálních operátorů.
Různé audity bezpečnostních systémů pařížského muzea Louvre odhalily závažné problémy v oblasti kybernetické bezpečnosti a tyto problémy přetrvávaly déle než deset let. Jeden z těchto auditů, který v roce 2014 provedla francouzská národní agentura pro kybernetickou bezpečnost, například ukázal, že heslo do kamerového systému muzea bylo „Louvre“. 😀
Z upstreamu GNOME Mutter byl zcela odstraněn backend X11. GNOME 50 tedy poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
192.168.2.180 a open vpn ip 10.0.1.1
routa 192.168.1.0 255.255.255.0 10.0.1.100 10.0.1.1 1
Server
ip 10.0.1.100 a i 192.168.1.34 s gw 192.168.1.1
na pc za vpnserverem je ip 192.168.1.38 a pridal jsem tam routu
route add -net 10.0.1.0 netmask 255.255.255.0 gw 192.168.1.34
tohle mi uz bez problemu jelo, problem je v tom, ze jsem preinstaloval pc za vpnserverem (ip 192.168.1.38) a uz to nejede, nechapu proc. Firewall tam neni.
openvpn server
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 * 255.255.255.0 U 0 0 0 tap0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
pc 192.168.1.38
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 192.168.1.34 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
ani nevim jak sledovat kam to chodi, pomoci snort jsem zjistil, ze kdyz zadam u klienta 192.168.1.38 tak to dorazi na 10.0.1.100 a dal uz nevim jak. Traceroute nic neukazuje
(akorat bacha - tcpdump sedi na sitovce - pakety prichozi ze site slysi DRIV jak firewall, kdezto pakety odchazejici slysi PO firewallu. Takze jeden vidi prichozi paket, tcpdump ho ukaze, ale hned zanim ho tise zahodi firewall...
)
V tom navodu je pouzit tap interface... tam nevim. Pouzivam tun.
Mel jsem za to, ze pokud se pouzije tap, tak by mely byt pocitace jakoby ve stejne siti (tj. pak chodi broadcasty a spol). Pri pouziti tun, by se naopak melo openvpn chovat jako dalsi propojeni dvou odlehlych siti a pak se k tomu pristupuje jako k routovane siti. (push-route v konfigu serveru a podobne)... ale za toto tvrzeni bych pracku do ohne nadal...
ping cilovy_stroj, tak by Ti po ceste mel
tcpdump -i eth0 -n host cilovy_strojmel ukazat asi toto:
18:59:55.014080 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 1, length 64 18:59:55.014345 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 1, length 64 18:59:56.014399 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 2, length 64 18:59:56.014655 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 2, length 64 18:59:57.014400 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 3, length 64 18:59:57.014647 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 3, length 64... v tomto pripade sly packety jen na sousedni masinu a eth0 je interface, pres ktery to melo jit. a opakuji - pri prichodu na masinu je tcpdump pred firewallem a pri odchodu je zanim.
192.168.2.180
-------------------------------
| PC1 winxp,opevpn client |
-------------------------------
|
|
|
-------------- -------------- --------------
| hw router |---------| internet |--------| hw router |
-------------- -------------- --------------
|
|
192.168.1.34, 10.0.1.100 |
------------------------------- |
| PC2 Debian,opevpn server |---------------------|
------------------------------- |
|
192.168.38 |
------------------------------- |
| PC3 Debian,Gnome |---------------------|
-------------------------------
Routovaci tabulky
PC2 - Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 * 255.255.255.0 U 0 0 0 tap0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
PC3 - Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 192.168.1.34 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
v pripade ze na PC1 zadam ping 10.0.1.100 nebo ping 192.168.1.34 tak dostanu odpoved, v pripade ze zadam ping 192.168.1.38 tak jsem pomoci SNORT zjistil, ze na PC2 to dorazilo, ale dal uz nevim co s tim.
)
Na serveru pak muzes prubezne zkouset sedet s tcpdumpem na interfacech, pres ktere by_to_melo_jit(tm) a divat se jestli to opravdu jde a nejlepe v obou smerech.
Sranda je v tom, ze Ty na serveru jadru sice reknes, kudy routovat, ale je mozne, ze to nepozna "uvnitr" vpnka... (pokud to teda neni ten firewall
)
A z opacneho skopka: na svojem stroji mam v konfiguraku serveru pridane cca toto:
push "route 192.168.1.0 255.255.255.0" client-config-dir ccd route 192.168.2.0 255.255.255.0to push "route..." rika klientom, ze do 192.168.2.0/24 .... "na mne" a v /etc/openvpn/ccd (zalozit rucne) je soubor, pojmenovany podle klice klienta (kdyz byl klic pri vytvareni pojmenovan kareL, tak se soubor musi menovat kareL - vcetne velikosti pismen , predpoklada, ze kazdy klient ma SVUJ jedinecny klic) s obsahem:
ifconfig-push 10.8.0.18 10.8.0.17 iroute 192.168.2.0 255.255.255.0Nutno podotknout, ze ja sedim na tun interfacu a sit openvpnka mam na 10.8.0.0/24. To ifconfig-push slouzi k prideleni pevne adresy v ramci openvpn (aby po restartu serveru dostal stejnou), iroute nakrmi openvpnko (tj. ne primo kernel) informaci o tom, kam v ramci toho openvpn ma paket dal jit. V dusledku tim jde rozjet routovani i mezi klienty. Za potencialne nevhodnou syntaxi ifconfig-push se omlouvam, ale ted nemam tap kde vyzkouset (ano, su liny, nechce se mi ted budovat dalsi server) ... v Tvojem pripade to bude rozhodne v segmentu 10.0.1.0/24. Osobne jsem domaci server budoval podle navodu primo u atoru Za narknuti s wc3 se omlouvam, ale pisatel se tam taky domahal odpovedi. (v jeho pripade tam pred tim par doporuceni padlo ale vysledky nenapsal ...) Vyzkousej a dej vedet.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes 23:33:45.755624 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 10496, length 40 23:33:51.187211 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 10752, length 40 23:33:56.686788 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 11008, length 40 23:34:02.188073 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 11264, length 40na [PC3] se mi v tcpdump plete ssh, takze to leti moc rychle, nevim jak to odfiltrovat pouze na ICMP, ale i tak si myslim ze to tam nedorazi
tcpdump -i eth0 -n icmp and host 192.168.1.1preventivne bych doporucil sednout na tom pc2 i na druhy interface, at vis, ze ma snahu to poslat dal. (-i eth0) ....a uplne hloupy dotaz: mas na tom serveru povoleny forward?
cat /proc/sys/net/ipv4/ip_forwardby melo vypsat "1"...
Sam nejsu zadny odpornik, takze urcite bude dost lidi, ktere napadne jeste neco, co se muze zkusit.
(osobne jsem taky parkrat poslal prispevek o chvilu pozdej protoze mi trvalo nez jsem pocetl zelou diskusi a nasledne sesmolil odpoved
)
v pripade ze na PC1 zadam ping 10.0.1.100 nebo ping 192.168.1.34 tak dostanu odpoved, v pripade ze zadam ping 192.168.1.38 tak jsem pomoci SNORT zjistil, ze na PC2 to dorazilo, ale dal uz nevim co s tim
Co vám na PC2 řekne cat /proc/sys/net/ipv4/ip_forward ?
echo 1 > /proc/sys/net/ipv4/ip_forward
/etc/rc.local a máte posekáno (nebudete to muset po každém restartu nahazovat růčo).
Tiskni
Sdílej: