近況

■MicrosoftのサイトにIPv6でアクセスできない場合があった件

先月末から先週まで、この件でいろいろ対応していたので、経緯をまとめてみました。

まとめ

• Microsoftの一部のサイト（office.microsoft.com, azure.microsoft.comなど）で利用しているCDNが、一部のIPv6ネットワーク（OCN、さくらインターネットなど）からアクセスできない場合があった。
• アクセスできないと言っても、ping6は通るし、80/tcpには接続できていて、HTTP GETを送って返事が返ってこないという奇妙な状態だった。
• IPv6でアクセスできないCDNは、Azure CDNで提供されているCDNと同一のサーバーだった。
• Azure CDNでコンテンツを公開したところ、やっぱり一部のIPv6ネットワークからアクセスできなかった。
• たまたま、手元に未使用のサポートインシデントがあったので、Azure CDNの障害として問い合わせてみた。
• いろいろやりとりした。
• 結果、Azure CDNの問題は解消され、それに伴い、同じCDNを使っているサイトにも、IPv6で正常にアクセスできるようになった。

時系列で細かく書いてみた

先方のサポートからの返答は、ベタで引用するとよろしくなさそうなので、最低限の引用にしています。
英文で、翻訳に自信がないところは、長めに引用しています。

6/24

Officeのダウンロード版を買って、office.microsoft.comからダウンロードしようとして、IPv6でうまく接続できないのに気づく。

そういえば、以前、azure.microsoft.comでも、使っているCDNにIPv6でアクセスできなかったことがあり、hostsファイルにCDNのIPv4アドレスを手で書いていたのだった。 しかし、IPv6で接続できない度にhostsを編集するのは面倒だ。

そういえば、IPv6ネットワーク全体からMSのサイトにアクセスできないようであれば、もっと大騒ぎになってもおかしくないのだが、ひょっとしてアクセスできないのはうちの環境だけなんだろうか？と思ってtwitterで聞いてみると、果たしてIPv6で正常にアクセスできるネットワークの方が多かった。

さらに調べると、以下のような状況がわかってきた。

• IPv6でアクセスできないCDNのURLは複数存在するが、ホスト名の実体は、みな同じホスト名を指していた。（CNAMEが同じホスト名を指している）
• このCDNエンドポイント（= ホスト）には、ping6は通るし、80/tcpに接続もできる。よってルーティングの問題ではなさそうだ。
• これはAnycastアドレスのようで、問題のあるISPは大阪回り、問題のないISPは東京回りでCDNエンドポイントにアクセスしている。
• Azure CDNも、CNAMEは同じホスト名を指しており、同じ問題が発生している。

これらの状況から、IPv6のルーティングというよりは、CDNエンドポイント側の障害じゃないかという気がしてきた。

これまで、このIPv6でアクセスできないという問題に対しては、こういう問題を問い合わせる窓口がないし、あったとしてもフォーラム等で反応が期待できないので、改善されるのをあきらめていた。 ところが、同じCDNを利用しているように見える、Azure CDNでも同じ問題が起きているということは、Azureの問題として問い合わせれば、結果として全体のアクセスが改善されるのでは？と思ったのだった。 たまたま、Microsoft BizSparkの無料サポートインシデントの有効期限が近づいていたので、失効させるよりはと思い、この件を問い合わせることにした。

6/25 - 6/29

マイクロソフトに問い合わせてから、契約状況の確認などあり、数日要した。 Azure CDNサポートは英語対応になるので、質問は英語で送れとのことで、@hideyu_k氏の協力のもと、問い合わせ文章を作る。

6/30 - 7/1

以下の内容で、マイクロソフトに問い合わせを送った。

• Azure CDNのエンドポイントにIPv6でアクセスできない場合がある件（日本語）
• IPv6 End points of Azure CDN don't respond to HTTP requests from particular network.（英語）

問い合わせは、Azure CDNを実際に運用しているEdgeCast Networksにエスカレーションされ、以後は、主にEdgeCastの担当と直接やりとりすることになった。

EdgeCastからの返答は早く、以下のような返答があった。

• このアカウント（= Azureサブスクリプション）では、IPv6が有効になっていない。
• 以下の免責事項を確認して、IPv6を有効にしてよいか連絡してくれ。
• "Please note that EdgeCast has IPv6 turned on its entire network but we have been seeing traffic routing problems across the globe in delivering IPv6. In some odd cases, this can cause up to a 0.45% failure of IPv6 enabled end users to connect because networks are improperly configured. We are continuing to work with service providers around the Internet to get their networks properly functioning."
• （EdgeCastは全ネットワークでIPv6を有効にしているが、IPv6で配信する上で通信ルーティングの問題を見いだしていることに注意してほしい。いくつかの奇妙な場合では、ネットワークが適切に設定されていないので、IPv6対応のエンドユーザの0.45%以下において、接続が失敗する場合がある。我々はISPとともに、ネットワークが正常に動作するよう作業を進めている）

上記の返答を得て、少々というか、かなり面食らった。

• Azure CDNでは、IPv6がデフォルト無効である、というのは知らなかった。というかポカーンだ。
• だって、IPv6有効/無効の設定があるのなら、何故CDNのエンドポイントがデフォルトでIPv6有効になっているのだ!?
• それに、問題のないIPv6ネットワークからCDNにアクセスすると、IPv6でも問題なくコンテンツが取れるのだが…

