Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
28.7.2008 16:33
David Watzke | skóre: 74
| blog: Blog...
| Praha
cd /etc/init.d && ln -s net.lo net.sit0a pak přidat do
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz/etc/conf.d/net
link_sit0="eth0" # eth0 je internet
config_sit0="ip6to4"
depend_sit0() {
need net.eth0
}
Toto je alternativa pouze k
iface sit0 inet6 static pre-up /sbin/ip tunnel add sit0 mode sit pre-up /sbin/ip link set sit0 up address 2002:XXXX:ZZZZ::1 netmask 16 gateway ::192.88.99.1Ale je stejne to ma gentoo vyreseno hezci nez stable deb
28.7.2008 22:17
David Watzke | skóre: 74
| blog: Blog...
| Praha
Si asi moc daleko nedocetl - asi ani na konec prvni vetySpíš jsem reagoval na tvoje
Jak tyto hodnoty nastavit po restartu se bohuzel casto lisi od distribuce, dale pro debian (a ubuntu)a doplnil info pro Gentoo. Jinak v6 firewall zatím nepoužívám - mám jen
iptables -A INPUT -i eth0 -p ipv6 -j ACCEPTa prázdno v ip6tables, ale dělá se to snadno, stejně jako u v4 - nastavěj se pravidla, potom
/etc/init.d/ip6tables savea pak stačí ip6tables přidat do nějakýho runlevelu.
Takoveto packety neprojdou pres NAT, takze je potreba vse nastavovat na stroji s verejnou ip.A jsem tam kde jsem byl
Samozrejme mluvim vo zaNATovanem pripojeni. Ten, kdo ma verejnou IPv4, imho ani moc IPv6 nepotrebuje. Jediny, co se pro nej zmeni bude ze si uz nebude svoji adresu tak snadno pamatovat. A bude cool mezi geeky.
29.7.2008 19:14
David Watzke | skóre: 74
| blog: Blog...
| Praha
.
30.7.2008 09:34
David Watzke | skóre: 74
| blog: Blog...
| Praha
), ale adminum odpadne par problemu - no a ty jeste zavaznejsi snad jeste pred tim nez se objevi. Ale mozna mas pravdu a udrzovat ty workaroundy "naporad" by vyslo levneji. Jiste ze ty to tunnely nejsou nic vic nez tunnely
Proste je potreba presvedcit ISP aby postupne presli na IPv6, jenze, uprimne, kolik z nich je ochotno takovy narocny krok podstoupit...
Benefit je tam, že předtím měli public IP jednu na celou síť, teďka maj jednou na každej počítač.No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.
No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.Ve své síti můžeš nasadit firewall na hraniční router.
Pokud potrebuju nakou sluzbu na nakym pocitaci z vnitrni site propojit s necim z venku, naroutuju prislusnej port/porty ne?A když ji potřebuješ na dvou počítačích tak uděláš co?
No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.Pokud nebude dosažitelný vůbec, můžeš odpojit kabel.
Ja preferuju reseni, kdy nemusim mit na kazdym pocitaci super silnej firewall. Pokud potrebuju nakou sluzbu na nakym pocitaci z vnitrni site propojit s necim z venku, naroutuju prislusnej port/porty ne?Taky preferuju toto řešení, ale s veřejnými adresami. Já radši bezpečnost vyřešenou pořádně a bez zkriplených služeb.
Nojo, nekdo zas predpoklada ze kdyz neni na kazdym pocitaci public IP tak jsou zkrpleny sluzby...A nejsou snad? FTP - nefunguje v normálním režimu. Podle conntrack modulů dále nefungují IRC, SIP, H.323 a dost dalších. Přenášení souborů v Jabberu a dalších IM sítích - nefunguje. Torrent a další P2P - zpravidla fungují hůř. A tak dál. Tohle všechno jsou věci, které obtěžují normálního uživatele, který je za NATem a kterému je to, že si někdo může forwardovat porty, úplně k ničemu. Protože k čemu je mi, že lze forwardovat porty, když Jabber prostě čeká, že soubory se přenášejí na 8010 a tečka.
Pokud potrebuju ve firme FTP, udelam jeden server s public IP pristupnou jak zvenku tak zevnitr (vicero interface) a bude to ne?Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone a dve ruzny konfigurace ftp serveru - oproti reseni s dostatkem adres a firewallu bez NAT.
Proč?Pokud potrebuju ve firme FTP, udelam jeden server s public IP pristupnou jak zvenku tak zevnitr (vicero interface) a bude to ne?Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone
a dve ruzny konfigurace ftp serveruProč?
- oproti reseni s dostatkem adres a firewallu bez NAT.Veřejná IPv4 adresa funguje stejně dobře jako veřejná IPv6, problém vidím v počtu adres.
Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone Proč?V lokalni siti budes prece ke sluzbe pristupovat pres jine ip nez z venku.
a dve ruzny konfigurace ftp serveru Proč?www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html , samozrejme ze tuto hodnotu muzou nejake ftp servery resit chytreji, ale potom te NAT omezuje na pouziti jen vyvoleneho kodu - a to je jeste horsi.
Proč? Nevidím žádný důvod a ani to tak nedělám.Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone Proč?V lokalni siti budes prece ke sluzbe pristupovat pres jine ip nez z venku.
FTP sice nepoužívám, ale ani k tomuhle nevidím rozumný důvod. Pokud je rozumně nakonfigurovaná síť, tak ani jeden z těch dvou problémů nenastane.a dve ruzny konfigurace ftp serveru Proč?www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html , samozrejme ze tuto hodnotu muzou nejake ftp servery resit chytreji, ale potom te NAT omezuje na pouziti jen vyvoleneho kodu - a to je jeste horsi.
Zajimavy.To jistě.
Ten ftp server je za DNAT.To je nová informace, kterou jsi asi zapoměl napsat.
Jak to nastavis aby packety chodily s odpovidajici src MACIP protokol žádný MAC adresy nezná (MAC adresy jsou o vrstvu níž). Takže nezájem, do toho FTP serveru ani klientu vůbec nic neni.
a src IPPokud by server nebyl za DNAT, vůbec nic by se neřešilo, takhle v přidáš nějaký pravidlo navíc.
a nechodil veskery traffic pres gw?Proč? Od čeho ji máme? (Teda pokud to s tím "veškterý traffic" nemyslíš obecněji než jsem to pochipil, ale to by nenastalo.)
To je nová informace, kterou jsi asi zapoměl napsat.Nojo, spatne jsem precetl ten kralykuv prispevek - auu
Ale v tom pripade je to cely uplne mimo
Ale jo kdyz na gw nastavis DNAT i pro -i lokalni_if, tak ti ten packet (ktery z lokalu posles na ftp://public_ip:ftpport ) pak na ftp server prijde stejnej jak z lokalu az na src MAC adresu - a system ho pak muze zahoditJak to nastavis aby packety chodily s odpovidajici src MACIP protokol žádný MAC adresy nezná (MAC adresy jsou o vrstvu níž). Takže nezájem, do toho FTP serveru ani klientu vůbec nic neni.
Proč? Od čeho ji [gw] máme?Protoze druha moznost je udelat DNAT i MASQUERADE pro -i lokalni_if -d public_ip --dport ftp - a pak traffic kterej by sel jen mezi client->ftp server pude client->gw->ftp server PS: to -i lokalni_if je obecnejsi, v iptables budes muset pouzit ip adresy
Ale v tom pripade je to cely uplne mimo
packet (ktery z lokalu posles na ftp://public_ip:ftpport ) pak na ftp server prijde stejnej jak z lokalu az na src MAC adresuAž na to, že jsi zapoměl, že IP packet žádnou MAC adresu nemá. Nehledě na to, že stačí vědět, co chceš a nastavit to, žádnej jinej než znalostní problém tu fakt nehledej.
Takze by stacilo na "ftp serveru" "fejkovat" src adresu a bude ti chodit pres gateway jen cast trafficu ktery by nemusel vubec, ale stejne toto udrzovat neni zrovna nejpohodlnejsi.
Rad se priucim, kdyz ukazes jak nastavit aby byl server pristupny pres verejnou ip z klienta ktery je na stejnem segmentu a zaroven byl pristupny z internetu (ale nemas dostatek ip adres takze je za NATem) - navic spojeni mezi klientem a serverem samozrejme nemuze jit zbytecne pres gateway (krome inicializace).
Tim se problem posouvaProblém, který nikdy neexistoval se nikam neposouvá.
ale nemas dostatek ip adres takze je za NATemPokud nemáš dostatek IP adres (tzn ani jednu), nemáš kde provozovat NAT (a provozuje ho někdo jiný). Pokud máš jednu veřejnou adresu, není nutné provozovat tak složitá řešení. Pokud se přecejenom z nějakého důvodu rozhodneš to řešit složitě, tak máš možnost si nastudovat, jak TCP/IP funguje a jak funguje firewall. A jestli chceš detailní přednášku, tak u toho potřebuju aspoň na stůl dostat pořádnej kus masa a nějaký pivo :D.
samozrejme nemuze jit zbytecne pres gatewayA jakou by sis přál barvu tý gateway? A smí být napájená elektřinou? Hele a přes switch to taky nesmí jít, co? Začínám mít nepříjemný pocit, že jen ztrácím čas tím, že se snažím přesvědčit někoho, že existuje jednoduché a funkční řešení, zatímco ten člověk se snaží nalézt takové podmínky, aby se mohl hřát u srdce, až tomu řešení jakkoliv zabrání.
. Mas jednu adresu (ale nemas dostatek aby si mel alespon jednu pro kazdy stroj pristupny z Netu (i to je malo ale), takze na gateway(ta ma jedina verejnou ip) provozujes SNAT a navic DNAT k ruznym serverum ktere bezi na jinych strojich. Sluzby na techto serverech chces mit pristupne i z Netu i z LAN. Proto potrebujes ty skaredosti jako dva proftpd s dvema ruznyma konfigama (MasqueradeAddress) a spravovat dve ruzne dns zone _a nebo_ cpat vsechen traffic pres tuto gw.
) - i kdyz to by stejne jako to prvni reseni nefungovalo s proftpd a passive ftp . Vsechny tyhle workaroundy ale slouzi pouze k tomu aby router a server mohly bezet na jinem stroji - kdybys chtel mit verejne sluzby na vic strojich nez mas adres tak jedine kdyz na routeru _NATujes veskery traffic_ k temto serverum (a nebo k nim pristupovat pomoci ruznych adres )
Kazdopadne verim ze bys dokazal vymyslet jak poresit i toto bez zbytecneho NATu gigabitoveho trafficu ale ta moje reakce na puvodni kralykuv komentar mela ukazat ze i kdyz mas verejnou ip adresu ale nemas _minimalne_ jednu pro kazdy stroj na kterem chces mit sluzby pristupny z Netu tak to znacne zkomplikuje reseni site.
To je nová informace, kterou jsi asi zapoměl napsat.A precejen jsem to napsal
oproti reseni s dostatkem adres a firewallu bez NAT.
A myslim si ze existujou lepsi reseni (nez verejna sit i NAT).Třeba živit se v jinym oboru? :D Nebo... to odříznout od internetu úplně? Nebo... zkriplit sluby víc - to je nejčastější řešení... pustit třeba jen HTTP přes proxy.
a co se tyce tech ostatnich jako voip apod. tak pokud budou ve firme vyuzivany, stejne budou pravdepodobne jen interni...Můžeš určovat pravidla svojí firmě, jiný firmy to můžou mít jinak.
Neboli nejak zkryplim sluzby, jak tomu ty s oblibou rikas (i kdyz nevim co je na tom zkryplenyho). Jestli chces, aby vsechny tvoje pocitace/nody v tvoji siti byly zvenku jako celek pristupny se vsema sluzbama co na nich kdo spusti nebo nespusti tak prosim, kdo chce kam, pomozme mu tam, anebo proti gustu zadny disputat...Podsouváš mi skoro opak toho, co jsem řekl. Nepozorný čtenář by ti to mohl sežrat a mě nebaví pořád vysvětlovat, co jsem napsal a co ne.
nastavim tam pravidla aby poustel jen nektery sluzby nekterym smerem na nektere adresy vevnitr.Ano, tomu se říká firewall. Dokonce se tomu říkalo firewall ještě než začaly docházet adresy a vymýšlely se různé obezličky. Je tu ještě jeden problém s NATem. Ve skutečnosti nemusí vůbec dělat to, co si myslíš a za některých okolností by tě to mohlo ještě dost překvapit. On totiž nechrání úplně stejně jako firewall, který pustí jen odchozí spojení. Dokonce různé implementace NATu můžou mít velmi různé vlastnosti. Je to asi jako si koupit zaručeně bezpečný zámek u vietnamců, možná funguje a možná taky ne.
a co se tyce tech ostatnich jako voip apod. tak pokud budou ve firme vyuzivany, stejne budou pravdepodobne jen interni...Možná, možná ne. Když už by šlo o firmu, tak řešením by mohlo být firewall zakazující všechno dovnitř + výjimky ze zákazu pro služby, které se ve firmě používají a je potřeba, aby byly dostupné zvenku (např. ty telefony).
Nojo, nekdo zas predpoklada ze kdyz neni na kazdym pocitaci public IP tak jsou zkrpleny sluzby... Takovy lidi se taky podepsali na ipv4 adress drain...Jasně :D. Tak když se nepřešlo včas na dostatečně velkej prostor čísel... tak radši z problémů obviníme, ty, kteří chtějí ty čísla využívat. Přečti si někdy, co se píše na webu RIPE o IP adresách. Mají být přidělovány podle potřeby a zdarma. Můj názor, že přirozených čísel existuje je dost na to, aby se daly počítače očíslovat. Stačí jenom používat vhodnej mechanismus, což IPv4 (kvůli nízké horní hranici) už dlouho neni.
Ja preferuju reseni, kdy nemusim mit na kazdym pocitaci super silnej firewall.Jako kdyby to nebylo jedno. Pokud se ti někdo dostane přes silnej FW na hraničním routeru, zvládne to samé i u počítače ve vnitřní síti bez ohledu na to, jestli tam taky máš silnej FW nebo ne.
Alespoň myslím, že si to myslel takhle...
28.7.2008 19:23
3of5 | skóre: 8
| blog: ta_technika
post-up /sbin/ip -6 route add 2002::XXXX:ZZZZ::/48 dev eth3Pozor na jednoznačnost
.
Taky by asi...To spíš zavání řešením (2).
aby router a server mohly bezet na jinem strojiPrávě, což je samo o sobě (jak sám píšeš) nesmysl, pokud nemáme několik samostatnou IP pro server.
Kazdopadne verim ze bys dokazal vymyslet jak poresit i toto bez zbytecneho NATu.Pořešit bez NATu bych to sice asi dokázal, ale musel bych to nahradit podobně komplikovanou technikou. Neexistuje jediný rozumný důvod, proč číslovat internet prostorem, který už nestačí. Pro telefonní čísla ani adresy domů se NAT nepoužívá :). Celý stávající koncept šetření číslama se mi zdá hloupý.
Tiskni
Sdílej:
30.7.2008 04:57