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.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Ahoj vsem,
resim problem propojeni dvou siti, ktere pouzivaji stejne adresni rozsahy. Jedna z moznosti by byla natovat obe podsite nekde na brane 1:1 na uplne jiny rozsah. Napada nekoho nejake jine reseni?
Podotykam, ze precislovani jedne podsite neni z duvodu rozsahlosti siti mozne...
Ano, prave tohle resim, proto se ptam jestli existuji nejake dalsi moznosti
Za natem prozatim nic neni, ty podsite jsou odeleny siti 192.168.x.x (jine site nez ty, ktere se prekryvaji). Bohuzel hybat s adresami by bylo dost problematicke. Jak uz jsem psal, mohlo by zabrat reseni, kdy bude fungovat nat 1:1 a pocitace ze vsech prekryvajicich se rozsahu (jsou to asi 4 rozsahy) namapovat napr. na adresy 172.16.x.x, ktere uz by v dane podsiti nebyly. To stejne pak udelat pro podsit na opacne strane.
Nevim jestli jsem to popsal dost jasne, pripadne vice vysvetlim.
Podle mě to tak jak píšete půjde a odpadá problém s tím, že by požadavek na druhý subnet zabloudil ve "stejném" prvním subnetu. Druhý "stejný" subnet totiž podle tohoto řešení pro druhou stranu neexistuje.
ip rule
) můžete rozhodovat podle příchozího rozhraní, takže byste mohl vybrat vždy routovací tabulku té druhé sítě. Problém by byl v tom, jak paket ze stanice v jedné síti dopravit na router místo počítače se stejnou IP adresou ve stejné síti. Šlo by to opět pomocí routovacích pravidel, ale jedině v případě, kdy dokážete nějak poznat, zda paket třeba na 192.168.1.1 má jít do stejné sítě, nebo do „té druhé“.
Každopádně bych se určitě snažil alespoň nějak ty sítě oddělit a připravovat se třeba na postupné přečíslování, protože i pouze s tím NATem bude dost změn, a budete s tím mít pořád nějaké problémy i v budoucnu. Takže ať už s tím budete dělat cokoli, dělejte to tak, abyste si tím zároveň připravoval cestu k přečíslování těch sítí.
presne tak, myslel sem problem, kdy pocitace ze site napr. 192.168.1.x potrebuji komunikovat s oddelenou siti 12.168.1.x
oprava - presne tak, myslel sem problem, kdy pocitace ze site napr. 192.168.1.x potrebuji komunikovat s oddelenou siti 192.168.1.x
Existuje nekolik moznosti jak toto udelat:
1, neroutovat ale udelat bridge (to uz je tu zmineno)
2, Napsat staticke routovaci tabulky pro vsechny pouzite IP adresy. To skutecne funguje!
3, ARP proxy.
4, NAT, ale potom nemuze komunikovat kazdy s kazdym. Ti co jsou za NATem nejsou zvenku videt.
a mozna i neco dalsiho.
4, NAT, ale potom nemuze komunikovat kazdy s kazdym. Ti co jsou za NATem nejsou zvenku videt.
Pokud se udělá překlad zdrojových i cílových adres, může komunikovat každý s každým bez omezení. Jen se musí řešení doplnit buď o přepisování DNS odpovědí na tom NATovacím stroji nebo o lokální DNS server. Rozlišení, který stroj je "v té druhé síti" tedy bude probíhat podle jména. Je to funkční, ale pain-in-the-ass řešení... (pro každý stroj, který má být "v druhé síti" dosažitelný, se musí udělat statické pravidlo)
Tiskni Sdílej: