Internet Info, s.r.o. Lupa Root Měšec Podnikatel DigiZone Slunečnice Vitalianew Bomba Navrcholu Weblogy Jagg Woko Dobrý web Computer.cz SK: MojeLinky
Root.czBlogyOskarův Weblog @root

Vodafone a ČD: bezpečnost až na posledním místě?

Ondřej Caletka, 11. 11. 2011, 13:37 v kategorii Nezařazené,

Kolem bezpečnosti na Internetu se už promluvilo a propsalo mnohé. Každý ví, že by neměl používat jednoduchá slovníková hesla, že by neměl používat jedno heslo pro více služeb (od toho tu máme MojeID, popřípadě SuperGenPass) a že by si neměl hesla nikam poznamenávat. Běžný uživatel obvykle nad takovýmito poučkami mávne rukou a dál se chová nebezpečně. Když se však tak chovají i profesionálové na druhém konci drátu, je to na pováženou.

Můj příběh začíná u e-shopu Českých Drah. V korelaci s výjezdem žlutých vlaků se e-shop majoritního dopravce také proměnil a je konečně schopen v zadané relaci sám doporučit takovou nabídku, která je pro cestujícího nejvýhodnější. Pro častější zákazníky nabízí i registraci, kdy je možné si do „profilu“ uložit například číslo In-karty.

A tady nastává potíž. E-shop obsahuje také odkaz Moje In-karta, kterýžto vizuálně působí dojmem, že patří do e-shopu. Bohužel, ve skutečnosti jde zřejmě o zcela oddělené webové aplikace, které mezi sebou nic nesdílí. Pro přihlášení In-karty je třeba zadat její číslo a heslo. Číslo se zadává do oddělených políček, které sice jsou svázány pomocí JavaScriptu, i tak ale efektivně brání použití automatického doplnění, či vložení ze schránky.

Přihlašovací dialog webového rozhraní In-karty

S heslem je to ještě mnohem horší. Úvodní heslo dostanete spolu s In-kartou na blanketu klasické „modré jízdenky“. Po přihlášení jej můžete změnit, je však třeba zachovat formát xxx####, kde x je písmeno bez diakritiky a # je číslice. Takové striktní požadavky na heslo mají v případě mé osoby jasný důsledek:

Při každém použití používám funkci pro obnovení zapomenutého hesla.

Už to samo o sobě určitě není správné, ještě horší to je, když zjistíte, že při obnově nedochází k vygenerování nového hesla, pouze vám e-mailem přijde vaše platné aktuální heslo! A to bez jakéhokoli zabezpečení. Ano, i na konci roku 2011 jsme stále tam, kde jsme byli v roce 1997, kdy jsem začínal s Internetem. Heslo mají v databázi uloženo v otevřené podobě, dostane se k němu jak každý legitimní správce, tak i ten, kdo se správcem stane zneužitím nějaké díry v softwaru.

Vodafone phishing stále v provozu

Když už vlastníte In-kartu, můžete si na stránce cdbonus.vodafone.cz zařídit tarif pro volání z mobilního telefonu s výraznou slevou (což není problém vzhledem k obecně známým předraženým ceníkovým cenám našich operátorů). Na webové stránce vyplníte formulář, po jehož odeslání se skoro nic nestane, jen v e-mailové schránce objevíte poněkud zvláštní zprávu:

From: nabidka.cd-bonus@vodafone.com
Subject: Zamestnanecka nabidka - potvrzeni objednavky

Dobrý den,

vaše objednávka byla úspěšně přijata.

Děkujeme
Váš Vodafone

O pár dnů později mi volá jakási paní z čísla +420777352nnn s tím, že by se mnou ráda vyřídila převod tarifu na nový zvýhodněný. Tohle číslo, jak jsem později zjistil, najdete na firmy.cz u jakési živnostnice v oboru cestovního ruchu z Bystřice pod Pernštejnem. A hned první otázka: „Vaše heslo pro komunikaci s operátorem?“

WTF? Tohle už se zde, na blozích roota, řešilo v roce 2008. Přesto Vodafone své zaměstnance stále nepoučil a jejich prostřednictvím vyzývá své klienty k nebezpečnému chování.

Když jsem se ohradil, že nevím, kdo mi volá, začala paní na druhém konci říkat, že pokud chci mít jistotu, nechť si zavolám na klasickou zákaznickou linku *077 a vyřídím to s nimi. Ale ujistila mě, že všechno vidí, moje jméno, tarify, které jsem zvolil i číslo In-karty. Nakonec jsem se tedy rozhodl, že provedu autorizaci pomocí čísla In-karty. Ta proběhla v pořádku, tak jsem heslo prozradil a hovor úspěšně dokončil. Vzhledem k tomu, že po hovoru se s mým zákaznickým účtem začalo něco dít (některé služby se deaktivovaly, jiné aktivovaly), je velmi pravděpodobné, že hovor skutečně byl legitimní, nejednalo se o žádný phishing.

Ani v případě, že o identitě protistrany není pochyb, se mi však nezdá korektní požadovat při telefonickém spojení celé heslo. Například Komerční Banka při ověřování hesla vyžaduje pouze dva náhodně vybrané znaky z hesla, takže není možné heslo zjistit jednorázovým odposlechem.

Zlepší se to někdy? Zrovna velké společnosti by měly v bezpečnosti jít příkladem. Jak je ale vidět, spíše opak je pravdou.

Jaké jsou žluté vlaky?

Ondřej Caletka, 9. 10. 2011, 22:18 v kategorii Nezařazené,

Na konci září začaly mezi Prahou a Havířovem jezdit dlouho slibované „žluté vlaky,“ tedy vlaky českého podnikatele Radima Jančury. Rozhodl jsem se je vyzkoušet a sepsat drobnou recenzi. Předem se omlouvám, že tento post nebude vůbec o linuxu a jen velice málo o počítačích.

(pokračování příspěvku…)

Spammeři jsou zase mazanější

Ondřej Caletka, 2. 08. 2011, 22:56 v kategorii Sítě,

E-mailové schránky českých uživatelů byly v posledních dnech pod útokem cílené kampaně spamů, přesněji tedy spíše scamů. Cílem tentokrát bylo nalákat uživatele na podvodnou službu GSMlocator, nabízející údajné zjištění polohy mobilního telefonu na základě telefonního čísla. Jako u každého scamu podfukář vytvoří u oběti dojem, že je všechno v naprostém pořádku a k získání polohy zbývá poslední drobný krůček – test pro vyloučení robotů. Ten se neprovádí pomocí opisování obrázku, ale posláním SMS. Aplikace přitom nijak neupozorňuje na to, že jde o prémiovou SMS v hodnotě 79 Kč. Také přesně jako každý správný scam to opsáním kódu nekončí, oběť dostane doplňující otázku na věk, odpověď zase pomocí SMS. Dál už to na serveru Hoax.cz nezkoušeli, ani se jim nedivím :)

Na celém případu pro mě není ani tak zajímavé, kolik lidí se v touze po nabourání cizího soukromí nechalo napálit, nezajímá mě ani podivné tvrzení, že „Přihlášení do mobilního telefonu do sítě operátora je šifrováno a signál je veden přes pozemní vysílač do satelitu“ Co mě opravdu zaujalo je způsob, jakým se spam rozšířil.

Odesílat klasický spam dnes není vůbec jednoduché, spamfiltry jsou den ode dne dokonalejší, open relay SMTP serverů ubývá a ty co existují, jsou dávno zapsány na černých listinách. Pořídit si vlastní botnet je taky spousta práce a navíc trvalý boj s výrobci antivirů.

Scammeři z GSMlocatoru objevili nový způsob, jak spamfiltry zmást. Mohlo to proběhnout asi takhle:

  1. V Google vyhledali pojem „czech freemail“. Hned první odkaz je zavedl na Seznam.
  2. Prozkoumali povinná pole registračního formuláře, zjistili, že jich mnoho není.
  3. Za několik člověkohodin vytvořili program pro automatizované registrování účtů. Formulář je chráněn poměrně čitelným CAPTCHA kódem, pokud by byl problém s OCR, není problém za pár centů zaměstnat indický cloud.
  4. Dalších pár člověkohodin zabralo vytvoření programu pro odeslání e-mailu prostřednictvím webového rozhraní Seznamu.
  5. Výsledný program předali nejspíše pronajatému botnetu. Ten zaregistroval mnoho účtů a odeslal mnohokrát mnoho e-mailů.

Kde je ten zásadní rozdíl proti klasickému spamu? Dříve se spamy šířily tak, že jejich zdroj se choval jako primitivní MTA. Připojil se na port 25, vychrlil zprávu SMTP protokolem, a aniž čekal na odpověď, šel o dům dál. Takové spamy jsou dnes díky technikám jako greylisting snadno zachytitelné a rozpoznatelné.

Teď došlo k tomu, čeho se bojovníci proti spamu obávali. Zdroj spamu namísto imitace primitivního MTA použije skutečného poštovního klienta hostitelského systému, v tomto případě webmail Seznamu. Takovým způsobem je možné odeslat výrazně méně e-mailů co do kvantity, ovšem pravděpodobnost jejich doručení je dramaticky vyšší.

Perličkou na celém incidentu je digitální podpis DKIM, který Seznam automaticky přikládá e-mailům, které projdou přes jejich poštovní servery. Spamy GSMlocatoru měly validní DKIM podpis, proto si také mohu být tak jistý příběhem o vzniku zprávy. Na rozdíl od jiných spamů tedy tento nefalšuje identitu odesílatele a chcete-li, můžete na něj odpovědět. Dlužno dodat, že e-mailová schránka pravděpodobně byla Seznamem dávno zrušena a i kdyby nebyla, vaši odpověď si stejně nikdo nepřečte. V každém případě v tuto chvíli bylo prolomeno tvrzení Tomáše Hály ze společnosti Active 24:

Ačkoli je to technicky možné, zatím jsme se nesetkali se spamem podepsaným DKIMem, pouze tak přišly nedoručenky.

Co proti tomu dělat?

Tady je každá rada drahá. Nenapadá mě žádný spolehlivý způsob, jak takovýto spam odfiltrovat. Samozřejmě, Seznam by mohl vylepšit CAPTCHA a dodat další autentizační faktor pro vytvoření účtu. Ale jaký? Ověřovací e-mail se pro zřizování freemailu moc nehodí. Ověření pomocí telefonu, SMS, nebo klasické pošty je zase poměrně nákladné.

Další možnosti boje proti spamu jsou založeny na statistice. Seznam a jemu podobní by nejspíše měli v reálném čase vyhodnocovat neobvyklé počty registrací z exotických krajů (do mé schránky dorazily spamy postupně ze Španělska, Guatemaly a Dominikánské republiky) a případně pozdržet několik hodin po registraci jejich zprávy k analýze. Jenže jak tu analýzu udělat? Při zachování telekomunikačního tajemství je nemožné, aby obsah pozdržených zpráv prohlíželi lidé. A stroje jen velmi těžko zachytí nově vzniklý scam…

Nemyslím si, že by v Seznamu něco zanedbali. Spíše doplatili na to, že jsou první na ráně. Docela by mě zajímalo nějaké vyjádření k tomuto incidentu přímo od Seznamu. Snad se časem dočkáme.

Hoffmanův Podcast

Ondřej Caletka, 30. 07. 2011, 23:26 v kategorii Nezařazené,

Ivan Hoffman se do mého povědomí zapsal především jako autor ranní poznámky ČRo 1 – Radiožurnálu. Když byl v roce 2008 Barborou Tachecí odejit, velice rychle se s podobným formátem uchytil u společnosti Vltava-Labe-Press, která vydává regionální deníky. Sloupek 300 slov na aktuální téma vychází kromě černotisku také ve webové podobě a snad z nostalgie k radiožurnálu dokonce i ve zvukové podobě s charakteristikým autorským projevem.

Bohužel právě zvukové záznamy jsou publikovány dosti nešikovně. K jejich přehrání je třeba spustit flashový přehrávač na webové stránce deníku, jiné možnosti oficiálně nabízeny nejsou. Stránka sice nabízí RSS export, obsahuje ale pouze titulek, odkaz a perex článku.

Napsal jsem do redakce, zda nechtějí odkaz na zvukové soubory přidat do RSS exportu, čímž by se proměnil v plnohodnotný podcast. Poděkovali za námět a přislíbili, že tuto možnost zváží. Než tak učiní, vymyslel jsem vlastní, pokěkud kontroverzní skript v Pythonu 3, který originální RSS export na podcast převádí.

Program funguje tak, že stáhne a přečte originální RSS export. V něm postupně otevře všechny odkazované stránky. Na najde odkaz na XML playlist a v tomto playlistu přímý odkaz na MP3 soubor s nahrávkou. Do původního RSS exportu doplní ke každé položce tag enclosure s přímým odkazem na MP3 soubor. Pokud výstup skriptu vystavíte někde na webu a namíříte na něj Podcast čtečku, můžete získat každé ráno čerstvý komentář přímo do svého přenosného přehrávače. Jako vedlejší produkt skript do výstupního souboru přidá i úplný text deníku, takže pokud jej čtečka podporuje, je možné přečíst si celý fejeton přímo ve čtečce.

Popis programu

Skript jsem vytvořil poměrně rychle po prostudování kapitol o XML a HTTP ve výborné knize Marka Pilgrima „Ponořme se do Pythonu 3“. V pasáži o HTTP se Mark hodně rozepisuje o tom, jak je důležité HTTP správně implementovat a že jedině knihovna httplib2 takovou komunikaci zvládá, včetně cachování. I když jsem knihovnu použil, narazil jsem na tvrdou realitu dnešních dynamicky generovaných webů, totiž že u veškerého obsahu je serverovými hlavičkami cachování zakázáno. Adresář .cache se tedy sice plní staženými daty, při dalším spuštění skriptu jsou však všechny soubory nemilosrdně staženy znovu.

Přesto se cache hodila, hlavně pro ladění programu. Odhalil jsem tak například, že novinový server trpí drobnou vadou řeči. Vydavatelskou společnost například označuje jménem VLATA-LABE-PRESS:

<copyright>© Copyright VLATA-LABE-PRESS, a.s. 2000 - 2011 - exodus4</copyright>

O něco vážnější vadou je, že také občas zadrhává. Projevuje se to tak, že při požadavku o stažení RSS exportu tento vrátí rovnou dvakrát za sebou. Knihovna ElementTree těžce nese, má-li XML dokument dvě kořenové značky, takže jsem musel do skriptu vestavět workaround, který odsekne zbytek souboru po první ukončovací kořenové značce.

Závěr

Jsem si plně vědom, že využívání webových stránek deníku takovým způsobem, jakým to dělá skript, může být chápáno jako zneužití. Je dost možné, že obchodní model Hoffmanova deníku počítá kromě prodeje tištěných verzí také s příjmy ze zobrazování reklam na webové stránce. Tyto reklamy v RSS streamu ani podcastu nejsou. Je to v podstatě stejná situace jako s programy pro generování XMLTV dat prostřednictvím automatizovaného zpracování portálů s TV programem.

Obsah webu je také chráněn autorským zákonem. Z toho důvodu není možné vygenerovaný podcast dále sdílet. Použití pro vlastní potřebu je však dle mého laického názoru zcela legální, podobně jako je legální používání blokovačů reklam pro webové prohlížeče.

Jak jsem zaváděl DVB-T2

Ondřej Caletka, 4. 05. 2011, 11:00 v kategorii Linux,

Přechod na zemské digitální vysílání v normě DVB-T pomalu vrcholí. A přitom už klepe na dveře další norma, zvaná DVB-T2. V tomto zápisku se s Vámi podělím, kterak jsem k pražskému experimentálnímu vysílání naráz připojil až 4000 nových diváků.

Co je norma DVB-T2

Návrh vysílání v normě DVB-T je z pohledu počítačů již velmi letitý; vždyť první vysílání v této normě bylo spuštěno již v roce 1998 (zdroj). Od té doby se výpočetní výkon počítačů mnohonásobně zvýšil. Nastal tedy čas přibližně po deseti letech normu zrevidovat, vzít v potaz moderní kódovací algoritmy i výkonnější počítače. Výsledkem této revize je v tuto chvíli již plně standardizovaná norma pro druhou generaci zemského digitálního vysílání – DVB-T2, jehož ostré vysílání bylo ve Velké Británii spuštěno v první polovině roku 2010.

FAQ: To budeme muset zase vyměňovat Set-Top-Boxy???

Ano i ne. S DVB-T2 se počítá spíše jako s platformou pro šíření HD vysílání ve formátu MPEG4; byť samotná modulace DVB-T2 rozlišení programů ani použitý kodek nepředepisuje. Dá se předpokládat, že dokud bude mezi diváky poptávka po pořadech v SD rozlišení, bude zachována alespoň minimální forma vysílání ve standardu DVB-T a MPEG2. Přechod na DVB-T2 tedy pravděpodobně přijde přirozeně, spolu s poptávkou po HDTV.

Zadáním pro vysílání v normě DVB-T2 byla alespoň o 30% vyšší spektrální účinnost. Ve skutečnosti se podařilo účinnost zvýšit i o více než 50% (zdroj). Podařilo se snad také pohnout s mobilním příjmem a jednofrekvenčními sítěmi. Zkrátka je o co stát.

Na konci listopadu minulého roku byl v Praze spuštěn dlouhodobý experiment vysílání v DVB-T2. Nedávno se navíc i v českých e-shopech začaly objevovat první televizní karty pro PC, podporující tento standard. Konkrétně jde o USB model PCTV nanoStick T2 290e, který se honosí také titulem „První DVB-T2 přijímač pro PC na světě“.

Podpora v Linuxu

Není překvapením, že ovladače na příjem DVB-T2 nejsou připraveny. I kdyby byly, není připraveno Linux DVB API a v neposlední řadě nejsou k dispozici žádné uživatelské programy, které by nový standard uměly použít. Přesto se na stránce, zabývající se podporou pro výše uvedenou kartu, objevilo toto sdělení:

Well, I've watched some channels from a T2 mux in VLC on Linux. Fantastic!

Jak je to možné? Především, díky finskému vývojáři jménem Antti Palosaari je k dispozici Git větev s prvním experimentálním ovladačem. Autor tam vyřešil i problém s absencí podpory nové normy v aplikacích. Využil faktu, že demodulátoru k nalezení DVB-T2 vysílání stačí pouze naladění vysílací frekvence a předání informace, že má hledat modulaci DVB-T2, zbylé parametry jsou detekovány automaticky. Přidal tedy do ovladače demodulátoru cxd2820r parametr dvbt2_freq, do kterého je možné uložit seznam frekvencí, na kterých se namísto DVB-T má ladit DVB-T2. Uživatelská aplikace tak vůbec netuší, že jde o vysílání v nové normě, prostě naladí daný kmitočet a začne odebírat data. Jednoduché a přitom funkční.

Postup krok za krokem

