Vývoj programovacího jazyka Zig byl přesunut z GitHubu na Codeberg. Sponzoring na Every.
Stejně jako GNOME i KDE Plasma končí s X11. KDE Plasma 6.8 poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
Poslanci Evropského parlamentu dnes vyzvali k výraznému zvýšení ochrany nezletilých na internetu, včetně zákazu vstupu na sociální sítě pro osoby mladší 16 let. Legislativně nezávazná zpráva, kterou dnes odsouhlasil Evropský parlament poměrem 493 hlasů pro ku 92 proti, kromě zavedení věkové hranice 16 let pro využívání sociálních sítí, platforem pro sdílení videí či společníků s umělou inteligencí (AI) vyzývá také k zákazu … více »
Doom v KiCadu nebo na osciloskopu? Žádný problém: KiDoom: Running DOOM on PCB Traces a ScopeDoom: DOOM on an Oscilloscope via Sound Card.
Po AlmaLinuxu byl v nové stabilní verzi 10.1 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Open source reimplementace počítačových her Tomb Raider I a Tomb Raider II spolu s dalšími vylepšeními a opravami chyb TRX byla vydána ve verzi 1.0. Jedná se o sloučení projektů / enginů TR1X a TR2X do jednoho TRX. Videoukázka na YouTube.
Společnost Seznam.cz spouští konverzační nástroj založený na umělé inteligenci Seznam Asistent. Asistent využívá vlastní jazykový model SeLLMa a dočasně i komerční modely od OpenAI provozované v evropských datacentrech prostřednictvím Microsoft Azure. Dlouhodobým cílem Seznamu je provozovat Asistenta výhradně na interních jazykových modelech a ve vlastních datových centrech.
Software LibrePods osvobozuje bezdrátová sluchátka AirPods z ekosystému Applu. Exkluzivní funkce AirPods umožňuje využívat na Androidu a Linuxu. Díky zdokumentování proprietárního protokolu AAP (Apple Accessory Protocol).
Byl vydán AlmaLinux OS 10.1 s kódovým názvem Heliotrope Lion. S podporou Btrfs. Podrobnosti v poznámkách k vydání.
Placená služba prohledávání zprostředkovatelů dat a automatického odstraňování uniklých osobních údajů Mozilla Monitor Plus bude 17. prosince ukončena. Bezplatná monitorovací služba Mozilla Monitor bude i nadále poskytovat okamžitá upozornění a podrobné pokyny k omezení rizik úniku dat. Služba Mozilla Monitor Plus byla představena v únoru loňského roku.
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: