Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Před sedmi lety společnost Valve představila fork projektu Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát počítačové hry do té doby běžící pouze ve Windows. Aktuální přehled podporovaných her na stránkách ProtonDB
Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
config setup conn base fragmentation=yes dpdaction=restart dpddelay=120s conn lan1 also=base keyexchange=ikev2 mobike=no left=1.1.1.1 leftsubnet=10.10.10.0/24 right=%any rightsubnet=192.168.101.0/24 authby=psk ike=aes128-sha1-modp1536 esp=aes128-sha1-modp1536 ikelifetime=1d lifetime=1h margintime=9m keyingtries=%forever rekey=no # auto=start auto=route conn lan2 also=base keyexchange=ikev2 mobike=no left=1.1.1.1 leftsubnet=10.81.0.0/16 right=%any rightsubnet=192.168.101.0/24 authby=psk ike=aes128-sha1-modp1536 esp=aes128-sha1-modp1536 ikelifetime=1d lifetime=1h margintime=9m keyingtries=%forever rekey=no auto=routestrongswan statusall
Connections: lan1: 1.1.1.1...%any IKEv2, dpddelay=120s lan1: local: [1.1.1.1] uses pre-shared key authentication lan1: remote: uses pre-shared key authentication lan1: child: 10.10.10.0/24 === 192.168.101.0/24 TUNNEL, dpdaction=restart lan2: child: 10.81.0.0/16 === 192.168.101.0/24 TUNNEL, dpdaction=restart Security Associations (1 up, 0 connecting): lan1[1]: ESTABLISHED 10 seconds ago, 1.1.1.1[1.1.1.1]...2.2.2.2[192.168.1.102] lan1[1]: IKEv2 SPIs: a0bb837a343ba52b_i cade29f30cf3c13a_r*, rekeying disabled lan1[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536 lan1{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf51c3da_i 0697cfc9_o lan1{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 524 bytes_o (7 pkts, 0s ago), rekeying disabled lan1{1}: 10.10.10.0/24 === 192.168.101.0/24 lan2{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cc888691_i 0698f9ae_o lan2{2}: AES_CBC_128/HMAC_SHA1_96/MODP_1536, 3114 bytes_i (27 pkts, 0s ago), 1128 bytes_o (16 pkts, 0s ago), rekeying disabled lan2{2}: 10.81.0.0/16 === 192.168.101.0/24MKT - RouterOS v6.43.7, WAN rozhranie ma privatnu IP (DHCP) 192.168.1.102 Vdaka za akukolvek radu.
Řešení dotazu:
Server ipsec1 10.10.10.0/24 | .............. MKT | | 192.168.101.0/24 192.168.101.0/24 | .............. ipsec2Tzn. z jednoho boxu mas dva tunely naraz?
Server ipsec1 10.10.10.0/24 |............. MKT | | 192.168.101.0/24 10.81.0.0/16 |............. ipsec2
conn
, ale v jednej conn
pridat oba subnety leftsubnet=10.10.10.0/24,10.81.0.0/16
? Lebo to som skusal, ale tiez to nefungovalo.
Ale keby si si spomenul, ako si to fixol, by bolo super :).
Specifies what to do if some of the SAs for this policy cannot be found:
- use - skip this transform, do not drop packet and do not acquire SA from IKE daemon
- require - drop packet and acquire SA (default)
- unique - drop packet and acquire a unique SA that is only used with this particular policy. It is used in setups where multiple clients can sit behind one public IP address (clients behind NAT).
Ale to dohodnutie roznych SA a pritom pouzit iba jednu asi uz bude bug (v pripade level=require).
shell# ip r g 192.168.101.10 192.168.101.12 via [ip.adresa.default.gw]] dev wan0 src 10.10.10.1 cachevracia src 10.10.10.1 - podla mna by tam mala byt verejna IP servera (v nasom priklade 1.1.1.1) a nie jeho lokalna (aspon tak som to pochopil, ze by to malo fungovat a v inych pripadoch ipsec to aj tak mam).
To je vždycky dobrý začátek: snažit se lokalizovat, kde přesně se pakety ztrácejí, pak už je většinou mnohem jednoduché poznat proč.
Další věci, na které by bylo dobré se podívat:
ip route show ip xfrm policy show ip xfrm state show
Případně jestli není problém v konfiguraci netfiltru - zejména překlady adres často způsobují problémy (hlavně příliš obecná pravidla pro maškarádu).
shell# ip xfrm policy show src 10.10.10.0/24 dst 192.168.101.0/24 dir out priority 375423 ptype main tmpl src 1.1.1.1 dst 2.2.2.2 proto esp spi 0x04ee0fc1 reqid 2 mode tunnel src 192.168.101.0/24 dst 10.10.10.0/24 dir fwd priority 375423 ptype main tmpl src 2.2.2.2 dst 1.1.1.1 proto esp reqid 2 mode tunnel src 192.168.101.0/24 dst 10.10.10.0/24 dir in priority 375423 ptype main tmpl src 2.2.2.2 dst 1.1.1.1 proto esp reqid 2 mode tunnel src 10.81.0.0/16 dst 192.168.101.0/24 dir out priority 379519 ptype main tmpl src 1.1.1.1 dst 2.2.2.2 proto esp spi 0x0f850dc5 reqid 1 mode tunnel src 192.168.101.0/24 dst 10.81.0.0/16 dir fwd priority 379519 ptype main tmpl src 2.2.2.2 dst 1.1.1.1 proto esp reqid 1 mode tunnel src 192.168.101.0/24 dst 10.81.0.0/16 dir in priority 379519 ptype main tmpl src 2.2.2.2 dst 1.1.1.1 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype mainProblem bude asi v tom, ze sa pouzije nespravna SA (bud server alebo MKT):
shell# tcpdump -vvnn -i wan0 'host 2.2.2.2 and port ! (1194 or 1201)' tcpdump: listening on wan0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:55:45.764133 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 608) 1.1.1.1.4500 > 2.2.2.2.4500: [no cksum] UDP-encap: ESP(spi=0x04ee0fc1,seq=0x7), length 580 22:55:45.768938 IP (tos 0x0, ttl 56, id 42957, offset 0, flags [none], proto UDP (17), length 608) 2.2.2.2.4500 > 1.1.1.1.4500: [no cksum] UDP-encap: ESP(spi=0xcd609f7f,seq=0x10), length 580 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel shell# strongswan statusall | grep '04ee0fc1\|cd609f7f' lan{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_o shell# tcpdump -vvnn -i wan0 'host 2.2.2.2 and port ! (1194 or 1201)' tcpdump: listening on wan0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:55:57.016446 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1024) 1.1.1.1.4500 > 2.2.2.2.4500: [no cksum] UDP-encap: ESP(spi=0x0f850dc5,seq=0x3), length 996 22:55:57.022014 IP (tos 0x0, ttl 56, id 42958, offset 0, flags [none], proto UDP (17), length 1024) 2.2.2.2.4500 > 1.1.1.1.4500: [no cksum] UDP-encap: ESP(spi=0xcd609f7f,seq=0x13), length 996 ^C 3 packets captured 4 packets received by filter 0 packets dropped by kernel shell# strongswan statusall | grep '0f850dc5\|cd609f7f' vpn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0be4177_i 0f850dc5_o lan{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_oPrvy ping a grep, ktory funguje, je z LAN (10.10.10.0/24) a "pouzije" sa rovnaka SA. Druhy ping, nefunkcny, je z VPN (10.81.0.0/16) a pouziju sa obe SA.
shell# strongswan statusall ... Connections: lan: 1.1.1.1...%any IKEv2, dpddelay=120s lan: local: [1.1.1.1] uses pre-shared key authentication lan: remote: uses pre-shared key authentication lan: child: 10.10.10.0/24 === 192.168.101.0/24 TUNNEL, dpdaction=restart vpn: child: 10.81.0.0/16 === 192.168.101.0/24 TUNNEL, dpdaction=restart Security Associations (1 up, 0 connecting): lan[1]: ESTABLISHED 21 minutes ago, 1.1.1.1[1.1.1.1]...2.2.2.2[192.168.1.102] lan[1]: IKEv2 SPIs: 059f7792a6358633_i fdbfb613553f93e8_r*, pre-shared key reauthentication in 23 hours lan[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536 vpn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0be4177_i 0f850dc5_o vpn{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i (0 pkts, 107s ago), 2856 bytes_o (3 pkts, 1212s ago), rekeying in 2 seconds vpn{1}: 10.81.0.0/16 === 192.168.101.0/24 lan{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cd609f7f_i 04ee0fc1_o lan{2}: AES_CBC_128/HMAC_SHA1_96/MODP_1536, 30444 bytes_i (305 pkts, 0s ago), 8100 bytes_o (70 pkts, 0s ago), rekeying in 58 seconds lan{2}: 10.10.10.0/24 === 192.168.101.0/24ipsec.conf
config setup # strictcrlpolicy=yes # uniqueids = no conn base fragmentation=yes dpdaction=restart dpddelay=120s conn lan also=base keyexchange=ikev2 mobike=no left=1.1.1.1 leftsubnet=10.10.10.0/24 right=%any rightsubnet=192.168.101.0/24 authby=psk ike=aes128-sha1-modp1536 esp=aes128-sha1-modp1536 ikelifetime=1d lifetime=30m margintime=5m keyingtries=%forever auto=route conn vpn also=base keyexchange=ikev2 mobike=no left=1.1.1.1 leftsubnet=10.81.0.0/16 right=%any rightsubnet=192.168.101.0/24 authby=psk ike=aes128-sha1-modp1536 esp=aes128-sha1-modp1536 ikelifetime=1d lifetime=30m margintime=5m keyingtries=%forever auto=route1.1.1.1 - verejna IP servera 2.2.2.2 - verejna IP MKT (skryty za S-NAT)
neprejde to uz bud do tunela, alebo to z neho nevyjde na lokalnom serveri (je tam trafik, takze je problem odsledovat ESP pakety)
Tak si vyfiltrujte jen ESP pakety s konkrétním SPI.
Tiskni
Sdílej: