ブランクの恐ろしさを痛感した VPN ワイドの DNS について
- 2015/10/08
- 20:44
偽者インフラエンジニアから、新米プログラマに転職したワタクシげんちゃん。
最近は C# をメインとした ASP.NET MVC5 という、酒（愚痴）の肴にはモッテコイ の技術をつかって仕事をしており、日々頭を悩ませております。
そんな中、久しぶりにネットワーク業務を任されました。 フレッツ VPN ワイドの構築業務です。
（よっしゃ、久しぶりにカンタンな仕事だぜベイベｗｗｗ） と、テンション上がってきた (ﾟ∀三ﾟ三∀ﾟ) なワタクシでした。
………が。。。
「1時間で終わるだろう」 とたかをくくっていた業務でしたが、あるトラブルに見舞われてしまいまして、解決できたのはなんと 「6時間後」 。 しかもそのトラブルは、インフラエンジニア時代だったら 「絶対にわからないはずが無かったコト」 だったのです。。
ブログの放置、イコール勉強のさぼり、イチ人間としての詰めの甘さなどなどを反省して、久しぶりに反省メモを書こうと思います。
…いやぁ、ブランクとは恐ろしいものです。。OTL
業務内容（フレッツ VPN ワイド、参加者の追加）
今回の業務内容は、NTT フレッツ VPN ワイドの 「参加者」 を追加することでした。
手順を簡単に書いてしまうのならば 「サービス情報サイト」 にブラウザからアクセスして、あとはマニュアルに従って設定するだけです。ほんと、とても簡単。
しかし今回はちょっとしたトラブルが発生してしまい、解決に時間をかけてしまいました。
↑図1： 既存 VPN ワイドにたった1拠点を追加するだけなのに…
ここで VPN ワイドについて、簡単におさらいします。
フレッツ VPN ワイドは NTT が低価格で提供するエントリー VPN です。2013年くらいまではわりと主流だった VPN ワイドですが、この VPN サービスは IPv4 を使い、かつ NGN 網の性質により最大 200Mbps 帯域幅しか利用できませんでした。
ところが 2014年くらいになりますと、v6 オプションのしくみを用いて最大 1Gbps 帯域幅を利用できる 「フレッツ VPN プライオ」 という VPN サービスが登場しました。これからは VPN プライオが主流になるとは思いますが、とはいえ光回線を必ずしも使えない拠点を考えますと、まだ VPN ワイドは残り続けるような気がします。
↑フレッツ VPN プライオ。 ギャランティプランも存在する (https://flets.com/vpnprio/service.html)
しかし、時代の流れとは本当に恐ろしいものですね…。
過去、NGN が 200Mbps の帯域幅しか出せないことを不満に思い、ヤマハルータの恩恵を使って 1Gbps 帯域の VPN を構築した過去がありました （フレッツ・v6・オプションで VPN を組む 2013/12/31 参照）。あのときは IPv6 や NGN 網の理解に全労力をつぎ込みましたが、今や正式なサービスとして 1Gbps VPN が利用できる時代になってしまいました。。。(´・ω・`)
こういう時代の流れは、人を オッサン化 させてしまいます。
10年後の居酒屋、40歳手前になった僕は 「今はいいよなー。昔は 1Gbps の VPN を構築することが画期的だったんだぞｗ」 なんてことを20代の若者の部下に説教していることでしょう。なんてイキ （いい迷惑?） なオッサンなのでしょう。そうならないためにも時代の流れに取り残されないよう、皆さま頑張って行きましょう!! orz
…話がそれてしまいましたので、気を取り直して。。。 (///)
そんな VPN ワイドには、VPN 全体を管理する 「管理者」 と、それにぶら下がる 「参加者」 の2種類があります。管理者と参加者の関係は言わずもがなですが、これらの拠点から VPN に関する設定を行うときは 「サービス情報サイト」 という Web サーバにアクセスする必要があります。
繰り返しますが、サービス情報サイト にアクセスする必要があります。
………。
そう！
今回のトラブルは、このサービス情報サイトに アクセスできない という内容だったのです。 OTL
サービス情報サイトへのアクセス
フレッツ関連の情報を設定・管理するには、サービス情報サイトにアクセスしなければなりません。
このサービス情報サイトは NGN 網に Web サーバとして存在していますので、通常は NGN 網にクライアント PC を接続した上で、ブラウザからアクセスが可能です。なお、アクセス方法には大きくわけて2種類が存在し、これらは IPv4/IPv6 の技術によって分類できます。
IPv4 → PPPoE によるアクセス
IPv6 → IPv6 IPoE によるアクセス
◆ IPv4 PPPoE によるアクセス
v6 オプションに対応していない拠点などは、IPv4 PPPoE によるサービス情報サイトへの接続を行います。
具体的な方法としましては、フレッツ開通と同時に付属する CD-ROM を使った接続や、ルータのマルチセッション機能を使った接続などがありますが、僕の場合は Windows にデフォルトで搭載された PPPoE クライアント機能を使っていました。
↑図2： なんだかんだ、これが一番ラクな方法だと思う
◆ IPv6 IPoE によるアクセス
v6 オプションに対応した拠点などは、IPv6 IPoE によるサービス情報サイトへの接続を行います。ちなみに今回は、こちらの IPv6 IPoE による接続でした。
IPv6 IPoE によるサービス情報サイトへの接続は IPv4 PPPoE に比べてとても簡単です。マルチセッションや PPPoE などは不要で、ただ ONU と Windows マシンなどの作業 PC を LAN ケーブルで直結するだけ OK。これにより RA または DHCPv6-PD それぞれの形式で作業 PC に IPv6 アドレスが生成され、ネイティブによるサービス情報サイトにアクセスできます。
↑図3： IPv6 アドレスを生成するだけ。これが本当の "カンタン接続"
早い話 IPv6 はストレートに、IPv4 はワンクッションおいてサービス情報サイトにアクセスできるのですね。
アクセスできない…
前項にも書きましたように IPv6 IPoE の場合は RA または DHCPv6-PD の仕組みにより、ONU と作業 PC を LAN ケーブルで直結させるだけで準備が整います。もちろん作業 PC が IPv6 に対応していることが前提ですが、最近の OS はほぼ対応済みだと思います。
なお今回の物理配線につきましては、作業 PC と ONU を直結させずに両者間に存在するスイッチと接続しています。これは論理的は ONU と作業 PC が直結されている状態ですので、動作上は問題なく RA パケットを取得できます。ちなみに今回は RA 方式のネットワークでした。
↑図4： RA 方式だとこの時点で /64 プレフィックスがもらえる
これで IPv6 アドレスが生成されますので、本来ならばあとはサービス情報サイト "http://flets-east.jp" にブラウザアクセスするだけ――なのですが…それがどうも、うまくいかないのです。ためしにサービス情報サイトへの Ping 通信 (ping flets-east.jp) を試みるもリプライがありませんでした。
（IPv6 アドレスは生成できている。 でも通信できない。 これはおかしい…）
そう思った僕は、試しに別の参加者拠点（拠点 B）にて同様の手順を実施しました。すると不思議なことに拠点 B ではサービス情報サイトへのアクセスができました。もちろん Ping 通信にも成功しています。
↑図5： これが本番環境の恐ろしいところ
（A 拠点では大丈夫なのに、B 拠点では失敗する……だめだワカラン!!!）
そんなよくわからない怪奇現象に見舞われ四苦八苦したぼくは、人生初となる 「NTT の有料サポート窓口」 へと電話をかけたのでした…。
解決: DNS アドレスが取得できず
かくかくしかじか、と NTT サポート窓口に電話をしたところ――
「DNS サーバのアドレスは取得できておりますでしょうか？」
という回答を得ました。
（スラムダンク）
言われた瞬間、すぐにそれが原因であることがわかりました。
◆解決法
どうやら、何らかの原因により DNS 情報が取得できなかった ようです。
すぐさま作業 PC に NGN 網の DNS アドレス (2404:1a8:7f01:a::3) を手動で入力したところ、無事にサービス情報サイトへアクセスができました。もしかするとサービス情報サイトの IPv6 アドレスを直接ブラウザに指定しても、正常に通信できるかもしれませんね（未検証）。
それにしても、どうして DNS 情報が取得できなかったのでしょうか。
結局分からずじまいですが、おそらく RA パケットを解析すればそれが 「RA レベル」 の問題か否かの判別は可能です。せめてそれくらいは調査したいところ………でしたが、いかんせんこのトラブルは 客先 で引き起こしてしまったものでした。 一分一秒の解決を迫られる状態で （RA パケットを保存して、あとで Wireshark で解決してみるか…） なんて余裕はありませんでした。
まだまだ修行がたりませんね。。
最後に
今回のトラブルにより 「ブランク」 という恐ろしさを痛感しました。
おそらくインフラエンジニア時代でしたら NTT サポート窓口に電話せず、解決できたと思います。
それどころか、もしかしたら 「トラブルと認識しないレベル」 だったかもしれません。
NTT サポート窓口から前述した解決法を聞いたときも （安西先生の登場）――
（それだ!! よし、これで解決できる！！） という安堵感よりも、
（それだ!! …こんなことも思い出せないのか僕は…） というため息の方が強かったです。
繰り返しますが、本当にブランクの恐ろしさを感じました。
そういうことを踏まえると、やっぱり日々の NW 勉強は怠るべきではありませんね。
と、いうことで……またマメにブログを更新していこうと思いますw （＾ω＾ ）
最近は C# をメインとした ASP.NET MVC5 という、酒（愚痴）の肴にはモッテコイ の技術をつかって仕事をしており、日々頭を悩ませております。
そんな中、久しぶりにネットワーク業務を任されました。 フレッツ VPN ワイドの構築業務です。
（よっしゃ、久しぶりにカンタンな仕事だぜベイベｗｗｗ） と、テンション上がってきた (ﾟ∀三ﾟ三∀ﾟ) なワタクシでした。
………が。。。
「1時間で終わるだろう」 とたかをくくっていた業務でしたが、あるトラブルに見舞われてしまいまして、解決できたのはなんと 「6時間後」 。 しかもそのトラブルは、インフラエンジニア時代だったら 「絶対にわからないはずが無かったコト」 だったのです。。
ブログの放置、イコール勉強のさぼり、イチ人間としての詰めの甘さなどなどを反省して、久しぶりに反省メモを書こうと思います。
…いやぁ、ブランクとは恐ろしいものです。。OTL
業務内容（フレッツ VPN ワイド、参加者の追加）
今回の業務内容は、NTT フレッツ VPN ワイドの 「参加者」 を追加することでした。
手順を簡単に書いてしまうのならば 「サービス情報サイト」 にブラウザからアクセスして、あとはマニュアルに従って設定するだけです。ほんと、とても簡単。
しかし今回はちょっとしたトラブルが発生してしまい、解決に時間をかけてしまいました。
↑図1： 既存 VPN ワイドにたった1拠点を追加するだけなのに…
ここで VPN ワイドについて、簡単におさらいします。
フレッツ VPN ワイドは NTT が低価格で提供するエントリー VPN です。2013年くらいまではわりと主流だった VPN ワイドですが、この VPN サービスは IPv4 を使い、かつ NGN 網の性質により最大 200Mbps 帯域幅しか利用できませんでした。
ところが 2014年くらいになりますと、v6 オプションのしくみを用いて最大 1Gbps 帯域幅を利用できる 「フレッツ VPN プライオ」 という VPN サービスが登場しました。これからは VPN プライオが主流になるとは思いますが、とはいえ光回線を必ずしも使えない拠点を考えますと、まだ VPN ワイドは残り続けるような気がします。
↑フレッツ VPN プライオ。 ギャランティプランも存在する (https://flets.com/vpnprio/service.html)
しかし、時代の流れとは本当に恐ろしいものですね…。
過去、NGN が 200Mbps の帯域幅しか出せないことを不満に思い、ヤマハルータの恩恵を使って 1Gbps 帯域の VPN を構築した過去がありました （フレッツ・v6・オプションで VPN を組む 2013/12/31 参照）。あのときは IPv6 や NGN 網の理解に全労力をつぎ込みましたが、今や正式なサービスとして 1Gbps VPN が利用できる時代になってしまいました。。。(´・ω・`)
こういう時代の流れは、人を オッサン化 させてしまいます。
10年後の居酒屋、40歳手前になった僕は 「今はいいよなー。昔は 1Gbps の VPN を構築することが画期的だったんだぞｗ」 なんてことを20代の若者の部下に説教していることでしょう。なんてイキ （いい迷惑?） なオッサンなのでしょう。そうならないためにも時代の流れに取り残されないよう、皆さま頑張って行きましょう!! orz
…話がそれてしまいましたので、気を取り直して。。。 (///)
そんな VPN ワイドには、VPN 全体を管理する 「管理者」 と、それにぶら下がる 「参加者」 の2種類があります。管理者と参加者の関係は言わずもがなですが、これらの拠点から VPN に関する設定を行うときは 「サービス情報サイト」 という Web サーバにアクセスする必要があります。
繰り返しますが、サービス情報サイト にアクセスする必要があります。
………。
そう！
今回のトラブルは、このサービス情報サイトに アクセスできない という内容だったのです。 OTL
サービス情報サイトへのアクセス
フレッツ関連の情報を設定・管理するには、サービス情報サイトにアクセスしなければなりません。
このサービス情報サイトは NGN 網に Web サーバとして存在していますので、通常は NGN 網にクライアント PC を接続した上で、ブラウザからアクセスが可能です。なお、アクセス方法には大きくわけて2種類が存在し、これらは IPv4/IPv6 の技術によって分類できます。
IPv4 → PPPoE によるアクセス
IPv6 → IPv6 IPoE によるアクセス
◆ IPv4 PPPoE によるアクセス
v6 オプションに対応していない拠点などは、IPv4 PPPoE によるサービス情報サイトへの接続を行います。
具体的な方法としましては、フレッツ開通と同時に付属する CD-ROM を使った接続や、ルータのマルチセッション機能を使った接続などがありますが、僕の場合は Windows にデフォルトで搭載された PPPoE クライアント機能を使っていました。
↑図2： なんだかんだ、これが一番ラクな方法だと思う
◆ IPv6 IPoE によるアクセス
v6 オプションに対応した拠点などは、IPv6 IPoE によるサービス情報サイトへの接続を行います。ちなみに今回は、こちらの IPv6 IPoE による接続でした。
IPv6 IPoE によるサービス情報サイトへの接続は IPv4 PPPoE に比べてとても簡単です。マルチセッションや PPPoE などは不要で、ただ ONU と Windows マシンなどの作業 PC を LAN ケーブルで直結するだけ OK。これにより RA または DHCPv6-PD それぞれの形式で作業 PC に IPv6 アドレスが生成され、ネイティブによるサービス情報サイトにアクセスできます。
↑図3： IPv6 アドレスを生成するだけ。これが本当の "カンタン接続"
早い話 IPv6 はストレートに、IPv4 はワンクッションおいてサービス情報サイトにアクセスできるのですね。
アクセスできない…
前項にも書きましたように IPv6 IPoE の場合は RA または DHCPv6-PD の仕組みにより、ONU と作業 PC を LAN ケーブルで直結させるだけで準備が整います。もちろん作業 PC が IPv6 に対応していることが前提ですが、最近の OS はほぼ対応済みだと思います。
なお今回の物理配線につきましては、作業 PC と ONU を直結させずに両者間に存在するスイッチと接続しています。これは論理的は ONU と作業 PC が直結されている状態ですので、動作上は問題なく RA パケットを取得できます。ちなみに今回は RA 方式のネットワークでした。
↑図4： RA 方式だとこの時点で /64 プレフィックスがもらえる
これで IPv6 アドレスが生成されますので、本来ならばあとはサービス情報サイト "http://flets-east.jp" にブラウザアクセスするだけ――なのですが…それがどうも、うまくいかないのです。ためしにサービス情報サイトへの Ping 通信 (ping flets-east.jp) を試みるもリプライがありませんでした。
（IPv6 アドレスは生成できている。 でも通信できない。 これはおかしい…）
そう思った僕は、試しに別の参加者拠点（拠点 B）にて同様の手順を実施しました。すると不思議なことに拠点 B ではサービス情報サイトへのアクセスができました。もちろん Ping 通信にも成功しています。
↑図5： これが本番環境の恐ろしいところ
（A 拠点では大丈夫なのに、B 拠点では失敗する……だめだワカラン!!!）
そんなよくわからない怪奇現象に見舞われ四苦八苦したぼくは、人生初となる 「NTT の有料サポート窓口」 へと電話をかけたのでした…。
解決: DNS アドレスが取得できず
かくかくしかじか、と NTT サポート窓口に電話をしたところ――
「DNS サーバのアドレスは取得できておりますでしょうか？」
という回答を得ました。
（スラムダンク）
言われた瞬間、すぐにそれが原因であることがわかりました。
◆解決法
どうやら、何らかの原因により DNS 情報が取得できなかった ようです。
すぐさま作業 PC に NGN 網の DNS アドレス (2404:1a8:7f01:a::3) を手動で入力したところ、無事にサービス情報サイトへアクセスができました。もしかするとサービス情報サイトの IPv6 アドレスを直接ブラウザに指定しても、正常に通信できるかもしれませんね（未検証）。
それにしても、どうして DNS 情報が取得できなかったのでしょうか。
結局分からずじまいですが、おそらく RA パケットを解析すればそれが 「RA レベル」 の問題か否かの判別は可能です。せめてそれくらいは調査したいところ………でしたが、いかんせんこのトラブルは 客先 で引き起こしてしまったものでした。 一分一秒の解決を迫られる状態で （RA パケットを保存して、あとで Wireshark で解決してみるか…） なんて余裕はありませんでした。
まだまだ修行がたりませんね。。
最後に
今回のトラブルにより 「ブランク」 という恐ろしさを痛感しました。
おそらくインフラエンジニア時代でしたら NTT サポート窓口に電話せず、解決できたと思います。
それどころか、もしかしたら 「トラブルと認識しないレベル」 だったかもしれません。
NTT サポート窓口から前述した解決法を聞いたときも （安西先生の登場）――
（それだ!! よし、これで解決できる！！） という安堵感よりも、
（それだ!! …こんなことも思い出せないのか僕は…） というため息の方が強かったです。
繰り返しますが、本当にブランクの恐ろしさを感じました。
そういうことを踏まえると、やっぱり日々の NW 勉強は怠るべきではありませんね。
と、いうことで……またマメにブログを更新していこうと思いますw （＾ω＾ ）
スポンサーサイト
