A je to tady, i velcí poskytovatelé obsahu přestali IPv6 ignorovat a svět pomalu začíná přecházet na Nový Internet. Na afterpárty letošního Installfestu jsme s Petrem Krčmářem přemýšleli, že bychom mohli „udělat něco s IPv6“ u příležitosti jeho světového jeho spuštění. Tak vznikl nápad na server http://www.nebezi.cz, který běží jen na protokolu IPv6.
Když jsme informaci o stránce ve středu zveřejnili, jak prostřednictvím zdejšího článku, tak i pomocí odznáčků rozdávaných na konferenci IPv6 Day, objevily se první pokusy o kontaktování autorů prostřednictvím e-mailové adresy, uvedené v patičce stránky. Tím se ukázalo, že spousta uživatelů, kteří mají IPv6 konektivitu, není schopna odesílat poštu na server, který nepodporuje protokol IPv4. Zřídil jsem proto novou službu, automatický odpovídač. Pošlete-li jakýkoli mail na adresu test@nebezi.cz, měla by se vám vrátit buď zpráva o nedoručitelnosti, nebo zpráva o úspěšném doručení.
Zároveň jsem také otestoval několik freemailů (jmenovitě Seznam, Centrum a Gmail) a počítal, kolikrát se mi zprávu podaří doručit. Ani jednou!
Nejzajímavější chování přitom pozoruji u Gmailu. Nejdříve jsem měl DNS nastaveno tak, že doména nebezi.cz neměla žádný MX záznam a očekával jsem, že k doručení bude použit přímo AAAA záznam. V takovém případě se e-mail vracel jako nedoručitelný s tím, že pro doménu neexistují MX záznamy. Během dopoledne jsem byl upozorněn, že možná mám něco špatně, protože RFC 2821 hovoří o tom, že cílová doména v SMTP komunikaci může mít MX záznam, nebo A záznam, nic jiného povoleno není. A to i přesto, že daný dokument je z roku 2001 a problematikou IPv6 se na jiných místech zabývá. Tento dokument však byl překonán Draft Standardem RFC 5321 z roku 2008, kterýžto už možnost použití AAAA záznamů explicitně připouští. Řekl jsem si tedy, že přidání MX záznamu ničemu neuškodí a přidal záznam mířící sám na sebe. Od té doby Gmail nejen že nedoručuje, ale ani neposílá nedoručenky, zprávy jednoduše končí v černé díře!
Problém se mi podařilo nahlásit na podporu Gmailu, snad se tím aspoň podaří obnovit posílání nedoručenek. Do té doby můžete testovat připravenost svého e-mailového poskytovatele na IPv6. A když přitom navštívíte Neběží.cz, bude naše radost o to větší, třeba se dostaneme i do první desítky na oficiálním seznamu IPv6 webů. V době psaní tohoto postu nám k desátému místu stačí sto návštěv.
Update 9.6.2012: Tak přesně po 24 hodinách Google vrátil zprávu o „dočasných problémech s doručováním.“ Gmail zřejmě nedokáže uvěřit, že doménové jméno, na které míří MX záznam, nevrátilo při dotazu na A záznam žádná data:
This is an automatically generated Delivery Status Notification THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: test@nebezi.cz Message will be retried for 2 more day(s) Technical details of temporary failure: DNS Error: DNS server returned answer with no data
Jak je možné, že mi nefunguje přístup na nebezi.cz? IPv6 mám tunelem z 192.88.99.1. Je patrné, že adresu DNS má. Ale pokud si pinknu na adresu nebezi.cz tak to nefunguje? Získám tedy tuto IP adresu 2a01:430:d:0:2cc:9eff:fe24:7e1a, pokud ji přímo zadám do prohlížeče, stránka se stejně nenačte. Kde může být problém?
ping6 nebezi.cz
PING nebezi.cz (2a01:430:d:0:2cc:9eff:fe24:7e1a): 56 data bytes
[5.] Vypadá to, že buď nemáš správně nastavené 6to4, nebo jsi zapomněl odfirewallovat IPv4 protokol 41. Vtip je v tom, že server, na kterém nebezi.cz běží, má vestavěnou 6to4 bránu, takže odpovědi na pakety, které přišly z anycastové brány, posílá zpět z nativní IPv4 adresy serveru přímou cestou.
Takže ty odesíláš paket s adresami v6 from 2002:neco to 2a01:430:d:0:2cc:9eff:fe24:7e1a zapouzdřené v IPv4 paketu from tv.oje.ip.adresa to 192.88.99.1, ale odpovědi se ti vrací se stejnými v6 adresami, ale zapouzdřená v paketu from 80.79.23.84 to tv.oje.ip.adresa.
Pokud není problém ve v4 firewallu, taky jsem zažil problém v nastavení tunelu. Teď jsem si pro účely testování 6to4 rozjel pomocí následujících příkazů:
# ip tunnel add tun6to4 mode sit remote any ttl 64
# ip -6 addr add dev tun6to4 `printf 2002:%2x%02x:%2x%02x::1/16 ip ad re sa`
# ip -6 rou add default via ::192.88.99.1
Důležitá je zejména délka prefixu 16 bitů, jinak nefunguje správně směrování na jiné 6to4 adresy. To si můžeš ověřit třeba pingem na 6to4.oskarcz.net.
Děkuji za rady, pomohl skriptík z http://petrkrcmar.blog.root.cz/2010/12/28/nastaveni-nove-nainstalovaneho-openwrt/. Server neběží už běží. (:-)
Zaujímavé, cez 6to4 sa k nemu nedostanem, ale cez miredo áno.
Asi zase vypadol 192.88.99.1, resp. momentálne traceroute ukazuje, že ide niekam do Ruska a tam sa stráca... Ale minulý týždeň mi konečne po 2 rokoch (!) od schválenia LIRom pridelili natívny IPv6 rozsah, tak to už bude lepšie...
Neco takoveho tu uz bylo.... myslim, ze nekdo nabizel porno ke stazeni pouzena IPv6.
BTW: a predsi bezi i z v4: http://webcache.googleusercontent.com/search?q=cache:http://www.nebezi.cz/
[18] Viz [6]. Zkontroluj konfiguraci 6to4 směrování a IPv4 firewallu. Server Nebezi.cz sice běží na nativní v6 adrese, ale dotazy z 6to4 dokáže vyřizovat zkratkou.
[19] Ani není potřeba použít Google, ten server na IPv4 ve skutečnosti opravdu běží, jinak by nebylo možné detekovat v4 konektivitu a preference dualstacku. Ale o to tady nejde.
Projekt IPv6 porna se odmlčel ještě před svým začátkem, nakonec to skončilo nejspíš na autorských právech k doprovodné hudbě. Vlastní obsah měli licencovaný od producentů zdarma, producenti však, jak se ukázalo později, neměli oprávnění sublicencovat hudbu, která na pozadí hrála.
Nicméně projekt měl startovat 5. ledna 2009, namísto toho se 21. února zcela odmlčel i mailing list projektu. Zbývá tak pouze stránka ipv6porn.co.nz :)
Mno všiml jsem si trapné chyby, která mi znemožňuje doručit obsah testovacího emailu po IPV6 a paradoxně to není u mě :)))))
Po IPV4 trapně OK, ale IPV6 :))))
Apr 1 20:09:14 newrel postfix/smtpd[9320]: NOQUEUE: reject: RCPT from unknown[2001:1528:132:70::ebe2]: 450 4.7.1 Client host rejected: cannot find your hostname, [2001:1528:132:70::ebe2]; from= to= proto=ESMTP helo=
Opravte si to kluci ušatý......
Díky za připomínku, ale nejspíš se jednalo o nějakou transientní událost v DNS. Ve 20:25:31 už k doručení úspěšně došlo:
Apr 1 20:25:31 flexi postfix/smtp[5783]: 76B033F5: to=, relay=mail.stcomp.cz[2001:af0:ffe4:1::3]:25, delay=977, delays=975/0.02/0.65/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3E611200B7)
Reverzní záznam klienta www.nebezi.cz zřízen byl a dokonce jsem si dal záležet aby odpovídal i tomu, jak se klient představí příkazem EHLO.
Co o sobě napsat? Absolvent ČVUT FEL, linuxák, síťař. Mimo to se zajímám o elektrotechniku, elektroniku a speciálně elektrické pohony.
Přečteno 57 276×
Přečteno 15 946×
Přečteno 15 859×
Přečteno 15 160×
Přečteno 13 129×