O příčinách mohu jen spekulovat, pozorovatelnou skutečností je, že ve druhé polovině listopadu se v DNS objevil záznam typu AAAA s IPv6 adresou pro www.mojedatovaschranka.cz. Dotyčný server ovšem na snahy o navázání TCP spojení po IPv6 reagoval stoickým mlčením. To je krajně nešťastné situace, protože stroje ze sítí podporujících IPv6 obvykle dávají přednost novému protokolu a trvá dost dlouho, než zkusí IPv4. Výsledkem je čekání v délce desítek vteřin, než se kýžená stránka otevře.
Shodou okolností tuto situaci ve svém posledním článku Dual Stack Esotropia velmi podrobně pitval Geoff Huston. Sestavoval různé zpotvořené scénáře s úmyslně nefunkčními údaji v DNS a sledoval, jak se budou chovat různé prohlížeče v různých operačních systémech.
V chování aplikací při tomto druhu chyb se totiž mísí dva vlivy: operační systém a aplikace samotná. Na operačním systému závisí, jak dlouho trvá, než ohlásí neúspěch při pokusu o navázání TCP spojení. Obvykle se totiž nenechá odradit, když na první paket nedostane odpověď (ostatně, od toho TCP máme, aby se dokázalo vypořádat s přenosovými chybami). Zkouší to opakovaně při zvětšujících se časových odstupech a trvá desítky vteřin, než své snažení vzdá a vrátí aplikaci chybový kód. Na aplikaci pak záleží, jaká spojení požaduje a jak reaguje na neúspěch.
Z pozorování Geoffa Hustona vyplývá, že typický současný WWW prohlížeč když dostane IPv4 i IPv6 adresy a běží na stroji připojeném oběma protokoly, nejprve zkusí navázat spojení po IPv6 a teprve po neúspěchu se obrátí na IPv4. V závislosti na operačním systému trvá 20–75 sekund, než otevře příslušnou stránku. Čestnou výjimkou je Chrome, který zkouší oba protokoly prakticky okamžitě, a Firefox, pokud mu zapnete volbu network.http.fast-fallback-to-IPv4.
O problému se ví už poměrně dlouho a pod křídly pracovní skupiny v6ops vzniká doporučení pro autory aplikací. Jmenuje se Happy Eyeballs a ve stručnosti radí otevírat IPv4 i IPv6 spojení paralelně, první úspěšné zachovat a uložit si informaci do dočasné paměti. Při opakované komunikaci se stejným strojem pak rovnou použít úspěšnou variantu z minula, aby se zbytečně nezatěžovala síť.
Jenže tohle jsou vize. Co si ale reálně počít, když se aplikace chová dnes obvyklým způsobem a vznikají neakceptovatelné prodlevy? Možností je několik:
- Kontaktovat správce služby
-
Je dobré si uvědomit, že skutečným zdrojem problémů nebývají žádné protokoly, ale nejčastěji chyba správce inkriminované služby. Ten by měl zajistit, aby byla služba korektně dostupná po IPv6, případně stáhnout příslušný záznam z DNS a neslibovat nesplnitelné. Chyby samozřejmě děláme všichni a dát o ní vědět je dobrým prvním krokem k odstranění. Tohle je ideální varianta, protože problém bude vyřešen přímo u zdroje a prospěch z toho budou mít všichni uživatelé služby. Jako bonus zdarma navíc situaci nebudete řešit vy.
Výsledkem dialogu se správcem může být i zjištění, že skutečným viníkem je nekorektní chování prvku v transportní síti a bude třeba domáhat se nápravy u příslušného operátora. Ale takové případy jsou spíše výjimečné. Pravděpodobnější je (často drobné) opomenutí na serveru či ve firewallech jeho přístupové sítě.
- Filtrovat DNS
-
Jestliže u kolébky potíží stojí nesoulad údajů v DNS se skutečným stavem daného stroje, může pomoci drobná cenzura DNS. Máte-li pod kontrolou DNS server obsluhující postižené klienty, můžete se pokusit jej přimět, aby jim neposkytoval problémové AAAA záznamy. Například v BINDu k tomuto účelu slouží příkaz
deny-answer-addresses, jímž lze filtrovat záznamy na základě adres, jež obsahují. Není to korektní a můžete narazit na DNSSEC, ale v řadě případů to pomůže. - Změnit preference koncového stroje
-
Operační systémy obvykle umožňují řídit priority síťových protokolů, takže můžete na klientském stroji dát IPv4 přednost před IPv6. Ve Windows k tomu slouží registr HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents, konkrétně nastavení jeho bitu 0×20 na jedničku (viz návod), v Linuxu pomůže konfigurační soubor /etc/gai.conf, kde je třeba zvýšit
precedenceprefixu ::ffff:0:0/96 na hodnotu vyšší než 50. Tady už ale s vaničkou vyléváme i dítě, protože priority protokolů lze v systému nastavit jen plošně, takže bude IPv4 preferováno pro veškerou komunikaci. Extrémní alternativou tohoto přístupu je IPv6 zcela vypnout, ale nechtějte po mně, abych tohle někomu doporučoval. - Prozkoumat možnosti postižené aplikace
-
Je možné, že s problémem se půjde vypořádat vhodným zásahem do konfigurace postižené aplikace. Za příklad může posloužit výše zmiňovaný parametr
network.http.fast-fallback-to-IPv4ve Firefoxu nebojava.net.preferIPv4Stackajava.net.preferIPv6Addressespro Javu. To už je ale poměrně horká půda. Pokud se vybraná aplikace chová jinak, bývá to zdrojem zmatení a komplikuje se pozdější hledání chyb – člověk má tendenci zapomínat na nestandardní nastavení a pak nevychází z údivu.
Výše zmíněný příklad datových schránek je pěknou ukázkou, že zpravidla funguje první varianta. Správce na upozornění reagoval obratem, a když jsem prošel standardním testem „nám to tady funguje, chyba bude nejspíš na vaší straně“, problém svižně odstranil. Takže mohu nabídnout happy end a s ním i doporučení: Snažte se neřídit podle zaběhaného modelu „uživatelé trpí mlčky“. Dejte o problémech vědět.
