Chrome で IPv6 ULA 宛て HTTPS が開けない – Firefox との差分から見る内部サイトの切り分け

内部ネットワーク上の HTTPS サイトで、Firefox では開けるのに Chrome だけ開けないという現象を確認しました。対象サイトは IPv4 と IPv6 ULA の両方を持ち、内部向け FQDN でアクセスする構成です。

結論から言うと、これは単純に「IPv6 が通っていない」「DNS が壊れている」「証明書が間違っている」とは言い切れない事象でした。観測した範囲では、Chrome が IPv6 ULA 宛ての HTTPS 経路を扱う時だけ、Firefox や curl と異なる挙動を示していました。

観測した事象

対象は、内部ネットワーク上の Web サービスです。FQDN は内部向けの名前で、IPv4 アドレスと IPv6 ULA を持っています。

この表で重要なのは、Chrome でも IPv4 に固定すると同じ FQDN のサイトを開ける点です。つまり、Chrome の HTTPS 処理全体、FQDN、SNI、証明書名、Host ヘッダ、Web アプリケーション側の応答がすべて壊れているわけではありません。

一方で、Firefox では IPv6 ULA に固定しても開けます。したがって、端末から対象 ULA への経路、サーバー側の IPv6 待ち受け、戻り経路、IPv6 ULA 上の HTTPS 処理は、少なくとも Firefox から見れば成立しています。

除外できる要因

IPv6 ULA に到達できない、だけでは説明できない

Firefox では同じ端末から同じ IPv6 ULA 宛てに接続できました。hosts ファイルで FQDN を IPv6 ULA に固定しても正常に開けています。

そのため、少なくとも次の要素は成立していると見てよさそうです。

• 端末から対象 IPv6 ULA への経路
• サーバー側の IPv6 待ち受け
• 戻り経路
• IPv6 ULA 上の TCP / TLS 接続
• Firefox から見た HTTP / HTTPS 処理

DNS 解決だけの問題ではない

hosts ファイルで FQDN を IPv6 ULA に固定しても Chrome では開けませんでした。通常 DNS の AAAA 応答だけが問題であれば、名前解決を固定した時点で挙動が変わるはずです。

そのため、DNS レコード、DNS キャッシュ、AAAA 応答の有無だけでは説明しきれません。Secure DNS / DoH を無効化しても改善しない場合、DoH だけを主原因と見るのも弱くなります。

証明書や Web アプリだけの問題ではない

同じ FQDN を IPv4 に固定すると Chrome でも開けます。これは、少なくとも IPv4 経路では、SNI、証明書名、Host ヘッダ、Web アプリケーション側の応答が成立していることを示します。

もちろん、IPv4 と IPv6 で異なるリバースプロキシや証明書チェーンを使っている場合は別ですが、同じサービスに到達している前提では、問題は Chrome が IPv6 ULA 宛てになった時の経路に絞られます。

ULA は内部ネットワークで正当なアドレスである

ここで重要なのは、IPv6 ULA は「変なアドレス」ではないという点です。ULA は内部ネットワークで使うための IPv6 アドレス空間です。グローバル到達性を持たないからといって、内部ネットワーク内での利用価値が低いわけではありません。

自宅や社内の内部サービスで、IPv6 ULA を使って管理系、監視系、内部 Web、Kubernetes、ストレージ、認証基盤へ到達する設計は十分あり得ます。問題が起きた時に「IPv4 にすれば開ける」で終わらせると、dual-stack や ULA 設計の問題点を見落とします。

IPv6 ULA や prefix 設計の考え方は、IPv6 における NAT66 再考 でも別の観点から扱っています。

Chrome 側で疑うべき領域

この事象で疑うべきなのは、Chrome / Chromium のネットワークスタックが、IPv6 ULA 宛て HTTPS を扱う経路です。具体的には、次のような領域が候補になります。

• Chrome のアドレス選択、Happy Eyeballs、接続試行順序
• IPv6 ULA 宛て接続時のタイムアウトや fallback の扱い
• Chrome 独自の DNS / host resolver / network service の挙動
• macOS のネットワーク API と Chrome の組み合わせ
• HTTP/2、TLS、レスポンス圧縮、大きなレスポンスでの詰まり
• IPv6 経路上の MTU、PMTU、フラグメント、MSS の問題

ここで注意したいのは、Chrome の仕様として ULA を拒否している、と断定しないことです。観測できているのは、同じ環境で Firefox と Chrome の挙動が分かれ、Chrome は IPv4 経路では開けるが IPv6 ULA 経路では詰まる、という事実です。

確認に使った観点

この種の問題では、ブラウザだけを見ていると切り分けが難しくなります。まず IPv4 と IPv6 を分けて確認します。

curl -4 -I https://internal.example.com/
curl -6 -I https://internal.example.com/

名前解決も確認します。

dig internal.example.com A
dig internal.example.com AAAA

macOS では、対象 IPv6 ULA への経路も確認します。

route -n get -inet6 fd00::a01:10

Chrome 側の切り分けでは、一時プロファイル、Secure DNS の設定、拡張機能なしの状態、IPv4 固定 / IPv6 固定の比較が役に立ちます。ただし、IPv4 固定で開けることは「IPv4 に逃げればよい」という結論ではなく、Chrome の IPv6 ULA 経路だけを切り出すための比較材料です。

今回の読み取り

今回の観測から言えるのは、次の程度です。

• 対象サイトそのものが壊れているとは言いにくい
• IPv6 ULA への到達性が全面的に壊れているとは言いにくい
• DNS 解決だけの問題とは言いにくい
• Chrome は IPv4 経路では同じ FQDN のサイトを開ける
• Chrome が IPv6 ULA 宛てになった時だけ、Firefox と異なる失敗をしている

したがって、問題領域は Chrome / Chromium 側の IPv6 ULA 宛て HTTPS 接続処理、または Chrome と macOS のネットワーク経路の組み合わせに寄っていると考えています。

結論

Firefox では開ける内部 HTTPS サイトが Chrome だけ開けない場合、単純に DNS、証明書、IPv6 到達性だけを疑うと切り分けを誤ることがあります。

今回のように、Firefox は IPv6 ULA で開ける、Chrome は IPv4 なら開ける、Chrome は IPv6 ULA だと開けない、という条件が揃う場合、Chrome の IPv6 ULA 経路だけを分離して見る必要があります。

IPv6 ULA は内部ネットワークで正当な設計要素です。IPv4 に固定すれば開けるという結果は、回避策としては使えても、設計上の答えとは限りません。dual-stack 環境では、どちらの経路で何が起きているのかを分けて確認することが重要です。

Related posts:

IPv6 における NAT66 再考 – ULA、GUA、Prefix 設計主権、IPv4 NAT の設計抽象 Chrome でのみ TLS 証明書エラーが発生 IPv6 Router Advertisement と DHCPv6 の役割整理 IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る – NAT66 以前の試行錯誤 BUFFALO BS-GS2016 を自宅基盤用スイッチとして見る – VLAN、管理機能、IPv6 対応範囲の考え方 MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること IPv4/IPv6 変換技術の重要性と価値 CentOS 7 Apache TLS 設定 – 自己署名証明書で HTTPS 化する CentOS 7 Apache TLS 設定 – Let’s Encrypt で HTTPS 化する Ubuntu 22.04 Apache TLS – 内部 CA 証明書で HTTPS を有効化する フォワードプロキシ認証の課題 – LDAP / Basic 認証 / HTTPS プロキシ / SAML・OIDC の整理 CentOS 7 IPv6 無効化 – 既存環境で無効化する場合の確認点