ドコモ光 マルチセッション 試行編

大分遠回りをしたが、やっと本来のマルチセッションについての検証。ルータはひかり電話用のPR-S300SEで、メインセッションをドコモnet(動的IP)に、セッション2をi-revo(固定IP)に繋げている状態。セッション2の接続ルール設定で自宅内サーバを送信元アドレスに設定し、ssh/dns/vpnをNATする。もう少し正確に言うとTCPが22と53を、UDPが53と1149をNATしている。vpnはGMOクラウド側にいるopenvpnクライアントと常時接続。

この設定でインターネットを利用していると、ルータが数時間でフリーズしてしまう。見た目上はランプも通常点灯のままなのだが、ブラウザで管理画面を表示する事は出来ず、それどころかpingにすら応答してくれない。結局ルータには通信不可能なので何もわからないのだが、きっとハングしてしまっているのだろう。

問題点を絞り込むために、まずは最も通信が多そうなvpnのNATをやめてみる。すると3時間過ぎてでも落ちない。それまで1〜2時間で確実に落ちていたので、3時間生き残るのは朗報。いきなり当たりを引いたか。以前はメインセッションでvpnをNATしていて何の問題もなかったので、セッション2でのvpnをやめてメインセッションに戻す事を検討。メインセッションはドコモnetなので、繋ぎ直すたびに律儀にIPが変わるのが不便。とはいえ切り分けのために一旦付け替えてみた。わりと安心して、この日は就寝。

6時間くらい寝て起床すると、案の定インターネットが落ちてる。vpnのログを見ると8時ちょうどに落ちている。時間のキリがいいのが気になるが、期間で言うと大体6時間くらいで落ちた模様。うーん、メインセッションでもだめなのかと考えて、メインセッションでのvpnも停止させて9時頃復旧。仕事中の15時頃に繋がらないーと家内から連絡を受ける。また6時間かと思いつつ、次はdnsのNATを止めてみる。sshを止めちゃうと入れなくなっちゃうから順番的にそっちから。

問題が起きない事の証明は時間効率が悪いもの。何も変更を加えず時間の経過をひたすら待つ。やれる事は少しでもやっておこうと、この間にドコモ光のメール問い合わせをしておく。間違いなくマルチセッション変更時点から異常が起きている事実を伝えて、解決方法や推奨構成、別機種ルータの貸し出し等を質問。回答は数日後になるだろう。

翌日、幸いにも先の設定が功を奏したようで、丸一日経過してもインターネットは安定。ここに来てやっと成功パターンを見つけた。ここまでの検証を整理してみると、

  1. セッション2でvpnとdnsをNAT : 1〜2時間でフリーズ
  2. メインセッションでvpn、セッション2でdnsをNAT : 5〜6時間でフリーズ
  3. セッション2でdnsをNAT : 5〜6時間でフリーズ
  4. セッション2でsshのみNAT : 24時間以上問題なし

という事になるので、問題となりうるのはやはりセッション2でのvpnとdns。その2つに共通してsshと異なる点と言えば、そう『UDP』。どうやらセッション2でUDP通信をNATするとルータがフリーズすると絞り込めた訳だ。メインセッションでのUDP通信用NATはおそらく問題ないが、その検証はまたの機会にでも。

dnsはGMOクラウド上にも立っていて補完的な位置付けなので最悪止めてもよい。しかし、vpnを止めるとGMOクラウド内ホストと自宅内chefサーバの通信経路が失われてしまう。そこでopenvpnサーバをUDPでなくTCPの設定に切り替える。セッション2のVPN用NATもUDPからTCPに変更して再開。GMOクラウド内ホストのopenvpnクライアントをTCPに切り替えて再接続。これでどうなるか様子見。

結果から言うと、この設定で数日経過してもルータは落ちていない。セッション2のUDP通信用NATが問題という事で間違いないだろう。尚、この間にドコモ光のメール相談窓口から返事が来たが、電話窓口で相談してみろという内容だけだった(もちろん文面はもっと丁重なもの)。電話窓口での相談は繋がるのが遅いという印象が強く、問題も解決したように思えた自分にとってその連絡は億劫に感じるものだった。しかし、1週間するかしないかくらいで、突然ルータのフリーズが再発し始めた。詳細は後日まとめるが、結局はサポートのお世話になる事に。

マルチセッションとは別の問題になるが、この前後からちょくちょく屋内DNSが止まる事が増えた。具体的には自宅内サーバの内向けbindが無応答になってしまう。一見インターネット障害に思える、この名前解決問題も事態の混乱を助長する一因だった。我が家のbindは外部の名前問い合わせをルータにforwardする設定で、bindのログを見ると以下のようなエラーが頻発していた。

got insecure response; parent indicates it should be secure

ルータ交換時にファームウェアが上がったか何かでdnssecのvalidationが通らなくなったのか。bindのnamed.confにてdnssec-validationを『no』に設定して、この問題も解決。ただマルチセッションやりたかっただけなのに、全然苦労に見合わない気が。。。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)