Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
================ =================== |OpenVPN klient| --|domácí router|--> internet ---> |hardwarový router| --->_______místní síť_______________ ================ =================== | | | | | | | | ================ počítače v síti |OpenVPN server| ================ OpenVPN klient: obecně jakákoliv ip, která není v cílové síti, např. 192.168.55.23/24 hardwarový router (neumí vpn): vnější adresa veřejná, vnitřní 192.168.1.1/24 OpenVPN server: 192.168.1.2/24 počítače v síti: 192.168.1.0/24 (Neřeším teď samotné ip adresy vpn tunelu)Problém je, že pokud se chci z vpn klienta dostat na nějaký počítač v síti, pak se na něj nedostanu z jednoho prostého důvodu. Pakety nemají cestu zpátky, protože počítače v síti mají jako výchozí bránu hardwarový router. Teoreticky bych mohl udělat to, že kýžené pakety budu routovat z routeru zpět na openvpn server. Jenže to nemůže fungovat z toho důvodu, že pakety projdou prvním směrem z openvpn serveru, ale zpátky už cestují přes router do openvpn serveru tzn. se zahodí. Jako možné řešení je přidat všem klientům v síti routu pro vpn klienty na vpn server. To sice funguje, ale je to dost nepraktické a "ošklivé". Dalším možným řešením by bylo vyjmout openvpn server z místní sítě a vše na něj a z něj routovat přes hardwarový router - to ale bohužel nemohu, protože tento server slouží i jako dhcp server. Mohl bych použít virtuální ethernety, ale to je ještě prasáčtější řešení, než v případě routování jednotlivých klientů.
Teoreticky bych mohl udělat to, že kýžené pakety budu routovat z routeru zpět na openvpn server. Jenže to nemůže fungovat z toho důvodu, že pakety projdou prvním směrem z openvpn serveru, ale zpátky už cestují přes router do openvpn serveru tzn. se zahodí.A presne to fungovat bude (Ano, funguje. Mam to takhle nastavene, brana routuje VPN subnet na LAN IP VPN serveru). Z jakeho duvodu by se pakety mely zahazovat? Kde?
1. OpenVPN server -> klient 2. klient -> router -> OpenVPN serverTady je jasné, že že se stavová spojení nepodaří navázat. (router si hlídá handshake)
Tady je jasné, že že se stavová spojení nepodaří navázat. (router si hlídá handshake)Neplet si router a firewall - zatimco firewall filtruje provoz a pro to obvykle pouzivat sledovani spojeni (connection tracking) a tvori si tabulku spojeni pro navazana spojeni, tak router POUZE routuje, tzn. predava pakety a nezajima ho, jestli je ten packet soucastni nejakyho spojeni. Pokud je tedy HW router i Firewall, tak by bylo nutne nastavit neco na zpusob iptables zapisu
iptables -A FORWARD -j ACCEPT -i eth0 -o eth0
, kde eth0 je mistni sit, cili, pokud neco prijde z eth0 a ma to odchazet na eth0, tak to proste predat a nezajimat se.
Jinak dalsi moznost by byla, ze by ten OpenVPN pridelovat par adres tem VPN klientum ze stejneho rozmezi jako hlavni DHCP server. Rekneme hlavne DHCP server by daval 10-150, VPN by daval 151-200 a nebo ,jak pise bigbrambor, pouzit primo bridgovani (pokud se nepletu, v tom pripade se pouziva tap misto tun), coz by bylo ve tvem pripade zrejme to nejlepsi.
Jinak pokud bys chtel ten VPN server dat mezi HW router (DHCP) a mistni sit, tak bys na VPN serveru spustil akorat dhcprelay a ten by pak vsechny DHCP pozadavky z mistni site predaval na HW router a zaroven by VPN server sam routoval do VPN.
1/ jak pises, az na to ze pres firewall to projde, akorat budes mit vsude br0 misto eth0, a klient se do site dostane, protoze jde o komunikaci jiz navazaneho spojeniNo četl jsem, že standardní iptables firewall (používá ho shorewall) nemůže fungovat na linkové vrstvě v bridgování. Např. bych potřeboval omezit počet nějakých paketů za sekundu, povolené porty apod. ve směru tap0->eth0. Nicméně jsem našel obrázek http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png, podle kterého bych řekl, že by to fungovat mělo (iptables filter tabulka). Jak to tedy je?
Tiskni
Sdílej: