Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Jde o to, proč když je k dispozici 1 veřejná IP adresa, tak, abych se dostal k více počítačům ve vnitřní síti, tak je nutné používat pomůcky typu přesměrování portů, třeba abych se dostal na svůj PC na webserver, tak musím na firewallu přesměrovávat port 80081 na 80 vnitřní sítě.
Absolutně nechápu proč to prostě nejde jednodušeji. Moje představa je taková. V internetu na DNS by bylo uvedeno, že třeba doména mojedomacidomena.cz odkazuje na IP adresu 90.178.50.128
*.mojedomacidomena.cz IN A 90.178.50.128
Když bych chtěl třeba pc.mojedomacidomena.cz, tak by můj router odpověděl, že se nachází na IP adrese 10.0.0.2 a dále by komunikace probíhala mezi těmito dvěma body. V případě, že bych zvenku zadal ntb.mojedomacidomena.cz, router by odpověděl 10.0.04 a zase by komunikace běžela mezi těmito dvěma body, bez směšné maškarády s porty.
Prostě klient z venku by věděl, že má požadavek hledat na IP adrese 90.178.50.128 a router by příchozí požadavky jej přesměrovával na 10.0.0.2, nebo cokoliv jiného. Proč vlastně něco takového nejde udělat?
Tiskni Sdílej:
Teď už ej to stejně zbytečné, nasaď ipv6 a jsi v suchu
na 3. (a případně nižší) vrstvějako ze by routoval na druhe vrstve?
pak má k dispozici z packetů pouze IP adresyjo? a jak potom delaj ten NAT?
Pokud pracuje jen na 3. (a případně nižší) vrstvěU toho jak je to napsane mam problem s vykladem, bud to chapu tak ze operuje automaticky i na nizsich vrstvach(bez toho by to nefungovalo) a nema to cenu zminovat nebo jak jsem si to vylozil ja: dela rozhodnuti na treti vrstve pripadne dela rozhodnuti na nizsi vrstve. Coz se mi samozrejme nezda. Nemam v umyslu se hadat, jen naznacuju jak mi to puvodne vyznelo a proc jsem reagoval jak jsem reagoval.
přesměrovávat port 80081Tak to steží . Jinak udělat by to jít mohlo, otázka je do jaké míry by bylo řešení kompatibilní se stávajícíma řešeníma. Jinak to protunelování NATu jde třeba pomocí http://en.wikipedia.org/wiki/Source_routing .
třeba pc.mojedomacidomena.cz, tak by můj router odpověděl, že se nachází na IP adrese 10.0.0.2 a dále by komunikace probíhala mezi těmito dvěma body. V případě, že bych zvenku zadal ntb.mojedomacidomena.cz, router by odpověděl 10.0.04 a zase by komunikace běžela mezi těmito dvěma bodyMe prijde ze chces aby kazdy router fungoval jako DNS server a odpovidal na dotazy adresama z privatnich rozsahu. Kdyz klient dostane odpoved 10.0.0.2 a kdo to potom bude routovat a hlavne kam?
Prostě klient z venku by věděl, že má požadavek hledat na IP adrese 90.178.50.128 a router by příchozí požadavky jej přesměrovával na 10.0.0.2, nebo cokoliv jiného. Proč vlastně něco takového nejde udělat?sakra tohle jsem nejak prehledl, jaky by pak byl rozdil mezi tim co ty navrhujes a NATem? Jak by router poznal kam to presmerovat do vnitrni site na urcite IPcko kdyz v IP paketu je jen cilova addresa a v tct/udp zas jenom port? A ted si predstave ze je tech NATu za sebou vic...
V mé úvaze se jedná o zamyšlení, proč není TCP/IPv4 navrženo tak, aby něco takového umělo, případně proč do něj někdo nějakou takovou funkcionalitu nenavrhnul.No hlavně proto, že celý NAT je strašlivý bastl, který porušuje základní principy fungování TCP/IP a ačkoliv ve většině případů funguje, občas, když není zrovna správná fáze Jupiterových měsíců, se něco rozsype a rozhodně nelze ani trochu mluvit o tom, že by do chování protokolů zapadal.
a ta ho odkáže na vnitřní IP adresu 10.0.0.2Jak by měl takový odkaz proběhnout? 10.0.0.2 má na domácí síti skoro každý, jak bude klient vědět s kterou 10.0.0.2 má komunikovat? Pokud chcete navrhnout, aby se adresa zapisovala stylem "10.0.0.2 poblíž 90.178.50.128", tak jste jen zvýšil délku adresy na dvojnásobek - což je přístup, který používá IPv6 (ale délka je čtyřnásobná). PS. nevím jestli dostatečně chápete rozdíl mezi DNS a IP. Internet je víceméně schopen funkce i bez DNS, IP komunikace probíhá mezi dvěma body které mají jednoznačně dané IP adresy pevné délky. DNS je jen tabulka pro lidi, která ukazuje jménem na IP adresu. V IP paketech žádná jména nejsou. Rozsah adres 10.0.0.0 - 10.255.255.255 (a další) je tzv. privátní a mají smysl vždy jen v rámci jedné organizace. Proto nemůžete na tyto adresy zvenčí nic poslat, protože každý může mít adresu 10.x a nebylo by jasné, ze které sítě to má být.
Přehlížíte příčinu problému – že chybí veřejné adresy. A řešení samozřejmě existuje – IPv6.
Pokud mermomocí chcete řešit IPv4, tak můžete použít source routing. Nicméně z rozumných důvodů jej směrovače ignorují.
Jinak ještě existuje jeden potrhlý vědec, který se snaží nahradit agregované IP směrování vyšší vrstvou, kde se směruje podle obsahu (názvů vlastností a jejich hodnot konkrétních nebo abstraktních objektů). Něco jako byl přechod od spojované telefonní sítě k přepojované IP, akorát o úroveň výše. (Google uspořádal na toto téma jeho přednášku, video se dá stáhnout, ale zapomněl jsem odkud.) Nicméně sám přiznává, že spousta problémů není dořešena, případně jejich složitost je značně nepraktická.
Ano, to je dobrý postřeh.
Rozdíl ale je ten, že aplikace se pak nepřipojuje na transportní adresu (transportní protokol, sítová adresa a číslo portu), ale na službu v doméně.
Pak by ale bylo třeba, aby takové adresování uměly všechny klienty, všechny servery (jakési UPnP s registrací DNS záznamů), aby bezpečnostní mechanismy pracovaly s těmito identifikátory (například porovnávání jmen v certifikátech, firewally) a tak dále.
Takže vzkaz tazateli: Je to skoro tak složité, jako třeba nasadit IPsec nebo IPv6.
Proč vlastně něco takového nejde udělat?Protože před otevřením WinBoxu by bylo vhodné si o tom vůbec něco přečíst.
/etc/hosts
podle toho, zda jsem byl doma nebo jinde)
Pro HTTP ale pokud vím nic takového neexistuje.Use of SRV records in conjuction with HTTP and URIs.