V úterý 6. června 2017 jsme pořádali už druhý ročník celodenního semináře o IPv6. Akce konaná v den pátého výročí celosvětového spuštění IPv6 vyvolala velký ohlas, nakonec dorazilo 291 účastníků a zhruba stovka sledovala přímý přenos. Pokud jste seminář nestihli, můžete se k němu zpětně vrátit na stránce akce, kde jsou k dispozici záznamy všech přednášek. V tomto příspěvku bych rád popsal podrobnosti o jednom malém bodu doprovodného programu – IPv6-only Wi-Fi síti.
Budova ČVUT, ve které se seminář konal, je plně pokryta Wi-Fi sítí eduroam. Bohužel ale stále pouze s IPv4 konektivitou. Přinesl jsem tedy vlastní router Turris Omnia, který poskytoval naopak pouze IPv6 konektivitu, ovšem s technologií NAT64/DNS64, která zajišťuje téměř plnohodnotný přístup i k IPv4 zdrojům. Měl jsem v záloze připravený OpenVPN tunel, kterým by bylo možné do routeru přivést IPv6 z páteřní sítě CESNETu, ale nebylo to zapotřebí, díky velké ochotě Iva Hulínského z FEL ČVUT. Vlastní router získal od FEL ČVUT nativní IPv4 i IPv6 konektivitu i delegovaný prefix pro vlastní
bezdrátovou síť. Zbylo tedy zajistit NAT64/DNS64.
Minulý rok jsem jako NAT64 použil jednoduchý překladač TAYGA, pracující v uživatelském prostoru. Nevyniká sice výkonností, ale je jednoduchý na nastavení a zprovoznění, zejména na OpenWRT, kde jsem k němu už před časem přidal integraci do konfiguračního systému netifd. Letos jsem měl nutkání vyzkoušel Jool, implementaci NAT64 v linuxovém jádře, která by měla být mnohem výkonnější. Nakonec však, jak už to bývá, nezbyl čas ani na zkompilování modulu pro aktuální jádro, použité v Omnii.
Problémy s DNS64
Zbývající komponentou bylo DNS64, ošklivý špinavý trik s DNS, který se snaží předstírat, že každé doménové jméno má k dipozici IPv6 adresu. Tato funkce je k dispozici v DNS resolverech BIND, Unbound i Knot DNS Resolver, stejně jako v cloudové službě Google Public DNS64. Výchozí volbou v Omnii je Knot DNS Resolver, takže volba na něj padla jako první. Konfigurace je triviální, stačí načíst příslušný modul a nastavit IPv6 prefix, do kterého bude IPv4 provoz mapován.
Ještě během testování o víkendu jsem však narazil, to když jsem si chtěl zarezervovat autobusovou jízdenku. Stránka jizdenky.regiojet.cz, totiž vypadala nějak jinak, než obvykle. Nejdřív jsem podezříval že došlo k nějakému redesignu, když jsem se však ani po minutě klikání nenašel formulář pro zadání požadované cesty, začal jsem hledat problém v funkčnosti na síti s NAT64.
K testování funkčnosti webových stránek na NAT64 se výborně hodí nástroj NAT64check od Sandera Steffana a Jana Žorže. Tato webová aplikace otestuje zadanou URL z IPv4-only sítě, čisté IPv6-only sítě a nakonec i z IPv6-only sítě s NAT64/DNS64. Ve všech třech případech vygeneruje náhledy daných URL, které pak porovná mezi sebou. Když jsem nechal otestovat výše uvedenou stránku, zjistil jsem, že stránka nemá problém s NAT64, ale jen s čistým IPv6-only a že v mém prohlížeči vypadá přesně tak, jako v v testeru vypadá na IPv6-only.
Ukázalo se, že problém je v DNS64 implementaci v Knot Resolveru. Problematickou adresou je www.regiojet.cz. Té chybí IPv6 adresa a ještě je navíc aliasovaná (na tom ovšem není nic špatného):
$ host www.regiojet.cz
www.regiojet.cz is an alias for brn-web02.sa.cz.
brn-web02.sa.cz has address 217.66.178.225
Knot DNS resolver vrátil nejprve jen informaci o aliasu, po vypnutí forwardingu na nadřazený DNS server se problém zdál být vyřešený:
$ dig www.regiojet.cz aaaa
…
;; ANSWER SECTION:
brn-web02.sa.cz. 3310 IN AAAA 64:ff9b::d942:b2e1
www.regiojet.cz. 3310 IN CNAME brn-web02.sa.cz.
Jenže ani to nefungovalo a webový prohlížeč sveřepě tvrdil, že daná stránka neexistuje. Přepnul jsem tedy na Unbound, který je v Omnii také předinstalovaný a porovnal odpovědi. Ukázalo se, že na pořadí záleží, Unbound totiž servíroval záznamy v odpovědi v opačném pořadí (tedy nejprve CNAME a pak AAAA) a s tím byl prohlížeč spokojen. Nahlásil jsem tedy chybu vývojářům Knot Resolveru. Petr Špaček následně dohledal, že RFC 1034 opravdu požaduje, aby řetězec případných CNAME záznamů předcházel finální odpovědi. A vlastně to je i logické: pokud klient poptává adresu doménového jména www.regiojet.cz a dostane zpátky odpověď obsahující doménové jméno brn-web02.sa.cz., musí dospět k závěru, že mu odpověď nepatří.
Izolovaná síť s off-link prefixem
Na minulém ročníku jsem hovořil o jedné z výhod IPv6, která umožňuje zmírňovat problémy způsobené sdílenou spojovou vrstvou, zejména ve veřejných sítích. Řešením je zapnutí izolace klientů (často také nazývané Private VLAN), kde L2 koncentrátor (Wi-Fi AP, nebo bridge/switch) neumožní komunikaci mezi jednotlivými klienty navzájem. Tahle metoda tedy není specifická pro IPv6, používá se i v IPv4, ale v IPv4 trpí nedostatkem, že po její aktivaci není možná vůbec žádná komunikace mezi zařízeními ve stejné síti. To z toho důvodu, že v IPv4 se vždy používá síťová maska k určení, která zařízení jsou dostupná přímo a která prostřednictvím brány. Zařízení, která jsou podle masky přímo dostupná však spolu kvůli izolaci komunikovat nemohou.
IPv6 nabízí elegantní nástroj jak tenhle problém s izolací řešit – takzvané off-link prefixy. V ohlášení směrovače se jednoduše u příslušného prefixu vypne příznak L. Tím se sděluje, že daný prefix není na lince, takže byť z něj má zařízení přidělenou adresu, měla by veškerý provoz směrovat na výchozí bránu. Výchozí brána je přitom vždy dostupná, neboť používá link-local adresu.
Aby to skutečně mohlo fungovat podle plánu, je třeba zabránit směrovači v odesílání ICMP zprávy o přesměrování. Tyto zprávy směrovač automaticky generuje v případě, že zjistí, že odesílá datagram stejnou linkou, ze které přišel, v zájmu zkrácení cesty. V případě Linuxu zřejmě neexistuje volba, která by generování takovýchto přesměrování v IPv6 vypínala, takže bylo třeba uchýlit se k pravidlu pro firewall:
# ip6tables -A output_lan_rule -p icmpv6 --icmpv6-type redirect -j DROP
A konečně posledním krokem je zablokovat přeposílání paketů v rámci linuxového bridge, který přemosťoval drátové a bezdrátové porty pro různá Wi-Fi pásma tak, aby škodlivý rámec přijatý jedním rozhraním bridge nebyl přeposlán na ostatní. Toto je možné snadno zařídit následujícím pravidlem:
# ebtables -A FORWARD --logical-in br-lan6 -j DROP
K dokonalosti ještě zbývá vyřešit problém nefunkční detekce duplicitních adres v takto izolované síti. Řešení nabízí RFC 6957, nenašel jsem však žádnou implementaci pro Linux. Problém jsem se proto rozhodl ignorovat. Ostatně, v adresním prostoru s 18 triliony možných adres je při náhodném výběru pravděpodobnost kolize v řádu 10-20, tedy v zásadě zanedbatelná.
Trable s iZařízeními
Takto zprovozněnou síť jsem testoval na všech zařízeních, co mám běžně po ruce – tedy telefonech s Androidem a noteboocích s Linuxem a ChromeOS. Vše se zdálo být plně funkční. Dokonce jsem zkusil vyrobit z jednoho notebooku falešný router a zkusit, zda jeho přítomnost ovlivní ostatní zařízení. Test proběhl hladce.
O to víc mě pak znepokojilo, když si Radek Zajíc pár minut po startu akce začal stěžovat, že mu nefunguje DNS:
Pokud vám nefunguje Wi-Fi síť na #ipv6day, je to výpadkem použitého DNS serveru 2001:718:2:1507::1. Samotná konektivita funguje. @Oskar456
—
Radek Zajic (@zajdee) 6. června 2017
Ve stejném okamžiku byly k routeru připojeny možná i desítky dalších zařízení, které bez problému fungovaly. Po zdlouhavém hledání příčiny jsme přišli na to, že na vině je právě off-link prefix. Jak iPad, tak i MacBook se nebyly schopné spojit s jakoukoli adresou v prefixu, který byl označen jako off-link. A jelikož v tomto prefixu ležel také rekurzivní DNS server, nemohla se s ním zařízení spojit, což vedlo ke kompletní nefunkčnosti připojení.
Problém jsem vyřešil přepnutím prefixu do režimu on-link. Další možnost obejití problému by byla ohlašováním jiné adresy DNS serveru, třeba z jiného rozhraní routeru, nebo Google Public DNS64. Rozhodně jde o zajímavý problém, který vyžaduje další průzkum.
Účty eduroam v záloze
Počítal jsem s tím, že pro některé návštěvníky nebude IPv6-only síť, zajišťovaná jedním přístupovým bodem, dostatečným řešením. Chtěl jsem proto návštěvníkům nabídnout přístup k síti eduroam a to i těm, kteří nepřichází z instituce, která by byla do eduroamu zapojena. V loňském roce jsem tento problém vyřešil vytvořením jednoho dočasného sdíleného účtu.
Od té doby ale došlo ke změně roamingové politiky. Nová verze politiky explicitně zakazuje vytváření sdílených účtů v rámci federace. Bylo tedy potřeba vymyslet jiné řešení. Nakonec jsem navrhl a vyrobil čtyřicet kartiček s unikátními eduroam účty. Každý, kdo přišel k registraci požádat o eduroam účet, obdržel kartičku a její přiřazení konkrétní osobě bylo zaznamenáno. Nakonec o kartičky požádalo pět návštěvníků.
Optimistické statistiky
Router Turris Omnia má vestavěnou funkci sběru dat, která byla v průběhu semináře aktivní. Ze statistik můžeme vyčíst, že účastníci semináře za celý den přenesli bezmála 18 GB, přičemž podíl IPv6 provozu je 55 %. Můžeme tedy směle prohlásit, že přinejmenším pro návštěvníky semináře byl IPv6 majoritním protokolem. A tak to má být!
Ondřej Caletka