とはいえ、IPv6を有効にすると言わないと、先に進めなさそうではある。でも、有効にすると言う前に、以下の確認をしてみた。

• IPv6を有効にしてくれと言った場合の料金はどうなるのでしょうか？
  • 「IP v6 の有効化に費用は発生いたしません。」
• そもそもCDNエンドポイントのアドレスを見ると、IPv4/IPv6両方ありますよね
  • "The VIP that the CNAME is pointed to is dual stacked and will show a ipv4 and ipv6 IP addresses as IPV6 . However, this will still need to be enabled on your account to function as needed without any sketchy behavior."
  • （CNAMEの指しているVIPはデュアルスタックなので、IPv4とIPv6アドレスの両方が出てきます。しかしながら、正常に動作させるためには、このアカウントで有効にする必要があります）
• IPv6を有効にしたばあい、サブスクリプション全体に対して有効になるのでしょうか？
  • "To answer your question. Yes, once i have enabled IPV6 on your account it will apply to all endpoints on your account."
  • （はい、IPv6をアカウントに対して有効にすると、あなたの全エンドポイントに適用されます）

正直、釈然としない返答ではあったが、追加料金があるわけでもなさそうだし、まあいいかということで、この後、IPv6を有効にしてくれというメールを送った。
程なくして、「IPv6を有効にした。設定が浸透するまで６時間ほどかかるから待ってくれ」という返事がある。

IPv6が有効になったと言われてから６時間経過した後、状況を確認するが、やっぱり症状は直っておらず、「やっぱりダメなんですけど」というメールを送る。

7/2

EdgeCastから連絡あり。

• 「現象を確認中だ」
• 「問題のあるホスト上でMTRを実行した結果を送ってくれないか。network routeを確認したい」

mtrコマンドの出力を送付後、さらにwgetを送るように依頼される。

• "wget -SO /dev/null -6 http://[CDNエンドポイントのv6アドレス]/test.html --header 'Host: azxxxxxx.vo.msecnd.net'"

その後、DNS teamにエスカレーションするという連絡あり。

7/6

何の連絡もないので、「進捗どうですか」とメールしてみる。
「内部で動いてるからもうちょっと待ってて」という返事。

7/7

朝、問題のあるIPv6ネットワークのホストからwgetしてみると、コンテンツが取れるようになっていた。 Azure CDNだけでなく、office.microsoft.comやazure.microsoft.comも、IPv6で正常にコンテンツが取得できる。
EdgeCastからの連絡はまだないが、問題は解消されたように見える。

7/9

EdgeCastから、直ったというメール。

• According to our DNS team, connecting to the IPV6 IP address for VIP cs1.wpc.v0cdn.net, is functioning properly. Internal testing is all working, please assist us by verifying on your end.
• （DNSチームによれば、VIP cs1.wpc.v0cdn.netのIPv6接続は正常に動くようになった。内部のテストでは問題ない。あなたの方でも確認してほしい）

こちらから観測する限りは、7/7から動作は正常に戻っていたが、内部のテストに数日を要したというところだろうか。
「こちらでもアクセスできている。ところで原因について可能な範囲で教えてくれないか」と返事をした。

• There were some ACL issues that we were previously having issues with. After we escalated this case to our DNS and Network engineering team we were able to solve this issue. Our Network team found out that there were some ACL's that needed special configurations to accomplish your request. After the ACL's on our network were modified, our DNS team were able to successfully test the azure CNAME internally.
• （ACLに以前より問題があった。今回の件をDNSとネットワークのチームにエスカレーションした結果、この問題を解決できた。ネットワークのチームが、あなたのリクエストを処理するにはACLに特殊な設定が必要なのに気づいた。ACLを修正後は、DNSチームがAzureのCNAMEを正常にテストできた。）

というわけで、設定の問題があったのを直したというのが結論のようでした。

@pekeq 情報の共有ありがとうございます。想像するに、オープンプロキシにならないように、多重で安全策が打ってあって、大阪配信サーバ -> オリジンサーバ のフィルタを開け忘れてたってところでしょうか。

— KUNITAKE Koichi (@kunitake) July 10, 2014

7/10

というわけで、当初の目的は達成されたのだが、これは結局、Azureの障害という扱いになるのだろうか。
マイクロソフトに「今回の件は、『マイクロソフト製品の不具合に起因するもの』になるのでしょうか？」というのを聞いてみた。

ご質問くださいました点についてですが、
Azure CDN は基本的には IPv6 への対応を行っておりません。
免責事項に承諾いただいたご利用者様に IPv6 を有効化する
仕組みとなっているため、今回の件は不具合には該当いたしません。
何卒ご理解いただけますと幸いです。

というわけで、Azure CDNとしてはIPv6正式対応しているわけではないので、障害じゃないです、ということでした。

IPv6対応していないと言いつつ、CDNエンドポイントにIPv6がついてるとかありえなくない？とか、有効かどうかに関わらずIPv6でアクセスできてるってのはどうなの？とか、言いたいことは多少ありますが、とりあえず目先の問題は解消されたし、これらはサポート窓口で主張しても解決されないであろう問題なので、この件は、これでおしまいです。

謝辞

• 翻訳を手伝ってくれた@hideyu_k氏
• 無償インシデントを提供してくれたMicrosoft BizSparkプログラム
• JANOGで話題にしていただいた@kunitake氏
• その他twitter等で情報提供していただいた皆様

皆様ありがとうございました。

ツイートする