Poznámka: Tento postup je platný v době publikování. Dá se předpokládat, že po finalizaci ovladače bude celý postup jiný, jednodušší.

  1. Stáhnout a zkompilovat kernel z uvedené Git větve. V praxi se mi při použití jádra 2.6.39.rc1+, ve kterém je ovladač vytvořen, objevily zvláštní problémy, proto doporučuji raději použít stabilní kernel 2.6.38.4 a patch s ovladačem:
    $ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.4.tar.bz2
    $ wget http://pastebin.com/raw.php?i=vUnBSSsE -O pctv290e.patch
    $ tar xjvf linux-2.6.38.4.tar.bz2
    $ cd linux-2.6.38.4
    $ patch -p1 < ../pctv290e.patch
  2. Zapojit adaptér a předat jádru parametr s kmitočtem pražského multiplexu na kanálu číslo 25, tj. 506 MHz:
    echo 506 > /sys/module/cxd2820r/parameters/dvbt2_freq
  3. Ověřit dostupnost signálu pomocí utility (dvb)scan:
    $ cat cz-PrahaT2
    # DVB-T Praha (Prague, Czech Republic)
    # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
    # DVB-T2 experiment K25
    T 506000000 8MHz AUTO AUTO AUTO AUTO AUTO NONE
    
    $ dvbscan cz-PrahaT2
    scanning cz-PrahaT2
    using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
    initial transponder 506000000 0 9 9 6 2 4 0
    >>> tune to: 506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE
    0x0000 0x0110: pmt_pid 0x0064 (null) -- CT HD (running)
    0x0000 0x0210: pmt_pid 0x00c8 (null) -- Nova HD (running)
    0x0000 0x0303: pmt_pid 0x012c (null) -- Prima HD (running)
    0x0000 0x0802: pmt_pid 0x0190 (null) -- Barrandov HD (running)
    Network Name 'DVB-T2'
    dumping lists (4 services)
    CT HD:506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:101:111:272
    Nova HD:506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:201:211:528
    Prima HD:506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:301:311:771
    Barrandov HD:506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:401:402:2050
    Done.
  4. Používat vytvořený soubor channels.conf, vzniklý přesměrováním výstupu programu dvbscan, v oblíbené DVB aplikaci. Například vysílat pomocí multicastu v lokální síti pomocí nástroje DVBlast z dílny VideoLAN:
    $ cat dvbt2-praha.cfg
    #[:][/udp]             [,]*
    #CT HD
    239.194.10.51:1234      0       272
    #Nova HD
    239.194.10.52:1234      0       528
    #Prima HD
    239.194.10.53:1234      0       771
    #Barrandov HD
    239.194.10.54:1234      0       2050
    
    $ dvblast -a0 -e -f 506000000 -c dvbt2-praha.cfg -t 12  2>&1 | \
      perl -pne 'print scalar(localtime()), " ";'

    Poznámka: Volání Perlu na konci posledního příkazu slouží pouze pro označkování jednotlivých řádků standardního výstupu časovým razítkem, na vlastní funkci nemá vliv.

Závěr

Bylo až překvapivé, jak to šlo nakonec snadno. Projekt experimentálního IPTV vysílání na Strahovských kolejích dostal čtyři nové HD programy v plném rozlišení a s vysokým datovým tokem. Protože je v této síti připojeno na čtyři tisíce uživatelů, znamená to zároveň také, že se mi nejspíše podařilo řádově zvýšit pokrytí experimentálního vysílání DVB-T2, co do počtu potenciálních diváků.

Doufám jen, že vývoj na tomto (prvním použitelném) bodě neustrne, ovladač bude zařazen do hlavní větve jádra, bude zveřejněno Linux DVB API verze 5.3 s podporou DVB-T2 a s tím dojde k doplnění potřebné funkcionality do uživatelských aplikací. To vše je však běh na dlouhou trať.

Time.is nyní česky!

Ondřej Caletka, 4. 04. 2011, 11:08 v kategorii Nezařazené,

Patřím mezi lidi, které ostatní označují jako „úchyláci na přesný čas“. Doma máme v každé místnosti alespoň jedny nástěnné hodiny, řízené signálem DCF-77, všechny počítače, které spravuji, disponují nějakou variantou NTP klienta. Proto mě velmi potěšilo, když jsem dostal tip na stránku Time.is.

Jedná se o jednoduchou JavaScriptovou stránku, jejím primárním cílem je jediné: Ukazovat přesný čas a to nezávisle na systémových hodinách počítače, na kterém běží prohlížeč. Umí toho ale mnohem víc: Automaticky vypočítává odchylku systémových hodin od času Time.is, nedělá jí problém zcela korektní přechod na letní čas a zpět, stejně jako zobrazování světového času.

Ani to ale není všechno, stránka obsahuje databázi světových míst, počítá čas východu a západu slunce a také generuje jednoduchý, ale praktický kalendář, který se dá také snadno vytisknout. Perličkou na pomyslném dortu je podpora zvukového znamení, stejně jako celostránková verze Google map.

A proč to všechno píšu? Tento web je od nynějška dostupný v české mutaci. Stačilo vyměnit si s jeho autorem pár e-mailů a český překlad je na světě. Autor dokonce zohlednil národní specifika, jako například používání shodných přívlastků (14. týden namísto týden 14), správné koncovky pro různá množství (o 1 sekundu, o 2-4 sekundy, o 5 sekund), nebo skloněné názvy kalendářních měsíců (4. dubna, ale duben 2011).

Přejme tedy společně webu mnoho spokojených zákazníků. Objevíte-li chybu v překladu, můžete ji napsat přímo mně.

Archivujeme televizní pořady

Ondřej Caletka, 1. 01. 2011, 00:01 v kategorii Linux,

Digitalizace televizního vysílání s sebou přináší, kromě rozšíření programové nabídky a (povětšinou) zlepšení kvality příjmu, také výrazné zjednodušení pořizování záznamu. Zatímco v případě analogového vysílání bylo nutno vysílání digitalizovat, digitální vysílání stačí pouze ukládat. O to složitější může být najít si čas na přehrání již nahraného záznamu. Zvlášť  po Vánocích.

V dnešním zápisku jsem se proto rozhodl představit způsob, jakým archivuji nahrávky digitálního televizního vysílání tak, aby nezabraly zbytečně mnoho místa při pokud možno zachování původní kvality. Protože archivuji pro vlastní potřebu, necítím se být svázán pravidly releasů warezových skupin, například že dvacetiminutová epizoda ve standardním rozlišení musí zabírat přesně čtvrtinu CD (175 MB) a podobně. Vypalování archívu na optické disky jsem vzdal už dávno; jsou s nimi jen problémy a ve výsledku zaberou mnohem více místa než jeden 3,5" hard disk…

Krok 1 – záznam

Tento krok záznamu nehodlám podrobně popisovat, neboť ten můj je nejspíše velmi odlišný od způsobu, který používají ostatní. K pořizování záznamu používám projekt DVBgrab, víceuživatelský virtuální videorekordér s webovým rozhraním. Ten na základě XMLTV programu generuje televizní program, ve kterém je možno jedním kliknutím označit pořad k nahrání. Pro záznam z vysílání ČT jsem do svého DVBgrabu integroval filtr vpsrecord, díky kterému jsou pořady České Televize zaznamenány přesně od skutečného začátku do skutečného konce pořadu.

V každém případě, ať zvolíte jakýkoli druh záznamu, výsledkem by měl být MPEG2 Transport Stream, uložený v souboru.

Krok 2 – střih a demultiplexování

Záznam ve formátu MPEG-TS je možné bez větších problémů zpětně přehrát všemi majoritními přehrávači. Jde o soubor složený ze 188 bajtů dlouhých paketů, který každý začíná znakem 0x47, ASCII „G“. Již z toho vyplývá, že jde o formát pro archivaci poměrně nevhodný, neboť je neúsporný a postrádá jakýkoli index. Navíc vlivem poruch při příjmu může soubor obsahovat poškozené, nebo chybějící snímky.

Před dalším zpracováním je potřeba záznam demultiplexovat na obrazovou a zvukovou stopu. K tomu se mi  z celé škály možností osvědčil program s názvem Project-X. Načte téměř jakýkoli MPEG-2 soubor a identifikuje v něm proudy obrazu, zvuku a případně i titulků či teletextu. Umožňuje jednoduchý střih na úrovní skupin obrázků (GOP), což v televizním vysílání představuje přibližně 12 − 15 snímků, tedy půl sekundy. Takovým střihem je obvykle nemožné zcela přesně vystřihnout reklamní přestávku, na druhou stranu jde o střih velice rychlý a na rozdíl od jiných snímkově přesných metod, které jsem vyzkoušel, vždy plně funkční.

Při exportu demultiplexovaného obrazu a zvuku se Project-X postará o to, aby byl obraz a zvuk za každou cenu synchronní. Toho dosahuje tak, že ze zvukové stopy odmazává zvukové rámce korespondující s poškozenými obrázky, nebo naopak ztracené zvukové rámce nahrazuje tichými. Jako příjemný bonus, který se uplatní u televizního vysílání a zvláště ČT, je možnost exportování skrytých podtitulků, vysílaných v teletextu, do klasického textového souboru.

Krok 3 – vlastní transkódování

Možností, co dělat s demultiplexovaným zvukem a obrazem, je spousta. Dříve jsem používal velice jednoduchý skriptík pro konverzi do formátu, kterému se obvykle říká DivX, tedy MPEG-4 ASP video, MPEG 1 Layer 3 audio, to celé zabalené v kontejneru OpenDML AVI. Tento formát však má své limity – například předpokládá, že poměr stran pixelů je 1:1, což u televizního vysílání ve standardním rozlišení není splněno…

Protože od éry AVI souborů s DivX kodekem doba drobně pokročila, rozhodl jsem se proces inovovat. Použil jsem moderní kodek MPEG-4 Part 10 (AVC), neboli H.264 pro obraz a k tomu odpovídající MPEG2 AAC pro zvuk. Pouze na pozici kontejneru jsem si dovolil odchýlit se od standardu a použít nestandardní, ale velmi rozšířený kontejner Matroška.

Nakonec jsem napsal skript, používající ffmpeg, normalize a faac pro konverzi zvukové stopy do formátu AAC s normalizací měřítka a mplayer s x264 pro překódování videa. Moje použití vypadá takto:

  1. V Project-X mám nastaveno, aby při exportování vytvořil adresář s demultiplexovanými stopami.
  2. Do tohoto adresáře nakopíruji zmíněný skript.
  3. Skript upravím podle parametrů aktuálního pořadu (především poměr stran a prokládání).
  4. Skript spustím, jako první parametr uvedu společný název souborů se stopami, jako druhý parametr cestu a jméno cílového souboru bez přípony.

Skript nejprve překonvertuje zvukovou stopu, poté spustí konverzi videa. Při mých testech se ukázalo, že není nutné používat dvouprůchodové kódování, zvlášť pokud netrváme na dodržení přesné velikosti výsledného souboru. Na samý závěr je obraz a zvuk multiplexován do výsledného kontejneru a to i s případnými skrytými titulky, které Matroška umí nastavit skutečně jako skryté (tedy že se objeví až po explicitním zapnutí).

Pokud zdrojový obraz obsahuje artefakty prokládání řádků, je pro jejich odstranění použit filtr yadif z mplayera, který dlouhodobě hodnotím jako nejlepší deinterlace filtr na poli open source. Je nutné poznamenat, že takovéto použití deinterlace filtru se nehodí pro sportovní přenosy s rychlými pohyby. V takovém případě by bylo vhodné použít variantu filtru yadif, která zdvojnásobuje snímkovou rychlost. Vyzkoušel jsem, že takové zvýšení způsobí při stejném faktoru kvality nárůst velikosti výsledného souboru o dvě třetiny, což mi připadá neúměrně mnoho. Protože sportovní přenosy nezaznamenávám, výzkum jsem na tomto místě přerušil a spokojil se s 25 snímky za sekundu.

Poznámka o poměru stran

Na tomto místě si dovolím malou poznámku o poměru stran obrazu, neboť se v tom často chybuje. Informace o poměru stran 4:3 nebo 16:9 totiž platí pro analogovou televizi. Jelikož ta digitální vznikla digitalizací analogové, bylo potřeba zaručit, že v digitálním obraze bude určitě všechno, co je v analogu. Proto digitalizací vznikne obraz poněkud širší. V případě PALu se poměr stran 4:3 nebo 16:9 vztahuje k horizontálnímu rozměru cca. 702,9 pixelu, nikoli k celé šířce obrazu 720. Protože počet pixelů nemůže být neceločíselný, zaokrouhluje se tato hodnota na 704 pixelů. Ideální digitalizovaný obraz tedy je zleva i zprava o osm pixelů širší, tyto pixely by měly být černé. V reálném případě je obraz obvykle posunut k některé straně, nebo klidně vyplňuje celou šířku 720 pixelů. Pak je jeho reálný poměr stran širší než 4:3 a 16:9.

Mnoho programů pracujících s videem, včetně např. mplayera, nebo VLC, tento fakt ignoruje a obraz 720×576 škáluje na 768×576 v případě 4:3 a 1024×576 v případě 16:9. Dochází tím k drobnému poškození proporcí obrazu, takové poškození je však jen těžko měřitelné a ještě hůře pozorovatelné člověkem.

Vzhledem k tomu, že můj skript nemění velikost obrazu, je rozhodnutí o výsledném poměru stran pouze nastavením metainformace o poměru stran pixelů. Nejběžnější varianty jsou vypsány přímo ve skriptu v tabulce, a každý nechť se rozhodne mezi tím, co je snadné (SAR1) a tím, co je správné (SAR2). Případně můžeme doplnit ještě hodnoty, které by odpovídaly úplně správnému poměru stran – takovému, který bere jako základ šířku 702,9 pixelů (SAR3)

##  DAR -  SAR1 -  SAR2 -   SAR3
## 16:9 - 64:45 - 16:11 - 118:81
##  4:3 - 16:15 - 12:11 -  59:54

Pro podrobnější studium doporučuji například článek zde, nebo na Wikipedii.

Závěr

Popsal jsem jeden z možných postupů, jak jednoduše archivovat televizní pořady. Díky použití standardizovaných kodeků by výsledný záznam měl být bez větších problémů přehratelný i na nejrůznějších hardwarových MPEG-4 přehrávačích. Použitím skriptovacích jazyků je možné postup zautomatizovat do té míry, že je jeho použití jednodušší, než shánění nelegálně zveřejněných TV-ripů na warezových fórech.

Přeji všem čtenářům, kteří dočetli až sem, vše nejlepší v roce 2011!

Praktické problémy s IPv6, část třetí

Ondřej Caletka, 4. 11. 2010, 10:30 v kategorii Sítě,

Od napsání předchozích epizod se na poli českého IPv6 udála zásadní událost. Servery společnosti Internet Info, včetně tohoto blogu, jsou přístupné přes IPv6. Že jste si ani nevšimli? Tak to má být. Zřejmě to s těmi problémy kolem IPv6 není tak žhavé... I přesto si dovolím dokončit několik kapitol o problémech s tímto protokolem.

Nechtěné Man-in-the-Middle útoky

Útok typu M-i-t-M je asi to nejzákeřnější, co může útočník na síti dělat. Je to také často jediná použitelná cesta, jak odposlouchat šifrované spojení, pokud uživatelé nejsou důslední v ověřování autenticity protistrany.  Klíčovou podmínkou pro provedení takového útoku je přesměrování veškeré komunikace tak, aby procházela počítačem útočníka. Na IPv6 je takové přesměrování běžným jevem. Stačí k němu počítač s MS Windows ve verzi Vista nebo vyšší a z nějakého důvodu zapnutá služba sdílení připojení k Internetu (ICS). Tato služba totiž kromě NATu, pokud nadetekuje veřejnou externí adresu, aktivuje také 6to4 směrovač, který do sítě nabízí 6to4 IPv6 adresy formou bezestavové konfigurace. Za to patří Microsoftu pochvala, jak jsem uvedl v prvním díle, pokud by se tak chovala většina NATů, měli bychom přechod na IPv6 dávno za sebou. Bohužel, celé to evidentně není tak doladěné, jak by být mělo − běžně se stává, že počítač posílá ohlášení směrovače i zpátky externím rozhraním (!). Vzhledem k povaze automatické konfigurace IPv6 dojde vpodstatě okamžitě k přesměrování IPv6 provozu přes stanici „útočníka“. Situaci naznačuje následující obrázek.

Faktický důsledek této situace není ani tak bezpečnostní, jako spíš výkonnostní. Klientské stanice s MS Windows obvykle nejsou dimenzovány na směrování síťového provozu, navíc je může uživatel kdykoli vypnout a tím všechna spojení přerušit.

Třídy adres a provisioning nastavení

Už v předchozím díle jsem nakousl, že bezestavová automatická konfigurace mimo jiné neumí sdělit klientovi, že v dané síti fungují pouze určité IP adresy. Takže pokud takové omezení v síti platí, je nutné každou stanici ručně zkonfigurovat.

Další velice zajímavé volby skrývá tabulka priorit adres, v Linuxu uložená v souboru /etc/gai.conf. Zatímco v IPv4 světě se tak nějak počítalo, že jedno síťové rozhraní má jen jednu IP adresu, koncept IPv6 počítá s tím, že jedno rozhraní má adres několik. Stejně tak se počítá s tím, že odpověď na DNS dotaz obsahuje více adres. Jsou definována přesná poměrně sofistikovaná pravidla, jakou adresu vybrat jak na straně zdroje, tak i na straně cíle.

Výchozí nastavení například předepisuje, že pokud je dostupné spojení po IPv4 i IPv6, dá se přednost IPv6. Navíc jsou rozsahy IP adres tříděny do skupin a upřednostňují se spojení v rámci jedné skupiny. Tím se má v maximální možné míře eliminovat používání prostředníků - Teredo adresa si k sobě vybere jen Teredo adresu, 6to4 jen 6to4 adresu a nativní IPv6 adresa jen nativní adresu. Systém nám trochu drhne v tom, že žádný producent obsahu nepublikuje 6to4 adresu v DNS, a také v tom, že velká část „nativních“ IPv6 adres je ve skutečnosti tunelovaných.

Chceme-li zavést IPv6 do prostředí s již zavedeným IPv4 protokolem, mohli bychom předejít některým problémům upravením tabulky priorit tak, aby  spojení po IPv4 protokolu dostalo maximální prioritu, a spojení přes IPv6 se používalo pouze v případě, že není zbytí.  Takové nastavení je velmi rozumné - zaručuje totiž, že co fungovalo doteď, to bude fungovat nadále bez problému a případné problémy nastanou jen s obsahem, který by bez IPv6 vůbec dostupný nebyl.

I v tomto případě ale nezbývá, než všechny stanice obejít a ručně konfiguraci změnit. Nicméně osobně nemám dojem, že by to bylo zcela špatně. Rozhodnutí o preferování určitých adres by dle mého názoru mělo být v kompetenci správce počítače, nikoli správce sítě.

Blýská se na lepší časy?

S IPv6 to není tak špatné, ale neznamená to, že by nemohlo být lépe. Zkusím v několika bodech shrnout, jak si představuji budoucnost:

  • Tunelování, ať už nativní, nebo 6to4 se stane minulostí. Pokud dojde k rozšíření IPv6-only obsahu, je možné, že se začne více používat Teredo, jednoduše proto, že nepotřebuje žádnou podporu ze strany síťové infrastruktury, a zároveň je předinstalováno takřka v každých MS Windows.
  • Správci menších sítí se postupně smíří s tím, že na IPv6 není možné získat úplnou kontrolu nad přidělováním IPv6 adres a pro jednoduchost budou používat bezestavovou konfiguraci, případně doplněnou o bezestavové DHCP. Větší sítě budou každého uživatele připojovat do samostatné VLANy a/nebo použijí DHCPv6.
  • Problém rušivých RA dostane řešení, např. v podobě rozšíření „RA-guard“ v síťových přepínačích, které zabrání klientským stanicím vůbec do sítě odesílat ohlášení směrovače. V menších sítích, jejíchž aktivní prvky takové možnosti nenabízí, lze k podobnému účelu použít démon Ramond, který rušivým RA nezabrání, ale hbitě odčiní jejich efekt zasláním „mazacích RA“. Další možnosti shrnuje dokument „Rogue RA Problem statement“.
  • Naučit se budou muset také poskytovatelé obsahu. Zatímco dnes k odstřihnutí zlobivého uživatele obvykle stačí zablokovat jeho IP adresu, bude u IPv6 nezbytné blokovat přinejmenším celou podsíť /64, pokud se realizuje vize, že každý zákazník včetně domácích dostane rozsah /48, bude jej zřejmě nutné zablokovat celý. Problém vidím v tom, že stejně dlouhý prefix dostane jak jedna domácí přípojka (efektivně jeden uživatel), tak například celé ČVUT (~ 10000 uživatelů). Nikde není ani dáno, že všechny podsítě používají délku prefixu /64. Viděl bych to tak, že časem vznikne databáze IP adres a k nim relevantních délek prefixu. Nejde ale jen o odstřihování uživatelů. Stejný problém bude nutné vyřešit v nejrůznějších webových anketách, pro ztížení možnosti manipulace výsledků.

Končí prozatím poslední díl miniseriálu. Jak už jsem zmínil v úvodu, v moři zvaném IPv6 se hnuly ledy. Zpřístupnění webů Internet Infa považuji za velký krok pro české IPv6. Ukazuje se, že ani komerční poskytovatelé obsahu nemusí mít strach, že by vystavením AAAA záznamů pro své domény přišly o zákazníky. Kdo bude následovat? Seznam, Idnes, nebo snad TN.cz? Nechme se překvapit.

Praktické problémy s IPv6, část druhá

Ondřej Caletka, 27. 09. 2010, 09:05 v kategorii Sítě,

Jak jsem minule slíbil, v dnešním díle seriálu se zaměřím na problematiku IPv6 z pohledu správce sítě. Ani oni to nemají s příchodem IPv6 snadné, zvlášť pokud si chtějí v síti zachovat pořádek.

Automatická konfigurace

Na začátek malá exkurze do historie. V době, kdy vznikal protokol IPv4, se rozměry počítačů neudávaly v jednotkách U, ale v počtu sálů. Každý takový počítač měl k dispozici dostatečně erudovaného správce, pro kterého nebyl problém při instalaci nastavit celý systém, včetně IP adresy a směrovací tabulky. Teprve s rozmachem Internetu se objevila potřeba konfigurovat aspoň ty nejnutnější parametry IP protokolu automaticky. Tak vznikly postupně protokoly BOOTP a DHCP, bez kterých si dnes síťování nedovedeme představit.

IPv6 je zařízeno fundamentálně odlišně, už v návrhu bylo počítáno s nutností automatické konfigurace. Ta zde není nadstavbovým protokolem, který by zkonfiguroval původně statické parametry protokolu, ale přímo integrální součástí protokolu. Došlo to tak daleko, že každé síťové rozhraní získá svojí první IPv6 adresu prakticky ihned po aktivaci rozhraní, aniž by síťový kabel vůbec někam vedl. Počítač ji vytvoří slepením prefixu linkové adresy (fe80::/64) a 64-bitového identifikátoru rozhraní.

V obdobném duchu funguje i konfigurace směrování, každý směrovač vysílá do sítě ohlášení, podle kterých stanice nastavují svou směrovací tabulku. Velmi vzdáleně to připomíná například směrovací protokol RIP.

Úskalí autokonfigurace

Výše popsaná bezestavová autokonfigurace funguje velice dobře a jednoduše. Její zásadní problém spočívá v tom, že adresy nejsou koncovým zařízením přidělovány (jako např. u DHCPv4), ale jsou vytvořeny spoluprací sítě, která dodá prefix a zařízení, které dodá identifikátor rozhraní. V dřevních dobách IPv6 to zas takový problém nebyl – identifikátor rozhraní byl prakticky vždy odvozen z MAC adresy ethernetového rozhraní.

Pak ale přišli lidé, nazvěme je třeba novotvarem privateroristi, kterým se zdálo, že MAC adresa síťové karty je příliš unikátní číslo, a že by na základě této adresy mohli ostatní uživatelé Internetu sledovat pohyb zařízení mezi různými sítěmi. Bez ohledu na to, že takové sledování je dost dobře možné už dnes (stačí k tomu třeba obyčejné cookie v prohlížeči), byl argument uznán jako oprávněný, a vzniklo RFC 4941, které k pevným idenrifikátorům rozhraní přidává ještě další,  náhodně volené, v čase proměnlivé identifikátory. Klientské systémy s MS Windows si v rámci ještě většího soukromí ani pevný identifikátor neodvodí z MAC adresy, ale náhodně zvolí při prvním startu.

DHCPv6

I když je bezestavová autokonfigurace zabudovaná v protokolu vcelku použitelná, byl nakonec vyvinut i pro IPv6 protokol DHCP. Vývojáři tehdy měli možnost vybrat mezi  drobným rozšířením stávajícího DHCP tak, aby umělo poskytovat i IPv6 adresy a zásadním přepracováním protokolu tak, aby řešil problémy, které se za dobu existence „starého“ DHCP objevily. Vývojáři se vydali druhou cestou, a za sebe říkám bohužel.

Ve starém DHCP byla základním identifikátorem MAC adresa. Na základě té se vyhledal na DHCP serveru záznam v databázi konfigurací a následně byla klientovi nabídnuta odpovídající adresa, jako i další parametry. Tento systém začal drobně selhávat zejména s rozmachem notebooků, vybavených jak ethernetem, tak i wi-fi adaptérem, každý samozřejmě s jinou MAC adresou. Pro DHCPv4 server takový notebook vypadá jako dva zcela nezávislé počítače, nemá  možnost zjistit, že jde ve skutečnosti o jeden systém. DHCPv6 tento drobný problém řeší. Bohužel, řešení je tak svérázné, že zároveň způsobuje několik mnohem fatálnějších problémů.

DHCPv6 se rozhodlo jít cestou zavedení nových identifikátorů. Každý počítač dostane jedinečný identifikátor DUID, každé síťové rozhraní daného počítače IAID. Nápad to není špatný. Praktická realizace ale jednoznačně špatná je.  Všechny současné PC systémy implementující DHCPv6 používají DUID typu 1, což je identifikátor odvozený z MAC adresy jedné (náhodně volené) síťové karty a časového razítka prvního startu operačního systému. Tento identifikátor je uložen na pevném disku, z principu jej není možné predikovat.

Sečteno a podtrženo, takové řešení přináší tyto nové problémy:

  • Máme-li multi-boot systém, každý z operačních systémů bude pro DHCPv6 zcela jiným počítačem. Pokud budeme chtít stanici startovat ze sítě pomocí DHCPv6, bude startovací firmware pro server dalším nezávislým počítačem.
  • Naopak používáme-li klonování pro hromadnou instalaci více počítačů, budou všechny klonované počítače pro DHCPv6 server vystupovat jako jeden.
  • Vazba na MAC adresu síťové karty je nahrazena vazbou na soubor na disku. Každý, kdo kdy měl něco do činění s MS Windows ví, že na jeden život síťové karty (=1 MAC adresa) připadá několik, možná i desítka reinstalací operačního systému (a tedy 10 různých DUIDů)
  • Snad všechny DHCPv6 servery, které jsem testoval, umožňují  nastavit statickou IP adresu pro daný DUID, podobně jako IPv4 servery umožňují pevné mapování MAC adresy a IP adresy. Jenže u IPv6 je to špatně. DUID je identifikátor počítače, ten má obecně víc rozhraní rozlišených podle IAID. Současné DHCP servery tedy přiřadí stejnou adresu všem rozhraním jednoho počítače. Dalších komentářů netřeba.

Správce sítě, který se rozhodne mít v síti pořádek má obvykle velkou tabulku s jménem PC, MAC adresou, IP adresou. Napadne ho, že by snad mohl existovat DHCPv6 server „v kompatibilním režimu“, který by na celý koncept s DUID a IAID kašlal a identifikoval klienta hezky postaru podle MAC adresy. Jenže neexistuje. A co víc, tvůrci protokolu DHCPv6 takovému přístupu aktivně brání, například tím, že z DHCPv6 zprávy odstranili informační pole s MAC adresou klienta. Případný „kompatibilní server“ by se tedy musel uchýlit ke sniffování MAC adresy, ze které požadavek přišel. Jenže tohle může fungovat jen tam, kde se nepoužívají DHCP relay agenti. Pro další studium si dovoluji odkázat na vlákno „Pre-determining DUID“ v archivu mailing listu DHC WG, zejména příspěvek Teda Lemona, jednoho z tvůrců protokolu, který právě existenci zmíněného „kompatibilního serveru“ rezolutně odmítl.

Konec druhé části

V knize o IPv6 situaci kolem autokonfigurace Pavel Satrapa glosuje humorem sobě vlastním:

Chaos v síti. Divocí uživatelé zapojující bez jakékoli kontroly a evidence nejrůznější aparáty. Jak v takové situaci řešit problémy, které způsobí? Jak odpovídat na dopisy „Tehdy a tehdy byl na počítači s adresou X z Vaší sítě nabízen P2P službou Y film „Zachraňte vojína Ryana“. Zbylo nám tu z natáčení pár tanků, tak s tím koukejte rychle něco udělat, nebo s nimi přijedeme!“

Skutečně současný stav autokonfigurace nahrává spíše nepořádníkům. Lidem, kteří chtějí mít v síti pořádek, zbývají v podstatě dvě cesty - buď zablokovat na nejbližším routeru všechny adresy kromě adres odvozených z MAC adres (a že se to dělá, dokazuje i existence modulu eui64 pro ip6tables), nebo nasadit sledovací software, který bude sledovat jaké IPv6 adresy který počítač právě používá. Oba přístupy ale tak říkajíc kulhají na obě nohy…

V tomto místě ukončuji druhý díl seriálu. Na třetí a snad i poslední díl zbývají témata, která s autokonfigurací celkem dost souvisí:

  • Nechtěné Man-in-the-Middle útoky
  • Ochrana soukromí vs. odpovědnost za obsah

Praktické problémy s IPv6, část první

Ondřej Caletka, 1. 09. 2010, 08:00 v kategorii Sítě,

Mám dojem, že poslední dobou sílí mediální kampaň proti IPv6. Na Rootovi (zde) a Lupě (1, 2) se objevují články, které se více či méně fundovaně snaží naznačit, že až dojdou IPv4 adresy, nasadíme další a další NATy a Internet bude fungovat jako dřív. A v tuto chvíli přicházím já se svou troškou do mlýna. Tímto příspěvkem bych rád poukázal na konkrétní problémy, se kterými se dřív či později setká každý, kdo se rozhodne IPv6 nasadit.

Méněcenné IPv6 adresy

Ve skutečnosti nebylo nutné s nasazením IPv6 čekat až na pověstný den, kdy zemřely směrovače. Díky přechodovým mechanizmům, jakými je Teredo, nebo (zejména) 6to4 by bylo bývalo možné,  abychom si po IPv6 povídali leta před tím, než se z toho stane nutnost. Obě jmenované přechodové technologie umožňují přímou komunikaci koncových bodů bez prostředníka; toho potřebují jen pro spojení s nativním IPv6 světem. V ideálním stavu už měl veškerý IPv4 obsah i svou 6to4 IPv6 adresu, protože zde platí ekvivalence:

Mám veřejnou IPv4 adresu <=> Mám k dispozici IPv6 prefix 2002:IPAD:RESA::/48

Protože jde o překlad bezestavový a oproti např. NAT naprosto triviální, nebyl by problém implementovat jej do každé krabičky která provádí NAT. V takovém ideálním světě by ani nebylo potřeba vyvíjet mnohem složitější technologii Teredo (která za pomoci velikého úsilí dokáže získat jednu IPv6 adresu z jakékoli neveřejné IPv4 adresy), ani různé obezličky typu Universal Plug&Play. Prostě by aplikace, potřebující propíchnout NAT, přešly na IPv6.

A teď zpátky do reality. Všichni poskytovatelé obsahu, kteří již dnes poskytují obsah po IPv6, zveřejňují pouze tzv. nativní IPv6 adresu. To znamená, že osvícení klienti, kteří si rozchodili Teredo, či 6to4, přistupují přes prostředníka (jednoho takového nedávno spustil CZ NIC), který má z principu omezené kapacity a ve smluvním vztahu Klient - ISP nebo ISP - Server je třetí stranou, bez odpovědnosti.  V případě 6to4 je navíc typicky různý prostředník pro každý směr provozu, což ještě víc ztěžuje případné hledání závad.

Dá se tedy říci, že 6to4 nefunguje ze stejného důvodu, proč nefunguje nativní IPv6 - poskytovatelé obsahu nemají zájem. A tak jsou adresní rozsahy 2002::/16 a 2001::/32 tak trochu méněcenné oproti nativním IPv6 adresám.

Tunelování zabíjí IPv6

Pokud chceme být opravdu IPv6 ready, a přitom náš ISP je lama, můžeme si zařídit statický tunel s klasickou „nativní“ IPv6 adresou, takže nikdo na první pohled nepozná, že náš IPv6 provoz je celý směřován kudysi přes tramtárii, kde když už nic, tak alespoň nabere nějakých 30ms zpoždění a to je ten lepší případ.

Problém je, že takových IPv6 ready klientů s lamáckými ISP je až příliš mnoho. Když se sejdou dva sousedi z jednoho paneláku, kteří by si rádi napřímo popovídali pomocí nějakého VoIP protokolu, mají na výběr buď IPv6, nebo všeliké pracné „propichování“ NATu. No a protože jsou to lidé osvícení, použijí IPv6. Jenomže každý má natažený tunel do jiné tramtárie, takže se nám RTT vyšplhá přes 200ms, zatímco po IPv4, pokud se povede NAT propíchnout, máme RTT do 50ms. A to se na u VoIP celkem jasně pozná.

Jiní dva sousedé si budou chtít poslat nejnovější HD film: „Jaktože to najednou jde jen 20kB/s, když to vždycky šlo 200kB/s ?“ - „Nojo nasadili jsme IPv6, a druhý konec tunelu je (zase) přetížen. Stačí vypnout IPv6, a pojedeme zase plnou rychlostí“

Můžeme tedy parafrázovat známou hlášku, že IPv6 je sice delší, ale zato mnohem horší cesta.

Konec první části

Kdybych chtěl sepsat vše, co mám k IPv6 na srdci, byl by příspěvek příliš dlouhý. Proto jsem se rozhodl pro  „seriálovou“ formu. V příští části se pokusím rozebrat problémy nasazení IPv6 z pohledu druhé strany:

  • Automatická konfigurace a DHCPv6
  • Nechtěné Man-in-the-Middle útoky
  • Ochrana soukromí vs. odpovědnost za obsah