Bezpečnostní specialista Graham Helton z Low Orbit Security si všímá podezřelých anomálií v BGP, zaznamenaných krátce před vstupem ozbrojených sil USA na území Venezuely, které tam během bleskové speciální vojenské operace úspěšně zatkly venezuelského diktátora Madura za narkoterorismus. BGP (Border Gateway Protocol) je 'dynamický směrovací protokol, který umožňuje routerům automaticky reagovat na změny topologie počítačové sítě' a je v bezpečnostních kruzích znám jako 'notoricky nezabezpečený'.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl 3,58 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 26,32 %. Procesor AMD používá 67,43 % hráčů na Linuxu.
V Las Vegas probíhá veletrh CES (Consumer Electronics Show, Wikipedie). Firmy představují své novinky. Například LEGO představilo systém LEGO SMART Play: chytré kostky SMART Brick, dlaždičky SMART Tagy a SMART minifigurky. Kostka SMART Brick dokáže rozpoznat přítomnost SMART Tagů a SMART minifigurek, které se nacházejí v její blízkosti. Ty kostku SMART Brick aktivují a určí, co má dělat.
Vládní CERT (GovCERT.CZ) upozorňuje (𝕏) na kritickou zranitelnost v jsPDF, CVE-2025-68428. Tato zranitelnost umožňuje neautentizovaným vzdáleným útočníkům číst libovolné soubory z lokálního souborového systému serveru při použití jsPDF v prostředí Node.js. Problém vzniká kvůli nedostatečné validaci vstupu u cest k souborům předávaných několika metodám jsPDF. Útočník může zneužít tuto chybu k exfiltraci citlivých
… více »V úterý 13. ledna 2025 se v pražské kanceláři SUSE v Karlíně uskuteční 5. Mobile Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj a související infrastrukturu. Akci pořádá David Heidelberg.
… více »Už je 14 dní zbývá do začátku osmého ročníku komunitního setkání nejen českých a slovenských správců sítí CSNOG 2026. Registrace na akci je stále otevřená, ale termín uzávěrky se blíží. I proto organizátoři doporučují, aby se zájemci přihlásili brzy, nejlépe ještě tento týden.
… více »Rok 2026 sotva začal, ale už v prvním týdnu se nashromáždilo nezvykle mnoho zajímavostí, událostí a zpráv. Jedno je ale jisté - už ve středu se koná Virtuální Bastlírna - online setkání techniků, bastlířů a ajťáků, kam rozhodně doražte, ideálně s mikrofonem a kamerou a zapojte se do diskuze o zajímavých technických tématech.
Dějí se i ne zcela šťastné věci – zdražování a nedostupnost RAM a SSD, nedostatek waferů, 3€ clo na každou položku z Číny … více »Vývojáři GNOME a Firefoxu zvažují ve výchozím nastavení vypnutí funkce vkládání prostředním tlačítkem myši. Zdůvodnění: "U většiny uživatelů tento X11ism způsobuje neočekávané chování".
Nástroj pro obnovu dat GNU ddrescue (Wikipedie) byl vydán v nové verzi 1.30. Vylepšena byla automatická obnova z disků s poškozenou čtecí hlavou.
Protokol IPv6 má již 30 let. První návrh specifikace RFC 1883 je z prosince 1995.
Dobry den,
Mam tu server se dvema interfaci. eth0 172.16.1.x - lokalni sit. eth1 172.16.13.x je inet. Bezi na nem openvpn se subnetem 172.16.2.x. Server ma adresu 172.16.1.10.
Dale tu mam klienta vpn windows xp 192.168.2.x. Podarilo se mi proroutovat az na adresu serveru 172.16.1.10, problem nastava kdyz se chci dostat na dalsi zarizeni v rozsahu 172.16.1.x. Muzete mi prosim poradit co dal?
Moc Dekuji
upresneni:
vpn mam pres tap.
Routy na strane klienta:
===========================================================================
===========================================================================
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.57 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.16.1.0 255.255.255.0 172.16.2.2 172.16.2.2 1
172.16.2.0 255.255.255.0 172.16.2.2 172.16.2.2 30
172.16.2.2 255.255.255.255 127.0.0.1 127.0.0.1 30
172.16.255.255 255.255.255.255 172.16.2.2 172.16.2.2 30
192.168.2.0 255.255.255.0 192.168.2.57 192.168.2.57 20
192.168.2.57 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.2.255 255.255.255.255 192.168.2.57 192.168.2.57 20
224.0.0.0 240.0.0.0 172.16.2.2 172.16.2.2 30
224.0.0.0 240.0.0.0 192.168.2.57 192.168.2.57 20
255.255.255.255 255.255.255.255 172.16.2.2 20005 1
255.255.255.255 255.255.255.255 172.16.2.2 10008 1
255.255.255.255 255.255.255.255 172.16.2.2 6 1
255.255.255.255 255.255.255.255 172.16.2.2 172.16.2.2 1
255.255.255.255 255.255.255.255 172.16.2.2 2 1
255.255.255.255 255.255.255.255 172.16.2.2 30004 1
255.255.255.255 255.255.255.255 192.168.2.57 192.168.2.57 1
Výchozí brána: 192.168.2.1
===========================================================================
Takhle nastavene to dojede na tu 172.16.1.10 nikoliv do celeho subnetu.
Na strane serveru to vypada takto.
172.16.13.0 0.0.0.0 255.255.255.192 U 0 0 0 eth1
172.16.2.0 172.16.2.1 255.255.255.0 UG 0 0 0 tap0
172.16.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.2.0 172.16.2.2 255.255.255.0 UG 0 0 0 tap0
192.168.2.0 172.16.2.1 255.255.255.0 UG 0 0 0 tap0
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 172.16.13.1 0.0.0.0 UG 0 0 0 eth1
Ze by se neco muselo nastavit v IPTABLES?
IP forwarding zapnut?
Ano zapnut. Routy jsem pridaval manualne pres cmd. Nemusi to byt nejak v konfiguraku?
server :
dev tap0
proto tcp-server
port 1194
mode server
server 172.16.2.0 255.255.255.0
status /tmp/openvpn
tls-auth /etc/openvpn/secret.key 0
keepalive 10 30
client-to-client
max-clients 6
verb 3
tls-server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
user openvpn
group openvpn
comp-lzo
klient:
remote 213.192.17.8
proto tcp-client
port 1194
dev tap
client
mute-replay-warnings
verb 3
persist-tun
persist-key
tls-auth C:\\ssh\\secret.key 1
user openvpn
group openvpn
tls-client
ca C:\\ssh\\ca.crt
cert C:\\ssh\\klient1.crt
key C:\\ssh\\klient1.key
comp-lzo
Podívejte, kam vám pingy odchází z klienta, já tam nějak nevidím, jak se z klienta routuje provoz do 172.16.13.0. V konfiguráku serveru by měla být direktiva "push route" (nebo tak něco), která "vnutí" klientovi routování do další sítě. Možná to jde nějak udělat i v konfiguráku klienta.
toto uz asi mas:
# Allow TAP interface connections to OpenVPN server
iptables -A INPUT -i tap+ -j ACCEPT
pridaj este toto (vyzera, ze je nie je povoleny forwarding z tap0 na cokolvek:
# Allow TAP interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tap+ -j ACCEPT
ak to nepomoze, tak wireshark na tap0 a eth0, aby si zistil, kde tie pakety chodia.
ano, toto je dobry nastrel. tu by mohol byt problem tiez. stroje v 1.x budu ale pravdepodobne mat default route na 1.10 - ktory by uz mal pakety poslat spat do tap (ACCEPT rule pre forwarding tap>eth0 by malo obsahovat myslim state=RELATED,ESTABLISHED, ale tymto som si uz neni uplne isty)
Tiskni
Sdílej: