Chrome で IPv6 ULA 宛て HTTPS が開けない時に見ること – Firefox との差分を切り分ける

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

このような事象では、すぐに「Chrome が悪い」「IPv6 が悪い」「証明書が悪い」と決めたくなります。しかし、実際には DNS、名前解決結果、IPv4 / IPv6 の経路、TLS 証明書、ブラウザ側の名前解決設定が重なっています。重要なのは、Chrome と Firefox の違いを手がかりにしながら、どの層で差分が出ているのかを分けて確認することです。

なお、この記事は Chrome / Firefox の実装仕様を断定するものではありません。自宅内部ネットワークで観測した事象をもとに、IPv6 ULA 宛て HTTPS の切り分け方を整理するものです。

IPv6 ULA は内部向けの IPv6 アドレスである

IPv6 ULA は Unique Local Address の略で、内部ネットワーク向けに使う IPv6 アドレスです。IPv4 でいうプライベートアドレスに近い位置づけですが、IPv4 の NAT 前提の感覚とは少し違います。

内部サイトに IPv6 ULA を付け、内部 DNS で FQDN を引かせる構成自体は不自然ではありません。問題は、ブラウザ、OS、DNS、証明書、ルーティングが、その名前とアドレスを同じ前提で扱えているかです。

まず Chrome と Firefox の差分を事実として整理する

今回のような事象では、最初に結果を条件ごとに分けます。単に「Chrome で開けない」と書くと大きすぎます。Firefox では開けるのか、Chrome でも IPv4 なら開けるのか、FQDN ではなく IPv6 ULA を直接指定したらどうなるのかを分けて見ます。

この切り分けで、Firefox では開ける、Chrome でも IPv4 なら開ける、Chrome だけ IPv6 ULA 経路で詰まる、という条件が見えるなら、見るべき場所はかなり絞れます。Web アプリケーションそのものやサーバー全体の障害ではなく、Chrome がその名前を IPv6 ULA 宛てに解決し、HTTPS として接続する部分に注目します。

名前解決を確認する

まず、FQDN がどのアドレスを返しているかを確認します。内部 DNS が A レコードと AAAA レコードの両方を返している場合、ブラウザがどちらを選ぶかによって結果が変わることがあります。

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

macOS では、システムの名前解決結果も確認します。dig は指定した DNS への問い合わせ確認には向いていますが、アプリケーションが実際に使う名前解決経路とは異なることがあります。

dscacheutil -q host -a name internal.example.com
scutil --dns

Chrome の Secure DNS、Firefox の DNS over HTTPS、OS の DNS 設定、内部 DNS が混ざると、同じ FQDN でもブラウザごとに見ている結果が違うことがあります。内部向け FQDN を使う場合は、ブラウザ側の Secure DNS / DoH 設定も確認対象です。

IPv4 と IPv6 ULA の到達性を分けて見る

次に、IPv4 と IPv6 を分けて到達性を確認します。FQDN で開けるかだけを見ると、どちらの経路を使っているのかが曖昧になります。

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

macOS で IPv6 ULA 宛ての経路を見る場合は、対象アドレスへのルートも確認します。

route -n get -inet6 fd00:1234:5678::10
ping6 fd00:1234:5678::10

curl -6 や ping6 で到達できるなら、単純な IPv6 経路断とは言い切れません。Chrome だけ失敗する場合は、ブラウザ側の名前解決、証明書検証、接続ポリシー、プロキシ設定などに視点を移します。

TLS 証明書を確認する

内部サイトを HTTPS 化している場合、証明書の SAN にアクセスしている FQDN が含まれている必要があります。IPv6 ULA を直接指定してアクセスする場合は、証明書名との不一致が起きやすくなります。

openssl s_client -connect internal.example.com:443 -servername internal.example.com -showcerts

Chrome と Firefox で証明書エラーの扱いが違って見える場合もあります。内部 CA を使っているなら、OS の信頼ストア、Firefox 独自の証明書ストア、Chrome が参照している信頼ストアの違いも確認します。

Chrome の Secure DNS と内部 DNS

Chrome には Secure DNS の設定があります。内部向けドメインを使っている場合、Chrome が OS の DNS 設定と同じ経路で名前解決しているとは限りません。特に、外部の DoH リゾルバーへ問い合わせる設定になっていると、内部ドメインや内部向け AAAA レコードを正しく解決できないことがあります。

Firefox 側にも DNS over HTTPS の設定があります。そのため、Chrome と Firefox の差分を見るときは、どちらか一方だけでなく、両方のブラウザがどの DNS 経路を使っているかを確認します。

IPv4 に固定するのは回避策であって原因特定ではない

Chrome で IPv4 に固定すると開ける場合、運用上の回避策にはなります。しかし、それだけでは原因を特定したことにはなりません。IPv6 ULA の経路、DNS、証明書、ブラウザ設定のどこに差分があるのかを残しておかないと、別の内部サイトでも同じ問題が起きます。

dual-stack 環境では、「IPv4 なら開ける」は便利な逃げ道です。ただし、IPv6 ULA を設計として使うなら、IPv6 側で何が成立していないのかを確認する必要があります。

確認順序

まとめ

Chrome で IPv6 ULA 宛て HTTPS が開けず、Firefox では開ける場合、問題を 1 つの原因に決めつけると切り分けを誤ります。内部 DNS、IPv4 / IPv6 の経路、TLS 証明書、内部 CA、ブラウザの Secure DNS / DoH 設定を分けて確認する必要があります。

IPv6 ULA は内部ネットワークで正当に使えるアドレスですが、ブラウザ、証明書、名前解決、経路設計が揃っていなければ、内部 HTTPS サイトでは差分として表面化します。Chrome と Firefox の挙動差は、どちらが正しいかを決めるためではなく、どの層で前提がずれているかを見つけるために使うべきです。

関連する記事

関連記事

IPv6 における NAT66 再考 – ULA、GUA、Prefix 設計主権、IPv4 NAT の設計抽象 IPv6 Router Advertisement と DHCPv6 の役割整理 IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る – NAT66 以前の試行錯誤 IPv4/IPv6 変換技術の重要性と価値 BUFFALO BS-GS2016 を自宅基盤用スイッチとして見る – VLAN、管理機能、IPv6 対応範囲の考え方 FQDN フィルタリングの限界 – DNS 依存の通信制御をどう考えるか 光 BB ユニットに感じる抵抗感 – ISP 提供ルーターと自宅ネットワーク設計の自由度 自宅用 VLAN 対応スイッチの選び方 – タグ VLAN、管理機能、仮想化環境を整理する