VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Řešení dotazu:
Máme server (A) a server (B), potřebujeme propojit jejich síť do LAN přes tunel..Jedina veta, ktera dava smysl.. Bud Vam poskytovatel protuneluje VLAN, nebo to budete muset do neceho zabalit napriklad GRE, nebo L2TP. Mimochodem "nefunguje" neni odpoved..
Dotaz tak, jak je napsaný, nedává moc smysl. Napadají mne přinejmenším dvě interpretace:
1. Máte dvě lokální sítě a chcete je propojit tak, aby vám mezi nimi fungovalo všechno "jako kdybyste to propojil přímo drátem". Na to existují různé nástroje, v současné době bych asi doporučil vxlan, což je protokol, který byl navržen přesně pro tyhle účely. Samozřejmě je potřeba ten tunel nějak zabezpečit (např. IPsec - ale stačí cokoli, co umí tunelovat UDP provoz mezi jednou dvojicí portů).
Máte dvě lokální sítě používající adresy z rezervovaných rozsahů, stačilo by vám je proroutovat (nepotřebujete transparentnost až na úroveň ethernetu), ale bohužel používají kolidující rozsahy adres. To lze řešit tak, že budete oběma směry překládat adresy tak, že se pro každou síť bude ta druhá mapovat na nějaký jiný rozsah. Ne všem protokolům se to ale bude líbit (obecně bude mít problémy cokoli, co používá adresy i někde v aplikačním protokolu, jako u každého NATu). Ačkoli se to možná na začátku nezdá, v praxi je z dlouhodobého hlediska většinou nejlepší prostě jednu z těch dvou sítí přečíslovat.
Samozřejmě je ale možné, že jste myslel něco úplně jiného. Takže zkuste napsat pořádně, co vlastně potřebujete.
Všechny odpovědi jsme zvažovali.
Zvažoval jste i tuhle? "Takže zkuste napsat pořádně, co vlastně potřebujete." Jestli ano, škoda, že jste ji zavrhl.
#udp
iptables -t nat -A PREROUTING -d veřejná_ip_openvpn_serveru -p udp --dport 27015 -j DNAT --to-dest 172.27.22.2:27015
iptables -t nat -A POSTROUTING -d 172.27.22.2 -p udp --dport 27015 -j SNAT --to-source veřejná_ip_openvpn_serveru
#tcp
iptables -t nat -A PREROUTING -d veřejná_ip_openvpn_serveru -p tcp --dport 27015 -j DNAT --to-dest 172.27.22.2:27015
iptables -t nat -A POSTROUTING -d 172.27.22.2 -p tcp --dport 27015 -j SNAT --to-source veřejná_ip_openvpn_serveru
iptables -t nat -A POSTROUTING -s 172.27.22.2 -j SNAT --to-source veřejná_ip_openvpn_serverua staci vam pouze jeden. zamysli se jak ti chodi packety a potom se pozastav nad tim co jsi v tom POSTROUTINGU napsal ty a co ja. Idealni by bylo pokud by sis na tom serveru pustil tcpdump a krasne by jsi to tam videl.
iptables -t nat -A POSTROUTING -d 172.27.22.2 -j SNAT --to-source interni_vpn_ip_openvpn_serveruaby mu odpoved z virtualu sla ven pres branu pres kterou prisel dotaz. Ale tohle reseni je dost nevhodny a da se pouzit tak maximalne na sluzbu navazovanou jen zvenku, navic pokud mi nevadi, ze nebudu znat verejnou IP odkud to prislo. Pri zamyslenym pouziti se to muze chovat dost nepredvidatelne, coz se asi v tuhle chvili deje. V ramci testovani bych dve brany vypustil a virtualu nastavil napevno branu pres VPN. Pak bych zjistoval, jak se to chova z pohledu funkcnosti a odezvy, jestli tomu VPN nevadi a pak teprve bych se snazil zprovoznit pristup na virtual pres obe verejny IP.
CounterStrike klient --------> Debian server --------> Windows server Puvodni verejna IP Nova IP, je zde verejna ?Na to staci pouze DNAT portu na serveru debian na ten novy server, klidne muze byt i s verejnou IP a ani nepotrebujete VPN
Především mi přijde diskutabilní už sám nápad přístup na herní server, u kterého - pokud vím - jde především a skoro výhradně o latence, tlačit přes tunel do jiné lokality a dobrovolně tak přidávat zbytečné milisekundy (to v ideálním případě) navíc. Tím spíš, že podle
Server vše stíhá, ale jakmile na RDP spustím například nějakou webovou stránku, tak okamžitě VPN kolabuje. Linka je 100 Mbps.
(ať už je "RDP" cokoli) tam někde ještě bude nějaké úzké hrdlo s dlouhým bufferem a bez nějakého aspoň základního opatření, které by zabránilo bufferbloatu.
Když tam dá jen DNAT, tak se stane to, že server na novém IP bude pakety posílat přímo zpět na klienta a ten ty pakety zahodí, protože ty pakety budou mít jinou zdrojovou adresu než očekává.A proto se používá SNAT+DNAT. Jedná se o triviální TCP/UDP proxy setup, na který stačí pár pravidel v iptables. Používá se například když člověk potřebuje přenést traffic ze staré destinace na novou dřív než zajistí změny v DNS a dalších systémech.
Bohužel nemáme technologie Cisco, které by toto spojení jistě usnadnili.
Tahle víra, že všemocné Cisco řeší všechny problémy za všech okolností nejlépe, jak to jen lze, mne nepřestává fascinovat. Vzpomínám si na jednoho Cisco Certified Cosi, který když nebyl schopen přijít na to, proč je mnou navrhované efektivnější řešení problému špatně (skutečný důvod byl že špatně nebylo), prohlásil: "Přece kdyby to bylo k něčemu dobré, tak by to to Cisco nabízelo taky." :-)
Tiskni Sdílej: