Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »GHC (Glasgow Haskell Compiler, Wikipedie), tj. překladač funkcionálního programovacího jazyka Haskell (Wikipedie), byl vydán ve verzi 9.10.1. Přehled novinek v poznámkách k vydání.
Po 9 týdnech vývoje od vydání Linuxu 6.8 oznámil Linus Torvalds vydání Linuxu 6.9. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.
Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Ř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: