iPadでWebRTCが機能しない問題はVPNのせいか？：TailscaleとIPv6フラグメント損失の発見
本記事は、開発者が自身のp2clawアプリケーションをiPad上で動作させた際に発生した、WebRTC通信に関する難解なバグ（ハイゼンバグ）の調査過程を詳細に記しています。MacやLinuxなど他のデバイスでは問題なく動作するにもかかわらず、iPadでのみページがロードされずに停止するという現象が発生しました。
当初、開発チームは「iPad本体」「WebKitブラウザエンジン」「Tailscale VPN」といった複数の容疑者を立てて調査を進めました。WebRTCハンドシェイクやデータチャネルのオープンは正常に完了し、最初のGETリクエストも送信されていますが、応答（レスポンス）がiPad側に届かないという状況でした。
調査過程では、メッセージサイズ制限（maxMessageSize）やネットワーク安定性など多くの要因を排除しましたが、問題の原因はブラウザエンジン（WebKit）のバグにあると仮定し、その方向に思考が偏りがちでした。しかし、決定的な手がかりを得るため、開発者はWebRTC通信ではなく「Ping」テストに切り替えました。
その結果、IPv4を使用した場合（1,400バイトのping）はフラグメントが正常に再構築される一方、**IPv6を使用し大きなデータパケット（1,400バイト）を送信した場合のみ、フラグメントが完全に消失する**という現象を発見しました。この損失はiOS固有の問題ではなく、Tailscale VPN自体に起因することが判明しました。
最終的な原因究明の結果、Tailscaleのクライアントの実装において、IPv6パケットヘッダーに含まれる「フラグメント（断片）」を正しく解析する機能が欠落していることが判明しました。このため、大きなデータペイロードが複数のフラグメントに分割されて送信される際、そのうちのフラグメントがTailscaleによって「未知のプロトコル」として認識され、アクセス制御ポリシー（ACL）に基づき破棄されていたのです。これは、VPNトンネルを通過する特定のネットワーク層での処理上の欠陥でした。
背景
WebRTCはリアルタイム通信を実現するための技術であり、データチャネルを通じて大きなデータを送る際、パケットサイズやネットワークの制約（MTU）から「フラグメンテーション（分割）」が発生することがあります。本記事の調査は、この複雑なネットワーク層でのデータの流れと、VPNがそのプロセスに与える影響を追跡したものです。
重要用語解説
- WebRTC: ウェブブラウザ間でリアルタイム通信を行うための技術規格です。音声や映像だけでなく、データチャネルを通じて任意のデータを送受信できます。
- フラグメンテーション（断片化）: 大きなデータパケットがネットワークのMTU（最大転送単位）を超える場合、それを複数の小さな「フラグメント」に分割して送信する処理のことです。
- Tailscale: プライベートなネットワークを構築するためのVPNサービスの一つで、デバイス間の安全な接続を提供します。この記事では、そのトンネル機能が特定のパケットロスを引き起こす原因となりました。
今後の影響
本件は、WebRTCやその他のリアルタイム通信において、使用するVPNやネットワーク層のプロトコル（特にIPv6）がフラグメンテーションを適切に処理できるかどうかが極めて重要であることを示しています。今後の開発では、このような特定の環境下でのパケットロス検証と、VPNレイヤーでのフラグメント対応の実装が必須となります。