abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 06:00 | Nová verze

Byla vydána nová verze 1.26 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 21
včera 03:00 | Nová verze

Po více než 3 měsících vývoje od vydání verze 2.12.0 byla vydána nová verze 3.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 169 vývojářů. Provedeno bylo více než 2 300 commitů. Přehled úprav a nových vlastností v seznamu změn. Proč verze 3.0.0 a ne 2.13.0? Není to kvůli triskaidekafobii. QEMU letos v březnu slavilo 15 let od oznámení verze 0.1 a to je dle vývojářů dobrý důvod pro novou major verzi. Vývojáři mají v plánu zvyšovat major verzi jednou ročně, vždy s prvním vydáním v daném roce.

Ladislav Hagara | Komentářů: 3
14.8. 22:11 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00161) další bezpečnostní problém ve svých procesorech. Problém byl pojmenován L1 Terminal Fault aneb L1TF. Popis problému přímo od Intelu na YouTube. Jedná se o CVE-2018-3615 (SGX), CVE-2018-3620 (OS/SMM) a CVE-2018-3646 (VMM). Další informace na stránce Foreshadow nebo přímo v dnešním commitu do Linuxu.

Ladislav Hagara | Komentářů: 12
14.8. 12:33 | IT novinky

Po více než 4 letech bylo vydáno RFC 8446 popisující verzi 1.3 protokolu TLS (Transport Layer Security). Popis novinek i historie TLS například v příspěvku na blogu Cloudflare.

Ladislav Hagara | Komentářů: 0
14.8. 11:11 | Zajímavý software

V roce 1998 uvedla společnost Tiger Electronics na trh elektronickou hračku, malého chlupatého tvora s velkýma ušima, Furby. Furby patřil k nejžádanějším hračkám. Během tří let se jich prodalo více než 40 milionů. Furby již tenkrát reagoval na světlo, zvuk, polohu, doteky a přítomnost dalších Furby. Sám mluvil a pohyboval se. Firmware uvnitř simuloval postupný vývoj a učení. Zdrojový kód tohoto firmwaru byl zveřejněn na Internet Archive [Hacker News].

Ladislav Hagara | Komentářů: 20
14.8. 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
13.8. 21:00 | Zajímavý projekt

Cílem projektu DXVK bylo vytvořit vrstvu kompatibility mezi Direct3D 11 a Vulkanem a začlenění této vrstvy do Wine. Direct3D 10 nad Vulkanem bylo možné řešit mezikrokem pomocí vrstvy DXUP překládající Direct3D 10 na Direct3D 11. Vývojáři DXVK se rozhodli přímo podporovat Direct3D 10. Podpora byla začleněna do hlavní větve na GitHubu.

Ladislav Hagara | Komentářů: 4
13.8. 16:00 | Nová verze

Vyšla verze 3.10 přehrávače Audacious. Přináší oprav chyb a drobná vylepšení seznamů skladeb, vyhledávání či ikonek. Zároveň pokračují práce na novém uživatelském rozhraní využívajícím Qt namísto GTK+ – nejsou však hotovy, proto je vydání 3.10 pojmenováno „Not Quite There Yet“; až bude proces u konce, vyjde Audacious 4.

Fluttershy, yay! | Komentářů: 12
13.8. 02:00 | Nová verze

Linus Torvalds vydal Linux 4.18. Více o vývojovém cyklu v Jaderných novinách: začleňovací okno [1] a [2], statistiky. Finální přehled změn je k mání na webu Linux Kernel Newbies.

Fluttershy, yay! | Komentářů: 5
13.8. 01:00 | Pozvánky

Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze. Prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.

xkucf03 | Komentářů: 0
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (7%)
 (4%)
 (12%)
 (77%)
