Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.0.1.0 10.0.1.2 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Sun Dec 10 23:29:45 2006 client/82.117.12.120:1473 MULTI: bad source address from client [192.168.1.5], packet droppedCo to znamená? Nastaveno podle http://4um.ocguru.cz/showthread.php?t=54902.
(provider) --> natovany port na openvpn server (192.168.1.2)a ten Route vypis co jsi poslal je z te masiny (192.168.1.2). A ty chces aby se nekdo pripojil z venku (s nastavenou ip 192.168.1.5) a pinkal v siti 192.168.1.0/24 ? Jesi to je spravne, tak bys mel zkusit pouzit tap zarizeni (ne tun), ktery premostis s tvoji eth0.
SERVER: dev tun local 192.168.1.2 port 1194 proto udp push "route 192.168.1.0 255.255.255.0 10.8.0.1" push "route 10.8.0.1" push "dhcp-option DNS x.x.x.x" #push "dhcp-option WINS 81.27.192.97" push "redirect-gateway" ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt log-append /etc/openvpn/log status /etc/openvpn/log/vpn.status 10 comp-lzo #keepalive 10 120 persist-tun persist-key verb 3 KLIENT: client dev tun proto udp remote f.f.f.f 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key comp-lzo verb 3Z klienta nedopinguju ani na 10.8.1.1, ze serveru ping 10.8.1.6(přidělený pro 192.168.1.5): operation not permitted
remote monsoon.no-ip.com tls-client dev tap pull nobind route 192.168.123.0 255.255.255.0 192.168.124.124 50 ca ca.crt cert monsoon_ntb.crt key monsoon_ntb.key comp-lzo verb 3 ns-cert-type serverserver:
mode server tls-server dev tap0 ifconfig 192.168.124.124 255.255.255.0 ifconfig-pool 192.168.124.125 192.168.124.140 255.255.255.0 ifconfig-pool-persist ipp.txt crl-verify /etc/openvpn/private/crl.pem ca /etc/openvpn/private/ca.crt cert /etc/openvpn/private/server.crt key /etc/openvpn/private/server.key dh /etc/openvpn/private/dh2048.pem log-append /var/log/openvpn status /var/run/openvpn/vpn.status 10 user openvpn group openvpn comp-lzo verb 3 keepalive 10 120
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.1.1 192.168.1.5 20
10.1.0.0 255.255.255.0 10.1.0.125 10.1.0.125 30
10.1.0.125 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.1.0.125 10.1.0.125 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.5 192.168.1.5 20
192.168.1.5 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.5 192.168.1.5 20
224.0.0.0 240.0.0.0 10.1.0.125 10.1.0.125 30
224.0.0.0 240.0.0.0 192.168.1.5 192.168.1.5 20
255.255.255.255 255.255.255.255 10.1.0.125 10.1.0.125 1
255.255.255.255 255.255.255.255 192.168.1.5 192.168.1.5 1
Výchozí brána: 192.168.1.1
na serveru ip route:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 10.1.0.0/24 dev tap0 proto kernel scope link src 10.1.0.124 default via 192.168.1.1 dev eth0 a route: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface localnet * 255.255.255.0 U 0 0 0 eth0 10.1.0.0 * 255.255.255.0 U 0 0 0 tap0 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Pokud jsem to správně pochopil, server (ve vnitřní síti) má tyto adresy:
eth0 192.168.1.2
tap0 10.8.1.1
Vnitřní síť má rozsah 192.168.1.0/24 a vy chcet na svém klientovi kdesi v internetu dát ping 192.168.1.x a dopingovat se.
Něco podobného jsem řešil nedávno.
Na serveru mám takového nastavení /etc/openvpn/server.ovpn:
dev tap comp-lzo server 10.8.1.0 255.255.255.0 status openvpn-status.log tls-server duplicate-cn crl-verify /etc/openvpn/revoked.pem dh /etc/openvpn/dh1024.pem ca /etc/openvpn/cacert.pem cert /etc/openvpn/server.crt key /etc/openvpn/server.key push "route 192.168.110.0 255.255.255.0" keepalive 10 60
Na klientu takovéto:
dev tap port 1194 verb 3 comp-lzo remote x.y.z.a pull tls-client ca xyservercacert.pem cert xy.crt key xy.key keepalive 10 60
pro vás je asi nejpodstatnější na serveru příkaz push a na klientovi příkaz
pull. Dále musí být na linuxu povolené routování (sysctl
net.ipv4.ip_forward
a příslušné routy povolené ve fw). Taktéž musíte mít
nastavené routování ve vnitřní síti tak aby vaše brána vše co je do podsítě VPN
10.8.1.0/255.255.255.0 směrovala na váš VPN server (192.168.1.2), to je potřeba
nastavit na vaší bráně (pochopil jsem že máte df gw na 193.168.1.1).
Zda vám funguje routování ve vnitřní síti ověříte pomocí
ping -I tap0 192.168.1.2 spuštěném na VPN serveru, pokud tento příkaz neprojde, je ve vnitřní
síti/na serveru cosi špatně, pokud projde, můžete začít řešit routování přes
VPN. Obecně ale musím říci, že není v typickém případě nastavovat nic na
VPN serveru ani na klientovi, protože příslušné routy si nahodí VPN sama, ale
naopak je třeba zajistit aby se 10.8.1.0/255.255.255.0 routovalo ve vnitřní
síti ne do internetu ale na VPN server.
Doufám, že jsem Vás pochopil správně.
Pomohlo poslat sem log z toho VPN klienta. Verb 3 nastaven máte, viděli bychom co se tam děje. Co vám na serveru vrátí příkaz sysctl net.ipv4.ip_forward? Co vám vrátí na serveru příkaz ping -I tap0 192.168.1.2? Máte povolené routování ve firewallu na serveru (nejlépe fw úplně vypnutý, alespoň po čas experimentů)?
Doplnil jste příkaz pull do konfigurace klienta, jak Vám radil někdo výše? Vaše brána ve vnitřní síti je, z výše uvedených nastavení, 192.168.1.2. Jak vám ten router routuje podsíť 10.1.0.1/255.255.255.0? Dopingujete se z nějakého počítače ve vnitřní síti na 10.1.0.1, tj. rozhranní serveru?
Obávám se že máte k vyřešení více nezávislých dílčích problémů najednou a bez odpovědí na alespoň některé (již několikrát položené) otázky Vám mohu jen těžko poradit něco užitečného.
***192.168.1.0/24*************192.168.1.0/24***
* 192.168.1.1 * * *
* 192.168.1.2 * VPN * 192.168.1.5 *
* 192.168.1.3 * * *
* ... * * *
***********************************************
192.168.1.2 > 192.168.1.5
192.168.1.2 < 192.168.1.5
Tiskni
Sdílej: