はじめに、の前に

こちらのブログを動かすのは実に9ヶ月ぶりですが、皆さんいかがお過ごしでしょうか。
このブログを動かしていないのには山よりも深い理由(?)がありまして、ずばり…

===== 宣伝ここから =====

株式会社Flatt Securityにおいて研究開発事業部が発足したためです 🎉🎉🎉
それに伴い、普段やっていたセキュリティ関連の研究はFlatt Security Researchに投稿を予定しています。 (既に記事を3つ投稿しているため、興味がある方は読んでみてください。)

基本的にあちらで投稿する内容は英語ですが、社内で翻訳して公式ブログの方で出る場合もありますので、日本語で読みたい方はこちらをご確認ください！

===== 宣伝ここまで =====

あらすじ

さて、ここからが本記事の本編です。なお、本記事の筆者はネットワーク機器等にあまり詳しくないため、ここからの内容には一部誤りが含まれる可能性があります。誤りを見つけた場合はTwitter等でお知らせいただければと思います。

半年に一回の固定費の見直しを行った結果、光回線を現在使用しているNURO光からenひかりLiteへ乗り換えることで、回線費用が月に約900円安くなるという試算が出ました。

意気揚々と契約の電話をしたところまでは良かったのですが、電話口で料金説明を受けた際に「ホームゲートウェイのレンタルが必要であり、それに月220円かかる」という旨の説明が受けました。

ホームゲートウェイが何なのかを全く知らなかったために詳しく確認したところ、ひかり電話を契約する場合は通常の機器からだと電話線が繋がらないため、原則としてホームゲートウェイが必要であるということを知りました。
「確かに普通のルーターは電話線を繋げられないよなぁ」と納得し、万が一解約したくなった場合は無料でできるようであったためそのまま契約手続きを進めることに。

この説明を受けた際、「Yamahaさんのルーターをお持ちであれば不要なケースもあるんですが…」という事をチラッと言っていたため、220円/月を節約するために少し調べてみることにしました。

Yamahaのルーター

軽く調べたところ、enひかりカスタマーセンターの方がおっしゃっていた「Yamahaさんのルーター」というのは、NVRシリーズと呼ばれるルーターであることが分かりました。
法人向け機器は新品で買うと高価であるため中古市場を物色していたのですが、現在主流になっていると思わしきNVR510という機器は中古相場でも一万円強ほどするものであり、220円/月を節約するための設備投資としては少し高すぎるように思えます。

その型落ちのNVR500であれば中古相場でも2000円弱で購入できるため、220円/月を節約するための設備投資としてはちょうど良いと判断し、購入を決めました。

MAP-E

ここで思い出していただきたいのは、筆者が契約しようとしているプランはenひかりLiteであるというところです。
このプランは、公式サイトにも記載のあるとおりIPoEのみに対応しており、その上IPv4 over IPv6の選択肢としてMAP-Eのみが存在します。

このMAP-Eというのは、利用者側に存在する機器内でアドレスの変換を行い、IPv4のみに対応したサービス群にアクセスすることを可能にする技術です。
これとよく比較されるものとしてDS-Liteという技術があります。こちらはMAP-Eとは対象的に、事業者側でのアドレス変換を行うものとなります。

厳密に確認したわけではありませんが、おそらくDS-Liteの方がMAP-Eよりも対応している機器が多いのではないかと思われます。

さて、ここまで説明した内容でお気づきの方もいらっしゃるかとは思いますが、上記で購入を決断したNVR500はMAP-Eに対応していません。

これは困ったということで作業通話内で相談したところ、以下の記事を紹介してもらいました。

内容としては、IPv4のみをNVR500に対してブリッジすることで、他のルーターの配下に置いていたとしてもひかり電話の通信を受け取れるようにするというものです。
手持ちの機材の中でこれをできそうなのはOpenWrtを焼いたFortiGate 50Eという機器なのですが、これは別のところで使っているため恒久的にONUの直下に置くことができません。

そこで、記事内でも使用されているIXシリーズのルーターを購入することにしました。

ネットワーク構成

記事内ではIX2215という機器が使用されていましたが、中古相場でも比較的高価であり物理的に大きいため、もう少し小さくて安価なIX2105を使用することにしました。
これにより、最終的に以下のような構成を目指すことにしました。

enひかりの工事完了後、まずは最小構成ということで上記の図の赤枠部分のみを構築しました。
IX2105の設定は以下のページ内の設定例3をベースに行い投入を行います。

構築後しばらくして、IPv6の疎通は確認できたのですが、MAP-Eのステータスがいくら待っても未接続のまま変わらないという問題に直面しました。

デバッグ

IX2105の設定方法をほぼ知らなかったので、ここからは手探りでやっていきます。

まず、MAP-Eのステータスを確認すると、以下のような表示になっていました。

Router(config)# show map-e status
Tunnel interface: Tunnel0.0
  Vendor Name: JPNE
  Status: waiting
  Request statistics:
    Last Request: 2024/09/12 15:49:37
    Last Update : -
    3 request, 0 success, 3 failure
Router(config)# 

3回リクエストが行われて3回とも失敗していることが分かりますが、これだけでは情報が少ないためリクエスト時のログを見てみます。

Router(config)# logging subsystem mape debug
Router(config)# event-terminal start
MAPE.022: MAP-E status changed from waiting to checking HGW, interface Tunnel0.0
MAPE.011: Check MAP-E HGW, interface Tunnel0.0
MAPE.013: Not detected MAP-E HGW, continue MAP-E, interface Tunnel0.0
MAPE.022: MAP-E status changed from checking HGW to getting rule, interface Tunnel0.0
MAPE.014: Request MAP-E rule information, interface Tunnel0.0
MAPE.022: MAP-E status changed from getting rule to reporting, interface Tunnel0.0
MAPE.017: Report MAP-E action, interface Tunnel0.0
MAPE.018: Success report MAP-E action, interface Tunnel0.0
MAPE.016: Failure get MAP-E rule information, interface Tunnel0.0(invalid map-e rule)
MAPE.022: MAP-E status changed from reporting to waiting, interface Tunnel0.0
MAPE.004: Next get MAP-E rule information after 1252 seconds, interface Tunnel0.0

このログを見ると、MAP-Eルールの取得時にinvalid map-e ruleというエラーが出ていることが分かります。
ただ、そもそもMAP-Eのルール取得が何をやっているのかわからなかったため、大雑把な切り分けから始めることにしました。

まず初めに、以下のようにホームゲートウェイを適切に使用するようにした場合はどうなるかを検証していきます。

この際、PC側から確認すると問題なくIPv4での接続ができていることがわかったため、この時点ではIX2105の設定に問題があると推測しました。

しかしながら、設定方法自体はNECの公式ページに記載されている通りであり、原因が全くわからないという状態となりました。
切り分けのためにIPv6のフィルタリング設定をオフにしたり、MAP-Eの接続方式をOCN固有の物へと変更したりしましたが、それでも変化はありません。

この時点で、IX側の設定が間違っているのではなく、何らかの理由によりプロバイダ側で問題が発生しているのではないかという事を疑い始めます。
そこで、IXの代わりにFortiGate 50E (OpenWrtインストール済み)を使用し、以下のような構成にすることでどういった挙動をするのかを観察することにしました。

なお、OpenWrtの設定は以下のページを参考にしました。

するとなんと、MAP-Eが正常に動作していることが確認できました。

やはりIX2105の設定が間違っているのかと一瞬疑いましたが、OpenWrtの設定時にMAP-Eルールを計算するツールを使用したことを思い出しました。

これが一般的な設定方法なのかがわからなかったため、手元にあった別の市販ルーターを接続し、MAP-Eが正常に動作するかどうかを確認してみます。
その結果、市販のルーターにおいてもMAP-Eが正常に動作しないことがわかりました。

投入先変更

これらの挙動から、市販ルーターではプロバイダ側からMAP-Eのルールを取得しており、プロバイダ側で何らかの設定をしないと正常に設定を取得できないのではないかという仮説が浮かびます。
そこでenひかりのカスタマーセンターへの問い合わせを行ったところ、「ホームゲートウェイに対する設定の投入を取りやめ、自前のルーターに対して設定の投入を行うように切り替える必要がある」という旨の回答を受けました。

ただし、この手続きは本来想定されているものでは無いようで、切り替えに2200円の手数料がかかる上に切り替え後に切り戻す場合は再度2200円の手数料がかかるとのことでした。
そのため、当該の手続きにより治るという確信を得たうえで実施したいと考え、調査を続行することにします。

投入先変更という単語から推測するに、設定の配信方法に何らかの出し分けが存在するものであると考えられます。
そこで、ONUとIX2105の通信をキャプチャしてどういった通信を行っているのかを見てみることにしました。

幸いなことに、手元にTL-SG105Eというポートミラーリングを行うことができる機器があったため、これを使用して以下のような構成に変更しました。

なお、ポートミラーリング先としてFortiGate 50Eを使用していますが、これはどうしても機材が足りず、仕方なくOpenWrt上にtcpdumpをインストールしてパケットキャプチャを行ったためです。

この状態でMAP-Eの再取得を走らせると、以下のログが確認できます。

00:22:13.168984 IP6 [送信元] > [宛先]: 40357+ [1au] AAAA? api.enabler.ne.jp. (46)

通信内容までは見ることができなかったものの、api.enabler.ne.jpを名前解決し、そこに対するリクエストを飛ばそうとしていることがわかったため、このドメインについての調査を行うことにしました。

インターネット上で当該ドメインについて調べてみると以下の記事がヒットします。

この記事によると、どうやらapi.enabler.ne.jpからMAP-Eのルールが配信されているので間違いないということがわかりました。
しかしながら、記事内で言及されているhttps://api.enabler.ne.jp/6a4a89a8639b7546793041643f5da608/get_rules?callback=v6plusというURLにアクセスしても、503とともに空のレスポンスが返されるだけでした。

もしかしたらホームゲートウェイを利用していない環境からリクエストを送信すると正常なレスポンスが帰るのかと思い、数名の方に試していただきましたが、どうやらそういうわけでもないようでした。

とはいえ、api.enabler.ne.jpに対して何らかのリクエストを送信しているのが確認できた以上、そのレスポンスが正常に帰ってきていないと仮定するのが良さそうです。
そこで、確信を得るためにenひかりカスタマーセンターの方へ「投入先変更の処理というのはapi.enabler.ne.jpからのレスポンスが変化するのでしょうか？」という旨の確認を行ったところ、その通りであるという旨の回答を受けました。

そのため、設定の投入先変更を申し込もうとしたのですが、申し込みを行う直前に「投入先変更を申し込まずにホームゲートウェイを解約したらどうなるのか」という点が気になってきました。
記事の冒頭でも軽く触れましたが、ホームゲートウェイの解約自体は手数料がかかるものではないため、ホームゲートウェイのみを解約した場合、最悪MAP-Eの設定が受け取れない環境になってしまうように思えます。

この疑問点を解消するため、再度enひかりカスタマーセンターの方へ確認をしたところ、「ホームゲートウェイを解約した場合は投入先が無くなるため、その場合は手数料無しで投入先変更が実施される」という回答を受けました。
元々ホームゲートウェイを廃止するために一連の作業を行っていたため、これ幸いと思いホームゲートウェイを解約して数時間後に再度IX2105を接続したところ、無事にMAP-Eが動作するようになりました。

api.enabler.ne.jp

さて、これらの手続きにより正常にMAP-Eが動作するようになったのですが、最後に一点解決しなければならない疑問が残されています。
それはずばり、api.enabler.ne.jpに対してどういったリクエストが送信されているのかという点です。

通信が暗号化されている都合上、機器の間でパケットキャプチャを行う方式での調査が難しかったため、市販ルーターのファームウェアを解析することにしました。

一連の作業を行っていたDiscordサーバーにおいて、別の方が市販ルーターのファームウェアを解析した結果、https://api.enabler.ne.jp/4027bf2bfdefca6d54b7650fbdeb41d0/get_rules?callback=v6plusというURLに対してリクエストを送信していることが判明します。
このURLを元に、ホームゲートウェイを使用している環境/使用していない環境でレスポンス内容がどのように変化するかを検証した結果、以下のようになりました。

これにより、投入先変更というのはapi.enabler.ne.jpからのレスポンスを出し分けることにより実現されているという可能性が高そうであるということが分かりました。

また、手元にある別ベンダ製市販ルーターのファームウェアを自分で解析した結果、別のURL (https://api.enabler.ne.jp/e4fe129ed441b61b3e72f835cd0cb61a/get_rules)に対してリクエストを送信していることが分かりました。
そのため、おそらくベンダごとに固有のIDが振られているのではないかという予想をしています。

まとめ

本記事では、ホームゲートウェイを使用せずにMAP-Eを利用しようとした際に直面した問題とその解決過程について詳しく説明しました。
インターネット上でもちらほら同様の問題に当たっていそうな方を見かけたため、そういったケースにおいてこの記事が参考になれば幸いです。

謝辞

本問題の原因究明にあたって検証等を手伝っていただいた@yanorei32、@_kokt_vrc、@KOBA789、@Tayu404、@pepepper_cpp、並びに通常想定されていない構成であるにも関わらず、親身にサポートしてくださったenひかりカスタマーセンターの皆様に改めて感謝申し上げます。