Celkem 179 hlasů
 Komentářů: 9, poslední 14.8. 21:03
    Rozcestník

    Dotaz: Multicast routing (ACL)

    18.5.2017 15:07 MaraCh
    Multicast routing (ACL)
    Přečteno: 397×
    Ahoj.

    Mám PC router s Linuxem, který má čtyři síťové rozhraní: l0, w0, f0 a a0. Jedním z úkolů tohoto PC je routování multicast provozu mezi síťovými rozhraními, ale s poměrně úzkými omezeními. Například:
    • mc vysílání na adresy 239.255.0.0/16 má být routováno jedině z rozhraní f0 do l0
    • mc vysílání na adresy 239.23.0.0/16 má být routováno jedině z rozhraní w0 do l0
    Tedy nesmí například být routováno vysílání 239.255.0.0/16 z w0 do l0, nebo jakýkoliv multicast provoz z f0 do w0.

    Výše uvedené mám zatím realizováno pomocí pimd v2.3.2 a firewall pravidel, které zakazují především forwardování toku, který nevyhovuje.

    Problémy a nedostatky zjištěné v rámci testů:
    • pimd umožňuje definovat rozsahy mc adres, kde se bude zabývat routováním - bohužel jen obecně jako celek s nemožností říci jaké skupiny adres se týkají jakého rozhraní odkud/kam
    • definice firewall pravidel zabraňuje sice nechtěných toků přes router, ale nedokáže zamezit vniku vysílání před routerem a nutnosti zahazování toku routerem (který by zahazován být nemusel, pokud by nechtěl routerem protékat)
    Například pokud bude nějaké zařízení za w0 přihlášeno k odběru 239.255.0.1 a v síti za f0 bude nějaké vysílací zařízení poskytující stream na 239.255.0.1, tak sice tento zakázaný tok (f0->w0) přes router díky firewall pravidlům neprojde, ale:
    1. na routeru vznikne routovací pravidlo zobrazitelné přes "ip mroute" a tento zbytečný multicast tok bude muset na příkaz iptables router zahazovat
    2. přestože neexistuje žádný povolený odběratel tak vysílací zařízení musí tento tok generovat (což by pokud se nepletu, kdyby opravdu nikdo přihlášen nebyl nedělalo)
    Existuje nějaká možnost jak to řešit elegantněji?

    Je to vůbec v silách síťové vrstvi na linuxu? Udivuje mne totiž, že i když jsem v rámci testů kompletně začal zahazovat pakety směřující do f0 jak v INPUT tak v FORWARD, tak ten router se nějak prostě dozvěděl, že tam za f0 někdo vysílá (nechápu jak) a při zahájení jeho vysílání vytvořil routovací pravidlo (viditelné přes: ip mroute).

    Odpovědi

    18.5.2017 15:48 NN
    Rozbalit Rozbalit vše Re: Multicast routing (ACL)
    Nevyplatilo by se pouzit statcky multicast routing pomoci smcroute doporucovany v odkazu misto dynamickeho? Mimojine umoznuje specifikovat rozsahy, rozhrani i smery.
    18.5.2017 16:11 MaraCh
    Rozbalit Rozbalit vše Re: Multicast routing (ACL)
    Nevidím, že by tam šlo definovat rozsahy u multicast adres - dívám se špatně?
    18.5.2017 17:27 NN
    Rozbalit Rozbalit vše Re: Multicast routing (ACL)
    Lze to definovat per vysilac, default limit je 20. Kolik jich mas, ze to potrebujes na cely subnet? Imho u milticastu se nevysila tam, kde neni alespon jeden prijemce u z principu protokolu, nebo se pletu?
    19.5.2017 08:11 MaraCh
    Rozbalit Rozbalit vše Re: Multicast routing (ACL)
    Těch potenciálních vysílačů bude v reálu přibližně kolem 20. Problém je v tom, že se rekrutují ze skupiny zařízení, kterých budou až stovky. Těch routerů budou v síti desítky. Desítky routerů není možné před každou akcí předefinovávat na ~20 potencionálně možných vysílačů, které asi zrovna budou v akci připadat v úvahu. Bylo by to administrativně neúnosné. Proto jsou definovány velké multicast prostory u kterých je však zřejmé kudy mohou téci. Teoreticky také hrozí nebezpečí špatného zapojení do nechtěného segmentu sítě (nebo průtoky do nechtěných segmentů sítě) a to je jeden z důvodů proč některé toky nesmí vznikat, protože by mohly zahltit část sítě, která má omezenou přenosovou kapacitu (je rádiová).

    Hledám tedy dynamický multicast routing se slušnou možností definovat možné toky. Ten statický vypadá na slušné možnosti, ale nemožnost definovat obecně velké multicast rozsahy ho dělají pro můj účel nepoužitelný.

    Multicast je v celku pěknej prevít - třeba zařízení s úplně jinou IPv4 konfigurací než je síť v které se nachází, nemá problém vysílat či přijímat multicasty...

    Čemu zatím také nemohu přijít na kloub (nerozumím tomu) je ten jeden z testů co jsem provedl. Přestože jsem zavřel přes iptables v INPUT i ve FORWARD komunikaci přicházející z jedné ze sítí na jedné straně routeru a potencionální posluchač byl aktivován na jiné straně routeru, tak v okamžiku zahájení vysílání zařízení na té zavřené straně routeru se v routeru vytvořila routa pro tento multicast (ukázal to ip mroute). Nechápu jak je to možné - jak se ten router dozvěděl, že tam je nějaký vysílač multicastu, příchozí tok k routeru z té strany je zcela zahazován. Budu ten test muset zopakovat - hlava mi to nebere (snad nějaké komunikace na L2 mimo L3?).
    19.5.2017 09:00 NN
    Rozbalit Rozbalit vše Re: Multicast routing (ACL)
    Blokujes cely IGMP ptotokol Query/Membership pakety, nebo jen multicast skupinu? Muzes to oddelit na L2, nebo je zadouci i jina L3 komunikace na rozhranich?
    19.5.2017 14:53 MaraCh
    Rozbalit Rozbalit vše Nemožnost odfiltrovat některé multicast dohody přes iptables - TEST
    Uvedu nyní přesně "výzkumný test", který zmiňuji v závěru své otázky a jehož výsledky nechápu.

    Mám router, kde běží pimd. Router má síťová rozhraní w0 a f0.

    Schema zapojení:
    PC_before_w0 <---> [w0]-router-[f0] <----> PC_before_f0
    
    1. Zákaz veškerého toku na router přícházejícího z rozhraní f0 (povoleno jen ssh):
    router#
    iptables -t filter -F
    iptables -t nat -F
    iptables -A INPUT -i f0 -p TCP --source-port 22 -j ACCEPT
    iptables -A INPUT -i f0 -j DROP
    iptables -A FORWARD -i f0 -j DROP
    
    2. Zahájení naslouchání (příjmu) multicast:
    PC_before_w0$ iperf -s -u -B 239.255.0.1
    
    3. Kontrola routovacích pravidel:
    router# ip mroute
    (nic nevypýše - žádná pravidla nejsou)
    
    4. Zahájení multicast vysílání:
    PC_before_f0$ iperf -u -c 239.255.0.1 -T 3 -t 30
    
    5. Kontrola routovacích pravidel:
    router# ip mroute
    (ip_adresa_PC_before_f0, 239.255.0.1)       Iif: f0       Oifs: w0
    
    Z výpisu routovacích pravidel je vidět, že vznikla multicast routa. K samotnému toku dat přes router nedojde. Jak je však možné, že vznikla ta routovací pravidla? Jak se router dozvěděl o existenci nějakého multicast vysílání před rozhraním f0, když v iptables je vše příchozí zahazováno? Může to prosím někdo vysvětlit?
    19.5.2017 15:09 MaraCh
    Rozbalit Rozbalit vše Re: Nemožnost odfiltrovat některé multicast dohody přes iptables - TEST
    Ještě dodám, že situace se nezmění ani když ještě k 1. bodu přidám následující pravidla:
    iptables -A OUTPUT -o f0 -p TCP --destination-port 22 -j ACCEPT
    iptables -A OUTPUT -o f0 -j DROP
    iptables -A FORWARD -o f0 -j DROP
    
    Kromě ssh nemohou IP data tam ni zpět, ale přesto se to nějak domluví. Jo kdyby to tak bylo i u lidí:-)
    19.5.2017 21:12 martinvolf
    Rozbalit Rozbalit vše Re: Nemožnost odfiltrovat některé multicast dohody přes iptables - TEST
    Nepomohlo by zahazovat to v tabulce raw?
    iptables -t raw -A PREROUTING -i f0 -j DROP
    21.5.2017 20:11 Ondrej Santiago Zajicek
    Rozbalit Rozbalit vše Re: Nemožnost odfiltrovat některé multicast dohody přes iptables - TEST
    Jak je však možné, že vznikla ta routovací pravidla? Jak se router dozvěděl o existenci nějakého multicast vysílání před rozhraním f0, když v iptables je vše příchozí zahazováno?
    AFAIK prichozi paket se nejdriv paket prozene routovanim, aby se zjistilo, co s nim, a pak teprve se aplikuji prislusna pravidla z filter tabulky (INPUT ci FORWARD chainy). Pri multicast routingu pak pri nepritomnosti routy kernel preda paket specialnim kanalem routovacimu demonu (tedy jeste pred aplikaci pravidel z filter tabulky) a ten prida routu do routovaci tabulky. Jak pise martinvolf nize, mohlo by pomoci filtrovat to v PREROUTING chainu tabulky raw.
    22.5.2017 12:14 MaraCh
    Rozbalit Rozbalit vše Re: Nemožnost odfiltrovat některé multicast dohody přes iptables - TEST
    Děkuji za odpověď i za odpověď předřečníkovi.

    V uvedeném konkrétním případě stačí pravidlo:
    iptables -t raw -A PREROUTING -i f0 -d 239.255.0.1/32 -j DROP
    
    A routa pak nevznikne. Trochu mi to bourá představu, že mcast tok vzniká jen když jsou odběratelé - zde je routa asi vytvořena až vznikne mcast tok (a jen pokud ho zamlčím tak routa nevnikne) (nebo snad vysílací strana ví o tom posluchači i když tam mám výše uvedené iptables pravidlo?).

    Uvedená pravidla v tabulce raw mohou zajistit nevznikání mcast routovacích pravidel na konkrétní rozsahy mcast cílů. Žel nelze s nimi zajistit, že cíl je povolen, ale jen k forwardování na konkrétní síťové rozhraní a na jiné ne.

    Jinými slovy hledám daemona na mcast routování, který bude umožňovat definovat přesnější pravidla. pimd to asi neumí. Zná někdo takového daemona?

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.