近況 Twitter

2014年12月18日(木)

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

56.15 動的 NAT ディスクリプタのアドレスマップの表示

> 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日(火)

Google Computing Engineロードバランサのアクセスログを取らない

AWSのELBみたいに、GCEのLBのサーバー死活監視アクセスApacheaccess.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

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年10月06日(月)

RTX1200でIIJmio FiberAccess/NFDS-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アクセスできない場合があった件

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


まとめ



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

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

6/24
Officeダウンロード版を買って、office.microsoft.comからダウンロードしようとして、IPv6でうまく接続できないのに気づく。
そういえば、以前、azure.microsoft.comでも、使っているCDNにIPv6アクセスできなかったことがあり、hostsファイルにCDNのIPv4アドレスを手で書いていたのだった。 しかし、IPv6で接続できない度にhostsを編集するのは面倒だ。
でも、IPv6ネットワーク全体からMSサイトアクセスできないようであれば、もっと大騒ぎになってもおかしくないのだが、ひょっとしてアクセスできないのはうちの環境だけなんだろうか?と思ってtwitterで聞いてみると果たしてIPv6で正常にアクセスできるネットワークの方が多かった。
さらに調べると、以下のような状況がわかってきた。
これらの状況から、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からの返答は早く、以下のような返答があった。
  • 以下の免責事項を確認して、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とともに、ネットワークが正常に動作するよう作業を進めている)

上記の返答を得て、少々というか、かなり面食らった。
とはいえ、IPv6有効にすると言わないと、先に進めなさそうではある。でも、有効にすると言う前に、以下の確認をしてみた。
  • IPv6有効にしてくれと言った場合の料金はどうなるのでしょうか?

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

IPv6有効になったと言われてから6時間経過した後、状況を確認するが、やっぱり症状は直っておらず、「やっぱりダメなんですけど」というメールを送る。
【追記】 ちなみに、IPv6有効にした前後で、挙動が変わったような様子は見られなかった。

7/2
EdgeCastから連絡あり。
  • 「現象を確認中だ」
  • 問題のあるホスト上でMTRを実行した結果を送ってくれないか。network routeを確認したい」
mtrコマンドの出力を送付後、さらにwgetを送るように依頼される。
その後、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.netIPv6接続は正常に動くようになった。内部のテストでは問題ない。あなたの方でも確認してほしい)


こちらから観測する限りは、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を正常にテストできた。)

というわけで、設定の問題があったのを直したというのが結論のようでした。
7/10
というわけで、当初の目的は達成されたのだが、これは結局、Azureの障害という扱いになるのだろうか。
マイクロソフトに「今回の件は、『マイクロソフト製品の不具合に起因するもの』になるのでしょうか?」というのを聞いてみた。
ご質問くださいました点についてですが、
Azure CDN は基本的には IPv6 への対応を行っておりません。
免責事項に承諾いただいたご利用者様に IPv6有効化する
仕組みとなっているため、今回の件は不具合には該当いたしません。
何卒ご理解いただけますと幸いです。
というわけで、Azure CDNとしてはIPv6正式対応しているわけではないので、障害じゃないです、ということでした。

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


その他、補足など

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

おそらく、IPv6有効無効というのは、契約上の問題で、実際の動きには影響がないのだと思う。


謝辞

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

2014年06月10日(火)

続・会社PCリプレース

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

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

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

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


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