RTXシリーズのNATテーブル溢れ対策

RTXシリーズで、接続は切れていないのに通信できないというトラブルは、NATテーブルが溢れている可能性が高いです。

1) show nat descriptor addressコマンドでNATテーブルの利用状況を確認する

show nat descriptor addressコマンドで、「xx個使用中」となっている部分が、利用機種の制限値ギリギリになっていないかを確認する。制限値ギリギリで推移している場合は、NATテーブルあふれの可能性が高い。

機種別のNATテーブル制限値はこちら: http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/nat/nat_descriptor_masquerade_port_range.html

> show nat descriptor address
参照NATディスクリプタ : 1000, 適用インタフェース : PP[01](1)
Masqueradeテーブル
    外側アドレス: ipcp/180.xx.xx.xx
    ポート範囲: 60000-64095, 49152-59999, 44096-49151   68個使用中

2) 特定ポートのNATタイムアウトを短くする

NATタイムアウトを短くしても無難そうな、http, httpsだけ、NATタイムアウトを短くする。
参考: http://jehupc.exblog.jp/17328735/

24.9 NAT の IP アドレスマップの消去タイマの設定

nat descriptor timer 1000 protocol=tcp port=80 120
nat descriptor timer 1000 protocol=tcp port=443 120

3) 全体のNATタイムアウトを短くする

デフォルトは900秒(=15分)なので、ちょっと短くする。
24.9 NAT の IP アドレスマップの消去タイマの設定

nat descriptor timer 1000 600

4) ホスト毎のNATセッション数を制限する

特にSkype等で、1台のPCから多数のコネクションを張っている場合に有効。
24.18 IP マスカレードで変換するホスト毎のセッション数の設定

nat descriptor masquerade session limit 1000 512

2014-11-25

AWS S3でcatch-all redirectサイトを作る

キャンペーン終了したりして、ドメイン丸ごと別サイトにリダイレクトしたい場合など。
要は、S3のBucketに何もファイルがないと、常にアクセスが404エラーになるので、404エラーのリダイレクト先として別サイトを指定すると、結果として全てのアクセスがリダイレクトされるということです。

1. リダイレクトしたいドメイン名でBucketを作る（例：example.jp）

Bucketの中には何もファイルを置かなくて良い。

2. 誰でもアクセスできるようにbucket policyを設定する

BucketのPropertiesを開いて、Permissions → Edit bucket policyで設定できる。以下のようなbucket policyで、誰でもs3:GetObjectできるように。
"Resource": "arn:aws:s3:::example.jp/*" の部分は、適宜対象ドメイン名で置換する。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "PublicReadForGetBucketObjects",
			"Effect": "Allow",
			"Principal": "*",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::example.jp/*" ← example.jpは対象ドメイン名で置き換える
		}
	]
}

3. Static Website Hostingを設定する

BucketのPropertiesを開いて、Static Website Hostingを設定する。

Enable website hostingをチェック
Index Documentには"index.html"を記入
Edit Redirection Rulesで、以下のXMLを設定

<RoutingRules>
    <RoutingRule>
        <Condition>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <HostName>www.example.co.jp</HostName> ← リダイレクト先のホスト名
            <ReplaceKeyWith/>
            <HttpRedirectCode>301</HttpRedirectCode>
        </Redirect>
    </RoutingRule>
</RoutingRules>

4. リダイレクトしたいドメインの参照先にS3 Bucketを指定する

Route53ならAliasでTargetにS3 Bucketを指定する。Route53で管理してない場合は、S3エンドポイントのアドレスを書いておくとかでしょうか（後日変わるリスクはありますが）。

2014-11-25

Google Computing 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から来るそうです。というわけで、ここのアドレスブロックからのアクセスをログに残さないようにすればよさそう。

Apache 2.4以降の記述だとこうなる。

# <If "-R '130.211.0.0/22'">は、 <If "%{REMOTE_ADDR} -ipmatch '130.211.0.0/22'"> の省略形です。

# HTTPロードバランサ
<If "-R '130.211.0.0/22'">
        SetEnv nolog
</If>
# ネットワークロードバランサ
<If "-R '169.254.169.254'">
        SetEnv nolog
</If>

CustomLog ${APACHE_LOG_DIR}/access.log combined env=!nolog

2014-10-06

RTX1200でIIJmio FiberAccess/NFのDS-Liteを使う

IIJmio FiberAccess/NFで、DS-Liteを使ったIPv4 over IPv6が使えるようになったとのことなので、RTX1200で接続できるか試してみたところ、ipipトンネルであっさり接続できました。

以下が最低限のconfigです。（MTUが1500で良いかどうかは~~自信がない~~1500でOKでした）

tunnel select 1
 tunnel encapsulation ipip
 tunnel endpoint address <gw.transix.jpのIPv6アドレス>
 ip tunnel mtu 1500
 ip tunnel tcp mss limit auto
 tunnel enable 1

実際に使う上では、最低限のフィルタくらいはかけた方がいいと思います。

ip filter 1 reject * * * * *
ip filter 2 pass * * * *

ip filter dynamic 1 * * ftp
ip filter dynamic 2 * * domain
ip filter dynamic 3 * * tcp
ip filter dynamic 4 * * udp

ipv6 filter 1 reject * * * * *
ipv6 filter 2 reject * * * * *

tunnel select 1
 tunnel encapsulation ipip
 tunnel endpoint address <gw.transix.jpのIPv6アドレス>
 ip tunnel mtu 1500
 ip tunnel secure filter in 1
 ip tunnel secure filter out 2 dynamic 1 2 3 4
 ip tunnel tcp mss limit auto
 ipv6 tunnel secure filter in 1
 ipv6 tunnel secure filter out 2
 tunnel enable 1

お楽しみ、スピードテストの結果はと言えば、それなりに速かったです。

=== Radish Network Speed Testing Ver.3.2.2 - Test Report ===
測定条件
　精度:高 データタイプ:標準
下り回線
　速度:292.5Mbps (36.56MByte/sec) 測定品質:95.1
上り回線
　速度:92.56Mbps (11.57MByte/sec) 測定品質:86.6
測定者ホスト:***.***.*.***.shared.user.transix.jp
測定サーバー:東京-WebARENA
測定時刻:2014/10/7(Tue) 1:27





















































































































-


























































測定サイト http://netspeed.studio-radish.com/
============================================================

2014-07-13

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でうまく接続できないのに気づく。

Microsoftのサイトで使われているCDN、IPv6アドレスを返すのはいいが全く反応しないCDNサーバーばかりでつらい
— Hideo Matsumoto (@pekeq) June 24, 2014

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

MSのCDNサイトにぶつかる度にhostsにIPv4アドレスを追加している。OCNが悪いのかと思ってさくらVPSで試してもダメ
— Hideo Matsumoto (@pekeq) June 24, 2014

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

IPv6 reachableな皆さま、この画像をIPv6で取得できるか教えてください http://t.co/0u6xp2bgsf
— Hideo Matsumoto (@pekeq) June 24, 2014

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

IPv6でアクセスできないCDNのURLは複数存在するが、ホスト名の実体は、みな同じホスト名を指していた。（CNAMEが同じホスト名を指している）
このCDNエンドポイント（= ホスト）には、ping6は通るし、80/tcpに接続もできる。よってルーティングの問題ではなさそうだ。
これはAnycastアドレスのようで、問題のあるISPは大阪回り、問題のないISPは東京回りでCDNエンドポイントにアクセスしている。
Azure CDNも、CNAMEは同じホスト名を指しており、試しにAzure CDNでコンテンツを公開してみると、同じ問題が発生している。
「接続できてもデータが取れない」場合、MTUの問題であるケースが多いが、MTUに十分収まる小さいデータで試すなどした結果、MTUの問題ではなさそうだという結論を得た。

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

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

6/25 - 6/29

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

6/30 - 7/1

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

問い合わせは、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を)有効にする必要があります）

IPv6を有効にしたばあい、サブスクリプション全体に対して有効になるのでしょうか？
- "Yes, once i have enabled IPV6 on your account it will apply to all endpoints on your account."
- （はい、IPv6をアカウントに対して有効にすると、あなたの全エンドポイントに適用されます）

正直、釈然としない返答ではあったが、追加料金があるわけでもなさそうだし、まあいいかということで、この後、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'"
CDNエンドポイントに対してDNSを使わずにIPアドレス直指定でアクセスしても、同様の問題が起きるかどうかを確認したかったようだ。

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

7/6

何の連絡もないので、「進捗どうですか」とメールしてみる。

「内部で動いてるからもうちょっと待ってて」という返事。

7/7

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

EdgeCastからの連絡はまだないが、問題は解消されたように見える。

まあ報告はないが事実として使えているので、ここ数日くらいは、日本のIPv6はオレが直した、くらいのドヤ顔してみたい
— Hideo Matsumoto (@pekeq) July 8, 2014

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でアクセスできてるってのはどうなの？とか、IPv6正式サポートすれば解決では？など、言いたいことは多少ありますが、とりあえず目先の問題は解消されたし、これらはサポート窓口で主張しても解決されないであろう問題なので、この件は、これでおしまいです。

その他、補足など

サポートにIPv6の有効・無効を依頼した前後で、CDNの挙動が変わっているようには見えなかった。問題解決後、IPv6を有効にするよう依頼をしていない、別のAzureサブスクリプションでCDNを新規作成したが、何の設定もしなくても、IPv6を介してコンテンツの取得が可能だった。
おそらく、IPv6の有効･無効というのは、契約上の問題で、実際の動きには影響がないのだと思う。

謝辞

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

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

2014-06-10

続・会社PCリプレース

未だに会社PCの調達で悩んでいる。10万円以上20万円未満の買い物というのは悩みどころであって、選択肢がいろいろあるんですよね…

10万円以下の構成で割り切って消耗品として買う
20万円以下で買って中小企業者等の少額減価償却資産の特例として即時償却する（一気に損金にできるが、この場合、固定資産税（償却資産）がかかる）
20万円以下で買って一括償却資産として３年で償却する（この場合、固定資産税（償却資産）はかからない）

超裏技としては、パーツ単位で買うというのもありますが…

DELLでなかなか良いパッケージが出ないから、サイコムで買ってみようかな…

サイコムのBTOパソコン！まずはお見積もりから

2014-05-23

会社PCリプレース

会社PC、前回の更新から２年半経過し、さすがにSSD化したくなってきた。これまではDELLの法人向けモデル(Vostro)を使ってきたのだが、最近のDELLでメモリ8G搭載しようとすると、上位モデル(OptiPlex)を買わないといけないのか。うーむ。
マウスコンピュータの法人モデルが安くて良さそうなのだが、以前に実家用に買ったのが２年で壊れた思い出があり、どうしたもんか。

【SOHO法人様向け】デル・オンライン広告限定ページ(デスクトップ)