「その後」を正直に書く
こんにちは、NET INNOVATION です。
以前、UniFi Cloud Gateway で JPNE の v6プラス固定IPを「DS-Lite 乗っ取り型」で終端した実装記録を公開しました（UniFiでv6プラス固定IPを終端する実装記録）。あの記事の最後で「運用してみた続報を出す」と書いたので、その約束を果たします。
結論から言うと、この2ヶ月は平穏ではありませんでした。 導入時に UniFi OS 5.1.26 だったコンソールは、その後 6.0 系へメジャーアップグレードされ、そのたびに新しい地雷を踏みました。ただ、いずれも「検知して自動で戻す」仕組みを積み増すことで潰し、最終的には 通信断ゼロの運用に到達しています。同じ構成を検討している方の役に立つよう、起きたことをそのまま残します。
本記事で触れる UniFi OS 6.0.x は 先行（Early Access）チャネルのビルドです。執筆時点の一般安定版は 5.1 系（5.1.31 など）で、6.0.x はまだ広くは配布されていません。新機能・新挙動を早期に検証するため、弊社では先行版を運用しています。
記事中の IP アドレス等はすべて例示用（ドキュメント範囲）に置き換えています。固定IPv4は
203.0.113.42、対応する JPNE IID は00cb:0071:2a00:0000、DS-Lite の内部アドレスは192.0.0.2として説明します。
事件①：インターネットは正常なのに、拠点間VPNだけ死ぬ（conntrack固着）
最初の障害は、インターネットが終始まったく正常だったせいで、17時間気づかなかったものでした。
きっかけはコントローラの設定再適用です。UniFi が数秒の間に WAN の IPv4 を何度も取り違え、トンネルの IPv4 が固定IP（203.0.113.42）と DS-Lite 既定の 192.0.0.2 の間を往復しました。
wgsts1000 → 192.0.0.2 (UniFiが固定IPを剥がした)
wgsts1000 → 203.0.113.42 (スクリプトが復旧)
wgsts1000 → 192.0.0.2
wgsts1000 → 203.0.113.42
wgsts1000 → 192.0.0.2 ← 最後がこれ
この往復の中で、SNAT ルールが消えている一瞬に、ルーター自身が拠点間VPN（WireGuard）のハンドシェイクを送信してしまいました。すると送信元が 192.0.0.2 のまま Linux の conntrack（コネクション追跡テーブル）に記録されます。
問題はここからです。conntrack は最初の判定を保持し続けるため、SNAT を戻したあとも、その通信の送信元は 192.0.0.2 のまま。DS-Lite の内部専用アドレスなので、戻りパケットは永遠に返ってきません。しかも WireGuard は数秒ごとに再送するので、エントリの有効期限が延々とリフレッシュされ、自然には絶対に失効しない。
固定IPの復旧自体は、watchdog が正しく発火して即座に終わっていました。なのに apply を何回走らせても直らない。 腐った conntrack エントリを1件削除した瞬間、ハンドシェイクが成立し、拠点間の経路が一気に復活しました。
対策：apply の最後に「腐ったエントリ」を掃除する
恒久対策として、固定IPを再適用するスクリプトの 最後（SNAT 再挿入の直後） に、腐った conntrack エントリを掃除する処理を足しました。順序が逆だと、掃除したそばから再生成されて意味がありません。
安全のため、削除の前に必ず件数を確認し、0件なら削除コマンド自体を発行しないゲートを付けています（正常時＝大多数では掃除処理が走らず、影響範囲がゼロになる）。「インターネットが正常だから気づけない」タイプの障害なので、掃除が効かなかった場合は必ず警告ログを残すようにもしました。
この事件の教訓：SD-WAN・Teleport など UniFi の VPN 機能は内部的に WireGuard で動いており、DS-Lite 乗っ取り構成と同じ地雷（
192.0.0.2を掴む）を踏み得ます。 インターネットの疎通だけを監視していると、拠点間通信の死を見逃します。
事件②：UniFi OS 6.0.7 以降、WAN設定を3分ごとに再適用して全IPv4断
次は OS のメジャーアップグレードで来ました。UniFi OS 6.0.7 以降、WAN 設定が約3分周期で再適用され、そのたびにトンネル IPv4 が 192.0.0.2 に戻って全 IPv4 通信が瞬断する、という挙動です。以前からの「設定保存のたびに戻る」問題が、今度は時限式で定期的に起きるようになった格好です。
これはコントローラ側の仕様変更が原因で、ユーザー側では止められません。できるのは「戻されたら、いかに速く戻し返すか」です。
そこで復旧の検知を強化しました。
- カーネルの netlink イベント（アドレスの増減）を直接購読する方式に、WAN 側 IPv6 の変化も監視対象として追加
- 健全性チェックに項目を追加：OS が3分ごとにトンネルのローカル /128 アドレスだけを消すようになったため、「トンネル定義も固定IPも SNAT も無傷なのに、実は送信できない」状態を、以前のチェックでは"健全"と誤判定していた。これを検知できるようにした
これで復旧は 実測 約1〜2秒まで詰められました。ただ、瞬間的とはいえ1秒強の断が3分おきに入るのは気持ちのいいものではありません。そこで次の一手を打ちました。
事件③（対策）：dummy0 併置で「通信断ゼロ」に
決め手は、トンネルのローカル IPv6 アドレス（/128）を、UniFi が絶対に触らない dummy0 インターフェースにも同時に持たせるという方法でした。
UniFi が消すのは実 WAN インターフェース側の /128 だけです。ところがこのトンネルはインターフェースに dev バインドされていないため、Linux カーネルの送信元アドレス確認は全インターフェースを走査します。つまり、WAN 側の /128 が消えている約1秒の間も、dummy0 側に同じアドレスが生きていれば、カーネルの送信チェックが通り続け、断が原理的にゼロになるのです。WAN 側は従来どおりスクリプトが付け直すので、上流との整合も保たれます。
実測でもはっきり効果が出ました。
| dummy0 併置前 | 併置後 | |
|---|---|---|
| 「ローカルアドレス未設定」エラー | 10分あたり30〜50件 | 0件 |
| 疎通（1秒間隔・300回） | 2損失（0.667%） | 0損失（0%） |
| RTT | 平均 4.32ms | 平均 4.30ms（不変） |
3分周期の再適用そのものは今も続いています（後述の OS 6.0.9 でも止まりませんでした）が、利用者から見た通信断は消えました。
OS 6.0.9 での再検証 — 3分周期は止まらなかった
その後、先行版の UniFi OS を 6.0.9 まで上げました。リリースノートに WAN の DHCP 接続が切れる問題の修正が挙がっており、今回の3分周期に効くことを期待したのですが、期待は外れ、3分周期の再適用は継続していました。
ここは正直に書いておきます。この種の"メーカー非公式"な運用は、OS のアップデートで挙動が変わり続ける前提で構えるべきです。幸い、断絶ゼロ化（dummy0 併置）は OS 側の周期処理とは独立に効くため、通信への影響は出ていません。
2ヶ月運用してわかったこと
- メジャー OS アップグレードは、非公式運用に容赦なく地雷を撒く。 それでも「検知して自動で戻す」層を厚くすれば、実用レベルの安定は保てる。
- 監視は二段構えが必須。 速い netlink イベント駆動（約1秒で復旧）と、取りこぼしを拾うポーリング（最大数秒）の両方が要る。片方だけでは必ず穴が出る。
- インターネットの疎通監視だけでは足りない。 拠点間VPN が死んでも気づけない。出口IP・トンネル端点・SNAT の存在まで見て、はじめて"健全"と言える。
- conntrack という伏兵。 一瞬の設定崩れが、腐ったコネクション追跡として居座り続けることがある。
「UniFi は日本の固定IP回線で本当に運用できるのか」という問いへの、2ヶ月後の答えはこうです。「できる。ただし作って終わりではなく、OS の変化に追随して手を入れ続ける覚悟が要る」。 逆に言えば、そこさえ引き受ければ、ネットワークからカメラ・入退室までを1画面で運用できる UniFi の利点を、固定IP環境でも享受し続けられます。
弊社では、UniFi × 日本回線の設計・構築・運用保守まで、営業を介さず現役のエンジニアが直接ご対応します。「導入はできても運用が不安」という案件こそ、お気軽にお問い合わせください。サービスの詳細はネットワーク構築のページもご覧ください。
関連記事