O víkendu probíhá konference OpenAlt 2025 (Stream). Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
Josef Průša představil novou velkoformátovou uzavřenou CoreXY 3D tiskárnu Prusa CORE One L a nový open source standard chytrých cívek OpenPrintTag i s novou přepracovanou špulkou.
Na GOG.com běží Autumn Sale. Při té příležitosti je zdarma hororová počítačová hra STASIS (ProtonDB: Platinum).
Ubuntu 25.10 má nově balíčky sestavené také pro úroveň mikroarchitektury x86-64-v3 (amd64v3).
Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
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: