IPv6対応の自宅ネットワーク上のクライアントブラウザは、CloudFlareが運営するサイトなど、特定のIPv6サイトからhttps:// URLを読み込もうとするとハングしてタイムアウトします。このような状況では、ファイアウォールのライブログには、リモートHTTPSサーバーからの大量の受信RSTパケットがサイレントにドロップされていることが示されています。参考:問題なくすぐにロードされ、ネットワークに RST パケットがほとんどまたはまったく送信されません。現在私が持っている唯一の有効な回避策は、特定の IPv6 アドレス範囲へのアウトバウンド HTTPS アクセスをブロックするファイアウォール ポリシーです。これにより、ブラウザは IPv4 経由で問題のある HTTPS サーバーにアクセスするようになります。あまり魅力的ではないオプションは、6rd と radvd を無効にして IPv6 を完全にオフにすることです。
環境に関する関連詳細は次のとおりです。
- インターネット接続は、単一の静的 IPv4 アドレスを持つ CenturyLink ADSL2+ PPPoE です。
- DSLモデムはアクションテック C1000A最新のファームウェアを適用
- ファイアウォールはソフォス UTM v9.2DHCP、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からファイアウォール外部インターフェースにルーティングされます。
IPv6 経由の HTTPS に関しては、Google サイトは問題なく読み込まれますが、CloudFlare でホストされているサイトは必ず失敗します。どちらもネットワークの専門家チームを擁する大企業なので、CloudFlare がここで何か間違っているかどうかさえわかりません。
CloudFlare の HTTPS サーバーが IPv6 ではリセット パケットを大量に送信しているのに、IPv4 では送信していないことに気づいた人はいますか?
私の ISP である CenturyLink が、私を助けたり保護したりするために、誤った意図で RST パケットを偽造している可能性はありますか?
リセットが送信されているのは、ブラウザがサーバーの SSL 実装の一部に満足していないためでしょうか?