数日ごとに死ぬNECルーターを撤去して、UniFi Cloud Gatewayをtransix(DS-Lite)に直結した話

自宅のネットワークから、長年の悩みの種だったNECルーターを撤去した。UniFi Cloud Gateway Ultra が transix (DS-Lite) を直接張る構成になり、二重NATも解消した。

結論だけ先に書くと、UniFi は transix (DS-Lite) に公式対応している。繋がらない場合の急所は AFTR の指定方法で、ホスト名 gw.transix.jp ではなく IPv6 アドレスのリテラルで指定する。うちの環境ではこれだけで、2分でタイムアウトしていたものが20秒で開通した。

そしてこの切替作業、設定変更は一度も管理画面を開かずに、APIキーを渡した Claude Code にやってもらった。自分でやれば丸一日がかりの作業を、バックアップ・段階検証・自動ロールバックまで含めた石橋を叩く進め方で、実質1時間ほどで終わらせてくれた。その進め方自体が面白かったので、詳しく書いておく。

元の構成: ダブルNATという苦肉の策

回線はIIJ光で、IPv4 over IPv6 は transix (DS-Lite) 方式。機器は次の三段構成だった。

ONU → NEC Aterm WX7800T8 → UniFi Cloud Gateway Ultra → U7 Pro (AP)

なぜゲートウェイが二台あるのか。導入当時、UniFi Cloud Gateway は日本の IPv6 環境(IPoE + IPv4 over IPv6)にうまく対応できず、試しても繋がらなかったからだ。仕方なく、日本の事情に強いNECルーターに transix を終端させ、その配下に UniFi を置いた。UniFi 側から見ればただの DHCP クライアントなので、これなら動く。代償はダブルNATだ。

この構成には持病があった。数日〜数週間に一度、NECルーターの IPv4 over IPv6 だけが死ぬ。NECの診断画面を見ると IPv6 は正常、IPv4 だけが不通。再起動すれば直るが、また忘れた頃に死ぬ。Atermの機種別サポートページに「IPv4 over IPv6 通信モードで通信が不安定になる場合がある」という公式QAが存在するくらいなので、うちの個体だけの問題ではないらしい。

家族から「ネット繋がらないんだけど」と言われて再起動しに行く生活を、いい加減終わらせたかった。

前提: transix (DS-Lite) とは何か

ハマっている人向けに、最低限の仕組みだけ整理しておく。

• フレッツ系の IPoE 接続では、IPv6 はネイティブで繋がる。問題は IPv4 で、IPv4 パケットを IPv6 トンネルに包んで運ぶ(IPv4 over IPv6)。この方式の一つが DS-Lite で、IIJ系が使うのが Internet Multifeed 社の transix だ
• トンネルの終端(AFTR)は ISP 側にあり、NAT もそこで行われる(CGN)。だからルーター側の設定は「トンネルをどこに張るか」だけで、認証も ID/パスワードもない
• 代わりにポート開放は一切できない。外から入る手段は Tailscale などのオーバーレイに寄せる前提になる

そして肝心の対応状況。UniFi は UniFi OS 3.2.5 以降 + Network 8.0.7 以降(2023年11月〜)で transix の DS-Lite に公式対応している。日本の IPv4 over IPv6 のうち対応するのは transix だけで、v6プラスなどの MAP-E 系は非対応。つまり「UniFiは日本で使えない」は、transix 回線に限っては過去の話だ。うちが繋がらなかったのは、対応前に試していたからだった。

管理画面を開かずに、Claude Code に任せる

今回の作業は Claude Code(モデルは Fable 5)にほぼ全部やってもらった。きっかけは雑談で「Cloud Gateway ってAPI的に設定できたりする？」と聞いたことだ。

UniFi OS のコンソールは API キーを発行できる。場所は少し分かりにくくて、最近のバージョンでは設定画面の中ではなく、画面左端のアイコン列にあるプラグ(コネクタ)型アイコン → Integrations → Create New API Key。メールアドレス+パスワードでのAPIログインは二段階認証に阻まれるが、APIキーは認証フローを通らないのでその問題がない。

発行したキーをファイルに置いて chmod 600 し、Claude Code に場所を教える。あとは X-API-KEY ヘッダを付ければ、Web UI が使っているのと同じローカル API(https://ゲートウェイのIP/proxy/network/api/s/default/...)が全部叩ける。つまり UI でできることは全部できる。

ここからの Claude の進め方が、見ていてなかなか感心するものだった。

石橋の叩き方

手順1: 読み取りだけで現状を丸裸にする

まず一切の変更をせず、API から現状を吸い出していた。WAN は DHCP で上流のNECから 192.168.10.x をもらっていること、WAN の IPv6 が無効になっていること、U7 Pro のファームが IPv6 まわりの既知バグの修正版(8.5.11)より新しいこと、外向きのグローバルIPが Multifeed の AS だから回線は間違いなく transix であること。切替の前提条件を全部データで確認してから、設定全体のバックアップを JSON で取った。

手順2: 影響ゼロの変更で仮説を検証する

次にやったのは DS-Lite への切替──ではなく、WAN の IPv6 を SLAAC で有効にするだけの変更だった。LAN 側には配らないのでクライアントへの影響はゼロ。狙いは「NECルーターが IPv6 をブリッジで素通ししているなら、配下にいる UniFi の WAN にも NGN のグローバル IPv6 が降ってくるはず」という仮説の検証だ。

数分後、UniFi の WAN に 2409: で始まる NGN のアドレスが付いた。これが意味するところは大きくて、DS-Lite は「AFTR に IPv6 で届くこと」しか要求しないので、ケーブルを一切触らず、NECの配下のままトンネルを試せることが確定した。物理作業の前に、リスクの低い場所でリハーサルができる。

手順3: 自動ロールバック付きで切り替える

いよいよ IPv4 を DHCP から DS-Lite に切り替える。ここで Claude が用意したのが、自動ロールバック付きの切替スクリプトだった。設計はこうだ。

• LAN 内のサーバー(常時起動の開発機)から UniFi の API を叩く。LAN 経由なのでインターネットが死んでいても復旧操作ができる
• DS-Lite を適用 → 最大2分間、6秒おきに IPv4 の疎通を確認 → 回復しなければ自動で DHCP に書き戻す
• nohup で切り離して実行するので、作業している Claude 自身の接続が切れても完走する

最後の点が地味に重要で、Claude Code は動作にインターネットを必要とする。WAN切替に失敗すればClaude自身も操作不能になるが、ロールバックはスクリプトが単独でやってくれる。AIが「自分が死んでも安全側に倒れる」仕掛けを自分で組んでから作業する、というのは示唆的だった。

#!/bin/sh
# UCG の WAN を DHCP → DS-Lite に切替え、疎通しなければ自動で戻す
WANID=<WAN設定のID>   # GET /rest/networkconf で確認できる
API="https://192.168.1.1/proxy/network/api/s/default/rest/networkconf/$WANID"
KEY=$(cat ~/.config/ucg-api-key)

put() { curl -sk -X PUT -H "X-API-KEY: $KEY" \
  -H 'Content-Type: application/json' -d "$1" "$API"; }
net_ok() { curl -4 -sm 4 https://1.1.1.1/cdn-cgi/trace | grep -q '^ip='; }

put '{"wan_type":"dslite","wan_dslite_remote_host":"2404:8e00::feed:100","wan_dslite_remote_host_auto":false}'

sleep 20
i=0
while [ $i -lt 20 ]; do
  net_ok && { echo "SUCCESS"; exit 0; }
  sleep 6; i=$((i+1))
done

echo "TIMEOUT: reverting"
put '{"wan_type":"dhcp"}'

1回目は失敗した。原因はDNSの鶏と卵

最初の切替は、2分待っても IPv4 が復活せず、自動ロールバックが発動して元に戻った(ロールバックは設計通り20秒で完了した。この時点で「失敗してもすぐ戻れる」ことが実証されたのは、精神衛生上とても大きい)。

敗因はすぐに特定された。AFTR を公式ドキュメント通りホスト名 gw.transix.jp で指定していたことだ。

考えてみれば当然で、切替の瞬間、ルーターは古い IPv4 の経路を失っている。その状態で「トンネルの張り先」をホスト名で持っていても、それを解決する DNS がもう使えない。鶏と卵である。NECのような国産ルーターはこの辺りをよしなにやっているのだろうが、UniFi は素直にスタックする。

対処はシンプルで、AFTR を IPv6 アドレスのリテラルで指定する。

$ dig +short AAAA gw.transix.jp
2404:8e00::feed:100
2404:8e00::feed:101
2404:8e00::feed:102

NTT東エリアなら 2404:8e00::feed:100(西は 2404:8e01:: 系になる。事前に自分の回線で dig して確認しておくこと)。リテラル指定にした2回目は、適用から20秒で開通した。

transix で「設定は合っているはずなのに繋がらない」という人は、まずここを疑ってみてほしい。設定画面の「IPv6 ゲートウェイアドレスまたはホスト名」に、ホスト名ではなくアドレスを入れるだけだ。

最終的な設定値

UniFi 側の設定はこれだけ(設定 → インターネット → 対象WAN → 高度な設定を「手動」に)。

項目	値
IPv6 接続	SLAAC
IPv4 接続	DS-Lite
AFTR	2404:8e00::feed:100(リテラル指定)
MSS クランプ	auto のまま

MSS は手動で 1412 にする流儀もあるが、うちは auto のままで実測 450Mbps(NEC撤去後の再計測では668Mbps。後述)出ており、問題は起きていない。まず auto で試して、速度が出ない・特定サイトだけ開けない場合に 1412 を試すのがいいと思う。

なお DS-Lite になると出口のグローバルIPは CGN の共有アドレスになり、ポート開放は一切できなくなる。うちは外からのアクセスを全部 Tailscale に寄せているので実害はないが、ここは構成次第で要検討。

NECの撤去はダウンタイムほぼゼロだった

DS-Lite が UniFi 側で動いた時点で、NECルーターの仕事は「IPv6 を素通しするブリッジ」だけになっている。数日様子を見たあと、ONU のケーブルを NEC から抜いて UniFi の WAN ポートに直結した。

面白いのはここで、切替の前後で出口のIPが変わらず、トンネルは切れた形跡すらなかった。DS-Lite のトンネルは「ルーターの IPv6 アドレス」に紐付いていて、そのアドレスは SLAAC(プレフィックス + MAC アドレス由来)で生成される。プレフィックスも MAC も変わらないので、間に挟まっていた透過ブリッジが消えても、L3 的には何も起きていないことになる。

こうして最終形はこうなった。

ONU → UniFi Cloud Gateway Ultra (DS-Lite) → U7 Pro (AP)

シングルNAT。管理画面は一つ。そして数日ごとに死んでいた機械は、構成ごと消えた。

撤去した日の夕方、APIで健康診断もしてもらった

撤去後に「で、実際速くなったの？」と Claude に聞いたら、これも管理画面を開かずに API だけで一通り計測してくれた。UniFi は WAN のレイテンシとパケットロスを5分粒度で記録しているので(v2/api/site/default/aggregated-dashboard で取れる)、切替前後の比較がそのまま数字で出せる。

指標	NEC経由(前日15時〜当日朝)	直結後
WANレイテンシ 平均	4.05ms	3.16ms
WANレイテンシ 最大	8ms	5ms
パケットロス	ほぼ0%	ほぼ0%
Uptimeモニタ可用性	─	100%

レイテンシは約0.9ms(2割強)の短縮。NATが一段消えた分としては妥当な数字で、体感に出る差ではないが、「悪化していない」ことをデータで確認できるのが大きい。

スピードテストも UCG 本体に API(cmd/devmgr の speedtest)で実行させたところ、下り668Mbps / 上り687Mbps / ping 4ms。切替直後の実測450Mbpsからさらに伸びて、ほぼ対称の速度になった。

面白かった計測が二つある。一つは負荷時のレイテンシ、いわゆるバッファブロートの測定だ。ルーターや ISP の機材は、送りきれないパケットを一時的にバッファ(待ち行列)に溜める。回線が飽和するとこの行列が伸びて、ダウンロード中だけ ping が跳ね上がる。出来の悪い機材だと飽和時に +100ms 以上増えることも珍しくなく、「家族が動画を見ていると Web 会議がカクつく」の正体はだいたいこれだ。DS-Lite は全トラフィックが ISP 側の CGN(共有NAT装置)を通るので、この点は特に疑われやすい。

そこで東京のサーバーから並列10本・507Mbps を流し込んで回線をほぼ飽和させ、その最中に ping を打ってみた。結果は平均4.7ms・最大10.2ms・ロス0%。アイドル時(平均3.4ms)から+1.3msしか増えない。回線を目一杯使っても待ち行列がほとんど伸びていない、つまり大容量ダウンロードの裏でも Web 会議やゲームは平気ということで、CGN 経由という字面から想像するよりずっと素性がいい。なお NEC 時代の負荷時レイテンシは測らないまま撤去してしまったので、これは改善の証明ではなく現構成の健全性の証明である。

もう一つは tracepath の出力に出た pMTU の数字だ。MTU は1パケットで運べる最大サイズで、普通のイーサネットは 1500 バイト。tracepath は経路上のどこでこの上限が縮むかを検出してくれるのだが、1ホップ目の UCG で 1500 から 1460 に落ちる。1460 = 1500 − 40 は IPv6 ヘッダのサイズそのもので、「IPv4 パケットを IPv6 に包んで運ぶ」という DS-Lite の抽象的な説明が、−40バイトという具体的な数字になって見えている。

誤解のないように書いておくと、この40バイトの税金は今回新たに発生したものではない。transix を使う限り NEC 時代も実効 MTU は同じ 1460 で、変わったのはトンネルの入口が NEC から UCG に移った結果、pMTU が縮む場所が1ホップ目に来たことだけだ。シングルNATになったことの確認も含めて、1コマンドで今の構成が丸ごと説明できる出力になった。

なお「ダウンタイムほぼゼロ」の実態も API の downtime 履歴に残っていた。ケーブル差し替えと設定反映で 70秒 + 113秒 + 128秒の3回、合計約5分。この間トンネル自体は張り直されておらず、出口 IP も変わっていない。

一番の収穫は「AIに石橋を叩かせる」体験だった

技術的な結論は上に書いた通りだが、個人的に一番印象に残ったのは作業の進め方そのものだった。

自分でやっていたら、たぶん丸一日コースだった。管理画面とドキュメントを往復し、思い切って切り替えては家中のネットを巻き添えにし、原因の切り分けに悩み…という未来が容易に想像できる。実際には、私がやった物理作業はAPIキーの発行とケーブルの差し替えだけで、あとはチャットで会話しているうちに終わっていた。

ポイントは、AIが速かったことではなく(それもあるが)、慎重さの品質が高かったことだと思う。フルバックアップを取ってから触る。影響ゼロの変更で仮説を検証してから本番の変更に進む。失敗時の自動ロールバックを先に用意する。自分の接続が切れても安全側に倒れるよう nohup で切り離す。1回目の失敗から原因(DNSの鶏と卵)を特定して、2回目で通す。どれも「分かってはいるが、人間がやると面倒で省略しがち」な手順ばかりだ。

ネットワーク機器の設定変更は「失敗すると復旧手段も一緒に失う」タイプの作業で、だからこそ腰が重くなる。APIキーを渡して、石橋を叩く段取りごと任せられるようになったのは、この種の作業との付き合い方が変わる体験だった。

後日談: 「回線ごと死ぬ」への保険も常設にした

この作業の途中、「WAN の切替に失敗したら、作業している Claude ごとネットから切り離される」という問題への対策として、スマホの USB テザリングをサーバーの予備回線にする案が出ていた。今回は自動ロールバックが仕事をしたので出番はなかったが、この仕掛け自体が便利だったので、netplan の設定を仕込んで常設にした。

スマホを USB で挿してテザリングを ON にするだけで、サーバーがモバイル回線に切り替わる(抜けば自動で戻る)。回線障害の際も、スマホ回線で AI と作業しながら LAN 経由でルーターを復旧操作できる。詳細は別記事に書いた。

→ 光回線が死んでも詰まないように、スマホを「挿すだけの予備回線」にしておく

まとめ

• UniFi Cloud Gateway は transix (DS-Lite) に公式対応している(UniFi OS 3.2.5+ / Network 8.0.7+)。MAP-E 系は非対応
• 繋がらないときの急所は AFTR の指定。ホスト名ではなく IPv6 リテラルで(東日本: 2404:8e00::feed:100)
• MSS クランプは auto でまず試す。実測 668Mbps・負荷時のレイテンシ増も +1.3ms で、CGN 経由でも素性は良かった
• 既存ルーターが IPv6 ブリッジになっているなら、撤去前に配下のまま DS-Lite をテストできる
• トンネルは SLAAC アドレスに紐付くので、前段ブリッジの撤去はダウンタイムなしでいける
• そして、この手の「失敗が怖い系」の作業は、APIキーを渡して AI に石橋を叩かせるのが思いのほか快適だった