IPv6対応のホームネットワーク上のクライアントブラウザーは、CloudFlareが運営するサイトなど、特定のIPv6サイトからhttps：// URLをロードしようとするとハングし、タイムアウトします。このような状況では、ファイアウォールのライブログに、リモートHTTPSサーバーからの多数の着信RSTパケットが静かにドロップされていることが示されます。https://ipv6.google.comなどの他のIPv6サイトは、問題なくすぐにロードされ、ネットワークにRSTパケットをほとんどまたはまったく送信しません。現時点で唯一成功している回避策は、特定のIPv6アドレス範囲へのアウトバウンドHTTPSアクセスをブロックするファイアウォールポリシーです。これにより、ブラウザーはIPv4を介して問題のあるHTTPSサーバーに効率的にアクセスできます。あまり魅力的ではないオプションは、6rdとradvdを無効にしてIPv6を完全にオフにすることです。
環境の関連する詳細を次に示します。
- インターネット接続は、単一の静的IPv4アドレスを持つCenturyLink ADSL2 + PPPoEです
- DSLモデムは、最新のファームウェアが適用されたActiontec C1000Aです
- ファイアウォールはSophos UTM v9.2であり、DHCP、DNS転送、パケットフィルター、およびradvdの内部を処理します
- モデムはIPv4のNATとIPv6の6rdを処理します
- モデムLANとファイアウォール外部インターフェイスで共有されるネットワークは、192.168.0.0 / 24およびfd00 :: / 64です
- クライアントマシンとファイアウォールの内部インターフェイスによって共有されるネットワークは、192.168.1.0 / 24および2602：xxxx：xxxx：xxxx :: / 64です。
- トラフィックは、ファイアウォールのNATではなく、モデムの静的ルートを介してモデムLANからファイアウォールの外部インターフェイスにルーティングされます
HTTPS over IPv6に関しては、Googleサイトは問題なくロードされますが、CloudFlareがホストするサイトは常に失敗します。どちらもネットワーキングの専門家のチームを持つ大企業なので、CloudFlareがここで何か悪いことをしているかどうかさえわかりません。
CloudFlareのHTTPSサーバーがIPv4ではなくIPv6で大量のリセットパケットを送信しているのを見ている人はいますか？
私のISPであるCenturyLinkは、私を助けたり保護したりするために、誤った方法でRSTパケットを偽造できますか？
ブラウザがサーバーのSSL実装の一部に満足していないため、リセットが送信されていますか？