尾瀬岩鞍スキー場は冬の顔。夏などは、どうなっている勝手言うと、ゆり園になっているらしく、
尾瀬岩鞍ゆり園マップというのがあった。よーく見ていると、
岩藏リゾートホテル、
レストラン オクタがあり、これ、どうみても、
尾瀬岩鞍スキー場のゲレンデだよなぁと思ってしまった。
比較してみるとこういう感じ。
ゲレンデマップでいうコースの3番と4番あたり。あそこがゆり園になるのねと。てことは、冬場は百合園の場所を踏みつけているのね。ということで、少し複雑な気分でした(^^;
尾瀬岩鞍スキー場は冬の顔。夏などは、どうなっている勝手言うと、ゆり園になっているらしく、
尾瀬岩鞍ゆり園マップというのがあった。よーく見ていると、
岩藏リゾートホテル、
レストラン オクタがあり、これ、どうみても、
尾瀬岩鞍スキー場のゲレンデだよなぁと思ってしまった。
比較してみるとこういう感じ。
ゲレンデマップでいうコースの3番と4番あたり。あそこがゆり園になるのねと。てことは、冬場は百合園の場所を踏みつけているのね。ということで、少し複雑な気分でした(^^;
先日から 2ch.net がみれないなぁとおもっていて、調査をしてみたところ、206.223.154.230 [www.2ch.net] に繋がらないだけではなく、名前解決も出来ていなかった。他の環境では、名前解決も出来るし、アクセスも出来る。ちなみに私の生活環境は、さくらのVPSの上と自宅のVMware上のWindows環境だ。基本的には、ssh -D が大好きな環境ということを前提だ。んで、引ける別環境から調べてみると、2ch.net の 権威NSサーバは次の通り。
;; QUESTION SECTION: ;2ch.net. IN NS ;; ANSWER SECTION: 2ch.net. 163 IN NS ns2.nttec.com. 2ch.net. 163 IN NS ns1.nttec.com. ;; ADDITIONAL SECTION: ns1.nttec.com. 98648 IN A 206.223.144.254 ns2.nttec.com. 21 IN A 206.223.146.254
上記二つに対して、そもそも到達性がない。純粋に、さくらのVPSで使っている 210.224.163.4 及び 210.224.163.3 から到達性が無く、名前解決が出来ていないかだけなのかなとおもったら、手元のVPSからも到達性がなかった。ちなみにいくつかさくらのVPSを保有しているが、次のネットワークから到達性がなかった。
この4つのブロック以外の次のものについては未確認(環境がないので)。
そのほかの環境で正常に到達性が有る場合は、次のようになる。
$ traceroute ns1.nttec.com ----- 13 * ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 136.972 ms 147.673 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 136.475 ms 126.539 ms 140.623 ms 15 nttec-demarc.cr02.centaurico.com (208.74.65.6) 137.670 ms 137.892 ms 141.295 ms 16 ns1.nttec.com (206.223.144.254) 138.313 ms 127.277 ms 120.655 ms
$ traceroute ns2.nttec.com ----- 13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 162.633 ms 135.416 ms 134.846 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 131.001 ms 123.646 ms 130.766 ms 15 nttec-demarc.cr02.centaurico.com (208.74.65.10) 137.945 ms 140.936 ms 130.759 ms 16 206.223.146.254 (206.223.146.254) 129.526 ms 134.333 ms 137.221 ms
$ traceroute www.2ch.net ----- 13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 152.578 ms * 139.815 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 129.471 ms 126.804 ms 134.731 ms 15 nttec-demarc.cr02.centaurico.com (208.74.65.10) 142.490 ms 134.795 ms 130.499 ms 16 206.223.154.230 (206.223.154.230) 136.718 ms 132.965 ms 133.436 ms
さくらのネットワークから試すと次のようになる。
$ traceroute 206.223.144.254 ----- 13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 116.715 ms 115.961 ms 116.165 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 125.603 ms 125.567 ms 125.525 ms 15 * * *
$ traceroute 206.223.146.254 ----- 13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 112.592 ms 112.575 ms 110.053 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 119.783 ms 125.586 ms 126.700 ms 15 * * *
$ traceroute 206.223.154.230 ----- 13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 115.959 ms 117.026 ms 112.617 ms 14 cent-dmarc.gt-t.net (98.124.130.206) 122.428 ms 119.754 ms 119.862 ms 15 * * *
さらに気になったので調べてみたところ、N.T. Technology (AS32335) の他のネットワークに繋がるかチェックしてみたところ、次のような結果が得られた。
まずは、AS32335 から広告されている経路(prefix)一覧は次の通り。
今回は、
さくらのLooking Glassが使用せず、それ以外の一つである
Public Route Servers @WideProjectを使用する。
route-views.wide.routeviews.org> show ip bgp regexp _32335$ BGP table version is 0, local router ID is 202.249.2.166 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 67.219.0.0/20 202.249.2.169 0 2497 4436 19214 32335 i * 202.249.2.86 0 7500 2497 4436 19214 32335 i *> 204.63.0.0/20 202.249.2.169 0 2497 4436 19214 32335 i * 202.249.2.86 0 7500 2497 4436 19214 32335 i *> 206.223.144.0/20 202.249.2.169 0 2497 4436 19214 32335 i * 202.249.2.86 0 7500 2497 4436 19214 32335 i *> 207.29.224.0/20 202.249.2.169 0 2497 4436 19214 32335 i * 202.249.2.86 0 7500 2497 4436 19214 32335 i *> 207.29.240.0/20 202.249.2.169 0 2497 4436 19214 32335 i * 202.249.2.86 0 7500 2497 4436 19214 32335 i
上記のPrefix が広報されていると言うことなので、さくらのネットワークから、下記のネットワークに到達性があるか確認してみる。先ずは正常に応答する、さくらのネットワーク以外の結果のケース。
$ ping -c 2 67.219.0.1 PING 67.219.0.1 (67.219.0.1) 56(84) bytes of data. 64 bytes from 67.219.0.1: icmp_req=1 ttl=238 time=130 ms 64 bytes from 67.219.0.1: icmp_req=2 ttl=239 time=130 ms
$ ping -c 2 204.63.0.2 PING 204.63.0.2 (204.63.0.2) 56(84) bytes of data. 64 bytes from 204.63.0.2: icmp_req=1 ttl=239 time=112 ms 64 bytes from 204.63.0.2: icmp_req=2 ttl=239 time=119 ms
$ ping -c 2 206.223.144.2 PING 206.223.144.2 (206.223.144.2) 56(84) bytes of data. 64 bytes from 206.223.144.2: icmp_req=1 ttl=238 time=127 ms 64 bytes from 206.223.144.2: icmp_req=2 ttl=239 time=123 ms
$ ping -c 2 207.29.224.2 PING 207.29.224.2 (207.29.224.2) 56(84) bytes of data. 64 bytes from 207.29.224.2: icmp_req=1 ttl=240 time=132 ms 64 bytes from 207.29.224.2: icmp_req=2 ttl=240 time=122 ms
$ ping -c 2 207.29.240.2 PING 207.29.240.2 (207.29.240.2) 56(84) bytes of data. 64 bytes from 207.29.240.2: icmp_req=1 ttl=240 time=123 ms 64 bytes from 207.29.240.2: icmp_req=2 ttl=240 time=123 ms
さくらのネットワークから
$ ping -c 2 67.219.0.1 PING 67.219.0.1 (67.219.0.1): 56 data bytes --- 67.219.0.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 204.63.0.2 PING 204.63.0.2 (204.63.0.2): 56 data bytes --- 204.63.0.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 206.223.144.2 PING 206.223.144.2 (206.223.144.2): 56 data bytes --- 206.223.144.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 207.29.224.2 PING 207.29.224.2 (207.29.224.2): 56 data bytes --- 207.29.224.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 207.29.240.2 PING 207.29.240.2 (207.29.240.2): 56 data bytes --- 207.29.240.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
さらに、調査をしてみたところ、ルータやL3のPoint-to-Point なダイナミックルーティングに使用するネットワークは、/30 であると思われることから、208.74.65.6(nttec-demarc.cr02.centaurico.com) 及び、その対向ルータ(208.74.65.5)と、208.74.65.10(nttec-demarc.cr02.centaurico.com)及びその対向ルータ(208.74.65.9)に対して、ping応答があるか確認してみた。
先ずは正常なパターン。
$ ping -c 2 208.74.65.6 # N.T. Technology 側 PING 208.74.65.6 (208.74.65.6) 56(84) bytes of data. 64 bytes from 208.74.65.6: icmp_req=1 ttl=239 time=132 ms 64 bytes from 208.74.65.6: icmp_req=2 ttl=240 time=125 ms
$ ping -c 2 208.74.65.5 # 上位キャリア側 PING 208.74.65.5 (208.74.65.5) 56(84) bytes of data. 64 bytes from 208.74.65.5: icmp_req=1 ttl=240 time=117 ms 64 bytes from 208.74.65.5: icmp_req=2 ttl=240 time=159 ms
$ ping -c 2 208.74.65.10 # N.T. Technology 側 PING 208.74.65.10 (208.74.65.10) 56(84) bytes of data. 64 bytes from 208.74.65.10: icmp_req=1 ttl=240 time=128 ms 64 bytes from 208.74.65.10: icmp_req=2 ttl=240 time=118 ms
$ ping -c 2 208.74.65.9 # 上位キャリア側 PING 208.74.65.9 (208.74.65.9) 56(84) bytes of data. 64 bytes from 208.74.65.9: icmp_req=1 ttl=240 time=117 ms 64 bytes from 208.74.65.9: icmp_req=2 ttl=240 time=123 ms
さて、さくらのネットワークから。
$ ping -c 2 208.74.65.6 PING 208.74.65.6 (208.74.65.6): 56 data bytes --- 208.74.65.6 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 208.74.65.5 PING 208.74.65.5 (208.74.65.5): 56 data bytes 64 bytes from 208.74.65.5: icmp_seq=0 ttl=245 time=124.915 ms 64 bytes from 208.74.65.5: icmp_seq=1 ttl=245 time=124.883 ms
$ ping -c 2 208.74.65.10 PING 208.74.65.10 (208.74.65.10): 56 data bytes --- 208.74.65.10 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 208.74.65.9 PING 208.74.65.9 (208.74.65.9): 56 data bytes 64 bytes from 208.74.65.9: icmp_seq=0 ttl=245 time=115.100 ms 64 bytes from 208.74.65.9: icmp_seq=1 ttl=245 time=115.097 ms
ということで、N.T. Technology, Inc. の入り口のルータで止められていると思われる。純粋にそのルータはBGPルータ(AS32335)と思われることから、さくらのAS(AS9370/AS9371)からの経路をFilterしているのではないかと思う。ルータで、パケットフィルタをするとは考えにくいし…。それによって、さくらからの経路を知らないので、パケットがルータ内で破棄され、繋がらないのではないかと。ということで、2ch及び、N.T. Technology 宛の通信はすべて受けとらねーよという意志ですか、ええ、私みたいなユーザもアクセスするなって事ですか。しょんぼり。見たいときは、BiglobeのSIMからみますよ、えぇ。ほんとにね。若しくはどっかの箱に入って、w3mでみますともさ。
ちなみに、もしBGP 経路情報を元にやっているのであれば、さくらのネットワーク(コロケーションもしくはハウジングの大口顧客である、エクスサーバの環境からアクセスできるか気になるところ。
事の発端はおそらく、ひろゆき(2ch.sc)との間の派閥の問題ではないか。次のまとめが参考になるかもしれない。
この件で、さくら関係者というのはいまいちわからない。なぜならば、レンタルサーバではSSHの開放をしているし、自由にプログラムのコンパイルも可能だ。また、VPSなども、ユーザーで自由にコントロールをすることが出来る。むろん、さくらの内部の人が正規ユーザとしてサーバを借りてやっている可能性はあるとしても特権を乱用することは、まず無いだろう。そこまで愚かではないと思われる。また、さくらのネットワーク上にあるサーバ以外からもいくつか確認されていることから、内部の人が特権を利用しているとは考えにくい。