pekeqのブログスマートフォン用の表示で見るpekeqのブログこの広告は、90日以上更新していないブログに表示しています。2014-12-18RTXシリーズのNATテーブル溢れ対策RTXシリーズで、接続は切れていないのに通信できないというトラブルは、NATテーブルが溢れている可能性が高いです。addressコマンドで、「xx個使用中」となっている部分が、利用機種の制限値ギリギリになっていないかを確認する。制限値ギリギリで推移している場合は、NATテーブルあふれの可能性が高い。httpsだけ、NATタイムアウトを短くする。全体のNATタイムアウトを短くするデフォルトは900秒(=15分)なので、ちょっと短くする。ホスト毎のNATセッション数を制限する特にSkype等で、1台のPCから多数のコネクションを張っている場合に有効。redirectサイトを作るキャンペーン終了したりして、ドメイン丸ごと別サイトにリダイレクトしたい場合など。要は、S3のBucketに何もファイルがないと、常にアクセスが404エラーになるので、404エラーのリダイレクト先として別サイトを指定すると、結果として全てのアクセスがリダイレクトされるということです。リダイレクトしたいドメイン名でBucketを作る(例:example.jp)Bucketの中には何もファイルを置かなくて良い。policyで設定できる。policyで、誰でもs3:GetObjectできるように。部分は、適宜対象ドメイン名で置換する。Hostingを設定する。Bucketを指定する。Route53で管理してない場合は、S3エンドポイントのアドレスを書いておくとかでしょうか(後日変わるリスクはありますが)。Engineのロードバランサのアクセスログを取らないAWSのELBみたいに、GCEのLBのサーバー死活監視アクセスをApacheのaccess.logに残したくないときどうするか。HTTPロードバランサの死活監視アクセスはどこから来るかというと、https://cloud.google.com/compute/docs/load-balancing/health-checks#update_firewall_rulesによれば、HTTPロードバランサは130.211.0.0/22から、ネットワークロードバランサは169.254.169.254から来るそうです。いうわけで、ここのアドレスブロックからのアクセスをログに残さないようにすればよさそう。2.4以降の記述だとこうなる。IPv6が使えるようになったとのことなので、RTX1200で接続できるか試してみたところ、ipipトンネルであっさり接続できました。以下が最低限のconfigです。1実際に使う上では、最低限のフィルタくらいはかけた方がいいと思います。1お楽しみ、スピードテストの結果はと言えば、それなりに速かったです。先月末から先週まで、この件でいろいろ対応していたので、経緯をまとめてみました。azure.microsoft.comなど)で利用しているCDNが、一部のIPv6ネットワーク(OCN、さくらインターネットなど)からアクセスできない場合があった。GETを送って返事が返ってこないという奇妙な状態だった。CDNで提供されているCDNと同一のサーバーだった。CDNでコンテンツを公開したところ、やっぱり一部のIPv6ネットワークからアクセスできなかった。CDNの障害として問い合わせてみた。CDNの問題は解消され、それに伴い、同じCDNを使っているサイトにも、IPv6で正常にアクセスできるようになった。釈然としない部分はあるが、とりあえず目先の問題は解消された。時系列で細かく書いてみた先方のサポートからの返答は、ベタで引用するとよろしくなさそうなので、最低限の引用にしています。英文で、翻訳に自信がないところは、長めに引用しています。6/24Officeのダウンロード版を買って、office.microsoft.comからダウンロードしようとして、IPv6でうまく接続できないのに気づく。2014そういえば、以前、azure.microsoft.comでも、使っているCDNにIPv6でアクセスできなかったことがあり、hostsファイルにCDNのIPv4アドレスを手で書いていたのだった。IPv6で接続できない度にhostsを編集するのは面倒だ。MSのCDNサイトにぶつかる度にhostsにIPv4アドレスを追加している。2014でも、IPv6ネットワーク全体からMSのサイトにアクセスできないようであれば、もっと大騒ぎになってもおかしくないのだが、ひょっとしてアクセスできないのはうちの環境だけなんだろうか?と思ってtwitterで聞いてみると、果たしてIPv6で正常にアクセスできるネットワークの方が多かった。2014さらに調べると、以下のような状況がわかってきた。IPv6でアクセスできないCDNのURLは複数存在するが、ホスト名の実体は、みな同じホスト名を指していた。ホスト)には、ping6は通るし、80/tcpに接続もできる。よってルーティングの問題ではなさそうだ。これはAnycastアドレスのようで、問題のあるISPは大阪回り、問題のないISPは東京回りでCDNエンドポイントにアクセスしている。CDNでコンテンツを公開してみると、同じ問題が発生している。「接続できてもデータが取れない」場合、MTUの問題であるケースが多いが、MTUに十分収まる小さいデータで試すなどした結果、MTUの問題ではなさそうだという結論を得た。これらの状況から、IPv6のルーティングというよりは、CDNエンドポイント側の障害じゃないかという気がしてきた。これまで、このIPv6でアクセスできないという問題に対しては、こういう問題を問い合わせる窓口がMicrosoftにはないし、あったとしてもフォーラム等で反応が期待できないので、改善されるのをあきらめていた。CDNでも同じ問題が起きているということは、Azureの問題として問い合わせれば、結果として全体のアクセスが改善されるのでは?と思ったのだった。BizSparkの無料サポートインシデントの有効期限が近づいていたので、失効させるよりはと思い、この件を問い合わせることにした。6/29マイクロソフトに問い合わせてから、契約状況の確認などあり、数日要した。CDNサポートは英語対応になるので、質問は英語で送れとのことで、@hideyu_k氏の協力のもと、問い合わせ文章を作る。7/1以下の内容で、マイクロソフトに問い合わせを送った。Networksにエスカレーションされ、以後は、主にEdgeCastの担当と直接やりとりすることになった。EdgeCastからの返答は早く、以下のような返答があった。Azureサブスクリプション)では、IPv6が有効になっていない。以下の免責事項を確認して、IPv6を有効にしてよいか連絡してくれ。functioning."(EdgeCastは全ネットワークでIPv6を有効にしているが、IPv6で配信する上で通信ルーティングの問題を見いだしていることに注意してほしい。いくつかの奇妙な場合では、ネットワークが適切に設定されていないので、IPv6対応のエンドユーザの0.45%以下において、接続が失敗する場合がある。我々はISPとともに、ネットワークが正常に動作するよう作業を進めている)上記の返答を得て、少々というか、かなり面食らった。CDNでは、IPv6がデフォルト無効である、というのは知らなかった。IPv6有効/無効の設定があるのなら、何故CDNのエンドポイントがデフォルトでIPv6有効になっているのだ!?それに、問題のないIPv6ネットワークからCDNにアクセスすると、IPv6でも問題なくコンテンツが取れるのだが...とはいえ、IPv6を有効にすると言わないと、先に進めなさそうではある。有効にすると言う前に、以下の確認をしてみた。有効化に費用は発生いたしません。behavior."(CNAMEの指しているVIPはデュアルスタックなので、IPv4とIPv6アドレスの両方が出てきます。account."(はい、IPv6をアカウントに対して有効にすると、あなたの全エンドポイントに適用されます)正直、釈然としない返答ではあったが、追加料金があるわけでもなさそうだし、まあいいかということで、この後、IPv6を有効にしてくれというメールを送った。なくして、「IPv6を有効にした。設定が浸透するまで6時間ほどかかるから待ってくれ」という返事がある。IPv6が有効になったと言われてから6時間経過した後、状況を確認するが、やっぱり症状は直っておらず、「やっぱりダメなんですけど」というメールを送る。【追記】ちなみに、IPv6を有効にした前後で、挙動が変わったような様子は見られなかった。7/2EdgeCastから連絡あり。「問題のあるホスト上でMTRを実行した結果を送ってくれないか。routeを確認したい」mtrコマンドの出力を送付後、さらにwgetを送るように依頼される。azxxxxxx.vo.msecnd.net'"CDNエンドポイントに対してDNSを使わずにIPアドレス直指定でアクセスしても、同様の問題が起きるかどうかを確認したかったようだ。teamにエスカレーションするという連絡あり。7/6何の連絡もないので、「進捗どうですか」とメールしてみる。「内部で動いてるからもうちょっと待ってて」という返事。7/7朝、問題のあるIPv6ネットワークのホストからwgetしてみると、コンテンツが取れるようになっていた。CDNだけでなく、office.microsoft.comやazure.microsoft.comも、IPv6で正常にコンテンツが取得できる。EdgeCastからの連絡はまだないが、問題は解消されたように見える。20147/9EdgeCastから、直ったというメール。cs1.wpc.v0cdn.netのIPv6接続は正常に動くようになった。内部のテストでは問題ない。あなたの方でも確認してほしい)こちらから観測する限りは、7/7から動作は正常に戻っていたが、内部のテストに数日を要したというところだろうか。「こちらでもアクセスできている。ところで原因について可能な範囲で教えてくれないか」と返事をしたところ、ちょっとだけ状況を教えてくれた。internally.(ACLに以前より問題があった。今回の件をDNSとネットワークのチームにエスカレーションした結果、この問題を解決できた。ネットワークのチームが、あなたのリクエストを処理するにはACLに特殊な設定が必要なのに気づいた。ACLを修正後は、DNSチームがAzureのCNAMEを正常にテストできた。)というわけで、設定の問題があったのを直したというのが結論のようでした。情報の共有ありがとうございます。フィルタを開け忘れてたってところでしょうか。20147/10というわけで、当初の目的は達成されたのだが、これは結局、Azureの障害という扱いになるのだろうか。マイクロソフトに「今回の件は、『マイクロソフト製品の不具合に起因するもの』になるのでしょうか?」というのを聞いてみた。対応を行っておりません。有効化する仕組みとなっているため、今回の件は不具合には該当いたしません。ご理解いただけますと幸いです。CDNとしてはIPv6正式対応しているわけではないので、障害じゃないです、ということでした。IPv6対応していないと言いつつ、CDNエンドポイントにIPv6がついてるとかありえなくない?とか、契約上有効かどうかに関わらず実際はIPv6でアクセスできてるってのはどうなの?とか、IPv6正式サポートすれば解決では?など、言いたいことは多少ありますが、とりあえず目先の問題は解消されたし、これらはサポート窓口で主張しても解決されないであろう問題なので、この件は、これでおしまいです。その他、補足などサポートにIPv6の有効・無効を依頼した前後で、CDNの挙動が変わっているようには見えなかった。問題解決後、IPv6を有効にするよう依頼をしていない、別のAzureサブスクリプションでCDNを新規作成したが、何の設定もしなくても、IPv6を介してコンテンツの取得が可能だった。IPv6の有効・無効というのは、契約上の問題で、実際の動きには影響がないのだと思う。皆様ありがとうございました。00:00MicrosoftのサイトにIPv6でアクセスできない場合があった件Tweet広告を非表示にする2014-06-10続・会社PCリプレース未だに会社PCの調達で悩んでいる。00:00続・会社PCリプレースTweet広告を非表示にする2014-05-23会社PCリプレース会社PC、前回の更新から2年半経過し、さすがにSSD化したくなってきた。これまではDELLの法人向けモデル(Vostro)を使ってきたのだが、最近のDELLでメモリ8G搭載しようとすると、上位モデル(OptiPlex)を買わないといけないのか。マウスコンピュータの法人モデルが安くて良さそうなのだが、以前に実家用に買ったのが2年で壊れた思い出があり、どうしたもんか。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。