サーバーにはIPv6アドレスしかない一方、サイトの利用者にはIPv4ネットワークからアクセスする人もいます。DDoS対策CDNを導入すれば、問題なく利用できるでしょうか。

可能です。ただし、CDNがIPv4ユーザーからのリクエストを受け付け、IPv6でオリジンに接続できることが条件です。 

ユーザーからCDN、CDNからオリジンへの接続は別々です。同じIPバージョンを使う必要はありません。契約前には、単に「IPv6対応」と書かれているかだけでなく、IPv6でのオリジン接続とIPv6専用オリジンの両方に対応しているか確認してください。

導入後、トップページは表示されるのにログインできない場合も、すぐにサーバーを変更する必要はありません。キャッシュ、オリジンまでのネットワーク経路、HTTPS設定が原因で、そのような状態になることがあります。

IPv4ユーザーがIPv6専用オリジンにアクセスできる仕組み

オリジンは、Webページを保存し、APIリクエストを処理し、アプリケーションを動かすサーバーです。リバースプロキシ型CDNを使うと、通常、ユーザーはオリジンに直接接続せず、まずCDNのエッジ拠点に接続します。オリジンのコンテンツが必要なときは、CDNが別途リクエストを送ります。

たとえば、ユーザーはIPv4でCDNに接続し、CDNはIPv6でオリジンからページを取得します。その結果を元のクライアント接続を通じて返します。ブラウザーがオリジンのIPv6アドレスを知る必要も、ユーザーがプロトコル変換を設定する必要もありません。

DNSだけで実現するわけではありません。DNSはクライアントの接続先を示し、プロキシサービスが二つの接続を仲介します。

この構成を実装している製品もあります。Amazon CloudFrontの IPv6でのユーザー接続とオリジン接続に関するドキュメント では、クライアント側とオリジン側を別々に設定できます。対応するカスタムオリジンでは、IPv4専用、IPv6専用、デュアルスタックの接続を選択でき、IPv6専用モードではオリジンのホスト名がIPv6アドレスに名前解決される必要があります。

ただし、これは特定の製品の機能であり、すべてのDDoS対策CDNが同じ設定に対応するとは限りません。この記事の対象はHTTP/HTTPSのWebサイトとAPIです。ゲームで使うネイティブのTCP・UDPポートについては、対応するプロキシと保護サービスを別途確認してください。

購入前に「IPv6対応」の範囲をどう確認するか

よくある行き違いは、事業者から「IPv6対応」と聞き、パブリックIPv4アドレスのないサーバーを購入したものの、設定画面ではIPv4のオリジン入力が必須だった、というケースです。

IPv6でのユーザー接続、オリジン接続、IPv6専用オリジンを区別する

これらはそれぞれ異なる条件を指します。

• IPv6でのユーザー接続：ユーザーがIPv6でCDNに接続できます。
• IPv6でのオリジン接続：CDNがIPv6でオリジンに接続できます。
• IPv6専用オリジン：オリジンへの接続に使えるIPv4アドレスがなく、CDNはIPv6だけで接続する必要があります。

二番目に対応していても、三番目まで対応しているとは限りません。Alibaba Cloud CDNの オリジン設定に関するドキュメント では現在、IPアドレスを指定するオリジン設定にIPv4とIPv6を登録できるものの、少なくとも一つのIPv4アドレスが必要とされています。また、IPv6のオリジンアドレスを使う前にIPv6でのオリジン接続を有効にする必要があります。これは該当製品の設定方式に関する制約であり、すべてのCDNに共通する条件ではありません。

問い合わせる際は、要件を具体的に伝えましょう。「オリジンにはパブリックIPv6アドレスしかなく、IPv4はありません。IPv4ユーザーにHTTPSサイトを提供したいのですが、検討中のプランとエッジ拠点で対応できますか。オリジンにはIPv6アドレスを直接登録すべきですか。それともAAAAレコードだけを持つオリジン用ドメインを登録すべきですか」といった聞き方です。

単に「IPv6に対応していますか」と聞くより、具体的な回答を得やすくなります。事業者を比較する際は、 用途・ネットワーク経路・防護要件からDDoS対策CDNを選ぶためのガイド も参考に、ユーザーの所在地、オリジンのデータセンター、実際の接続能力を合わせて確認してください。

デュアルスタックのオリジンでもIPv4で接続されている場合がある

デュアルスタックとは、オリジンがIPv4とIPv6の両方で接続できる構成です。両方のアドレスを設定していても、CDNが実際にどちらを使うかはオリジン接続ポリシーによって決まります。

たとえば、Cloudflareの IPv6互換性に関する説明 によると、プロキシ対象レコードにIPv4とIPv6の両方のオリジンアドレスがある場合、IPv4での接続が優先されます。AAAAレコードがあるだけでは、オリジンへの通信がIPv6に移行したとは言えません。  

従来のIPv4アドレスを廃止する前に、IPv6でのオリジン接続を検証してから本番設定を変更してください。IPv6専用オリジンへの経路に障害が起きても、そのサーバーには自動的に切り替えられるIPv4の経路がありません。

両方のユーザーをCDN経由にするDNS設定とは

公開サイトのホスト名と、CDNに登録するオリジンのアドレスには、それぞれ異なる役割があります。

例として、 www.example.comはユーザーがアクセスするホスト名であり、事業者の指示に従ってCDNに向けます。一方、CDNの管理画面に登録するオリジンアドレスは実際のサーバーを指します。専用のオリジン用ドメインを使う場合は、同じCDNの接続口に戻らず、オリジンを指すことを確認してください。戻ってしまうと接続がループします。

AレコードはIPv4アドレス、AAAAレコードはIPv6アドレス、CNAMEレコードは別のホスト名へのエイリアスを示します。CNAMEで導入する場合、IPv4ユーザーが必要とするAレコードは、エイリアスの参照先であるCDNのホスト名から得られることがあります。利用者が必ずAレコードを手動で追加するわけではありません。

IPv6を「追加」するために、通常のDNS設定でAレコードをCDNに向け、AAAAレコードだけをオリジンに直接向けないでください。 一部のIPv6ユーザーがCDNを迂回し、別の経路を通って、CDNに設定した防護も受けられなくなる可能性があります。

また、DNSを事業者に預けるだけでは、その事業者のプロキシは有効になりません。Cloudflareの プロキシ状態に関する説明 では、プロキシ対象レコードとDNSのみのレコードが区別されています。DNSのみのレコードでは、Webサイトへのリクエストが自動的にHTTPプロキシの保護を通るわけではありません。

導入後は、管理画面に緑色のステータスが表示されるかどうかだけでなく、ユーザーが実際にどこへ接続しているかを確認してください。

IPv4アクセスとIPv6でのオリジン接続をどう検証するか

公開側の接続口、オリジン、実際のアプリケーションリクエストの三段階で検証します。以下のコマンドは、 digと curlをインストールしたLinuxまたはmacOSのターミナルで実行できます。例示したドメインは自分のドメインに置き換えてください。

まず公開DNSとIPv4の接続口を確認する

公開サイトのホスト名について、レコードを照会します。

dig +short A www.example.com
dig +short AAAA www.example.com

CNAMEで接続している場合、出力にはエイリアスと最終的なアドレスの両方が表示されることがあります。Aレコードの照会で最終的に利用可能なIPv4アドレスが得られるか確認し、CDNの管理画面の情報と照合して、想定した接続口か判断してください。

AAAAレコードの照会結果が空でも、IPv4ユーザーのアクセスに影響するとは限りません。また、それだけではCDNがIPv6でオリジンに接続できるかどうかも分かりません。今回の照会で公開ホスト名のIPv6接続先が得られなかったことを示すだけです。

次に、インターネットへ直接接続できるテスト環境からIPv4のリクエストを送ります。

curl --noproxy '*' -4 -sS \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntotal=%{time_total}s\n' \
  https://www.example.com/

remote_ipは今回の接続先アドレス、 http_codeはHTTPステータスコード、 totalはリクエストの総所要時間です。 --noproxy '*'を指定すると、このテストでは環境に設定されたプロキシを使いません。プロキシサーバーへの接続結果をWebサイトへの直接接続と取り違えることを防げます。

想定した応答が返れば、今回のIPv4リクエストは接続口に到達しています。ただし、ステータスが200でも内容を確認し、エラーページを正常なアプリケーションの応答と誤認しないようにしてください。301または302の場合は、リダイレクト先のホスト名も確認します。CDNに接続していない別のアドレスへ誘導される場合があります。

IPv6ユーザーにもサイトを提供する場合は、IPv6接続が利用できる環境で、上記の -4を -6に変えて再度テストします。テスト端末にIPv6の経路がなければ、失敗の原因をすぐにCDNと判断することはできません。

これらのIPバージョン指定と、後述する接続先アドレスの指定方法は、 curlの公式マニュアル で確認できます。ここでの -4はクライアント側の接続だけを指定します。CDNがオリジンにIPv4とIPv6のどちらで接続しているかは証明できません。  

次に、オリジンが実際にIPv6でWebサイトを提供しているか確認する

サーバーにIPv6アドレスが割り当てられていても、WebサイトがIPv6で利用できるとは限りません。WebサービスがIPv6で待ち受けているか、ポートが正しいか、クラウドのセキュリティグループ、サーバーのファイアウォール、インターネットへの経路が接続を許可しているかを確認します。

オリジンへのアクセスを許可されたIPv6テスト環境から、次のコマンドを実行します。

curl --noproxy '*' -6 -sS \
  --connect-timeout 10 --max-time 30 \
  --resolve 'www.example.com:443:[2001:db8::10]' \
  -D - -o /dev/null \
  https://www.example.com/

2001:db8::10はドキュメント用の例示アドレスです。そのまま実環境のテストには使えません。自分のオリジンのIPv6アドレスに置き換えてください。

このコマンドは指定したIPv6アドレスに接続しつつ、URLのホスト名を保持します。この名前はHTTPS証明書の検証、TLSハンドシェイク時のServer Name Indication（SNI）、HTTPのHostヘッダーに使われます。例ではすべて www.example.comを使う想定です。実際のオリジン接続で異なる名前を使う場合は、その設定に合わせてテストしてください。

証明書エラーが出たら、信頼チェーン、有効期限、ホスト名との一致を確認します。デフォルトサイトや404が返る場合は、Hostヘッダー、バーチャルホスト、リクエストパスを確認してください。設定の問題を隠すために証明書検証を無効化したり、このテストのためだけにオリジンをインターネット全体へ公開したりしないでください。

直接接続に成功しても、「このテスト端末からオリジンに到達できる」ことが分かるだけです。CDNのオリジン接続拠点は別のネットワーク経路を使うため、そこからの接続は次の手順で検証します。

実際にオリジンへ到達するリクエストで確認を完了する

トップページは表示できるのにログインAPIが失敗する状態は、サイト全体が開かない場合より原因を見誤りやすくなります。

理由は単純かもしれません。トップページはCDNのキャッシュから返され、オリジンに接続していない一方、ログイン、検索、フォーム送信はリアルタイムでオリジンに接続する必要があるためです。

機密情報を含まないテスト用パスとして、たとえば /origin-check.txtを用意し、オリジンから識別しやすい内容を返します。CDNでは、このパスのキャッシュを明示的にバイパスするよう設定してください。その後、通常の公開ホスト名からアクセスし、該当時刻のCDNのオリジン接続ログとオリジンのアクセスログを確認します。

ランダムなクエリーパラメーターを追加したり、リクエストに Cache-Control: no-cacheを付けたりするだけでは、CDNのキャッシュをバイパスした証拠にはなりません。実際の動作はキャッシュキーや事業者のルールによって変わります。

検証では、次の三点を確認します。コンテンツは現在のオリジンから返されたか。オリジンはそのリクエストを受信したか。実際のオリジンへの接続はIPv6だったか。実IPモジュールがログ内のクライアントアドレスを書き換えている場合は、転送されたユーザーIPだけでなく、実際の接続元アドレスを示す項目も確認してください。

その後、テストアカウントでログイン、API、アップロード、ダウンロード、実際に使うWebSocket接続を確認します。一つのパスの調査のためにサイト全体のキャッシュを削除し、オリジンへのリクエストを増やさないようにしてください。

導入後にアクセスできない場合、どう切り分けるか

切り分け中は、できるだけ一度に一つの条件だけを変えてください。たとえばパスとプロトコルを固定してテストネットワークだけを変えるか、クライアントを固定してキャッシュから返るパスとオリジンに到達するパスを比べます。DNS、証明書、オリジンアドレスを同時に変更すると、アクセスが回復しても何が原因だったか分からなくなります。

「表示はされるが遅い」場合は、 DNS、TTFB、リソース読み込みの切り分け方法 に沿って各段階を確認できます。IPv6なら速いとは限りません。ユーザーからエッジ拠点、エッジ拠点からオリジンへの経路品質と、アプリケーションの処理時間を別々に見てください。

DDoS対策CDNの導入後もIPv6オリジンに防護は必要か

必要です。CDNが処理できるのはCDNを通るリクエストです。オリジンのIPv6アドレスへ直接送られたトラフィックが、自動的にCDNへ回ってスクラビングされることはありません。

IPv6アドレスが長くても、秘密であるとは限りません。公開されたAAAAレコード、見落とした業務用サブドメイン、アプリケーションの応答内容からオリジンアドレスが見つかることがあります。心当たりがある場合は、 オリジンIPの露出とアクセス制限に関するガイド も参考に、CDNを迂回する経路を調べてください。

導入後は、オリジンの業務用ポートが想定したCDNからの通信だけを受け付けるよう制限します。事業者が提供する実際のオリジン接続元アドレス範囲に基づいてルールを設定し、利用できる場合はオリジン認証も組み合わせてください。IPv4とIPv6のルールは別々に確認します。IPv4を制限しても、IPv6に同じ制限が自動適用されるわけではありません。

必要な運用管理用の接続は確保し、CDNのオリジン接続元アドレス範囲が更新された際の反映方法も確認します。複数のサイトでCDNの送信元IPを共有する場合、そのIP群を許可するだけでは自分のサイト宛ての接続を識別できないことがあります。製品が対応する認証方法も検討してください。

アプリケーションへのアクセス制限と帯域保護も区別が必要です。サーバーのファイアウォールでリクエストを拒否しても、大量の攻撃トラフィックによって上流回線が埋まる可能性はあります。外部から到達可能なIPv6オリジンに直接攻撃を受けるリスクがある場合は、オリジン側ネットワークのDDoS対策も検討してください。

Webサイトの高速化と防護に CDN07のDDoS対策CDN を検討する際は、ユーザーの地域、オリジンのデータセンター、オリジン接続の制約を合わせて相談し、エッジ拠点、帯域、セキュリティポリシーを決めてください。IPv6専用オリジンについては、購入前に該当プランの接続条件を確認し、一般的なWebサイト向けの導入手順をそのまま当てはめないようにします。  

よくある質問

IPv6専用サーバーでも、IPv4アドレスを買わずにWebサイトを運営できますか？

可能です。ただし、前段のサービスがIPv4の接続口を提供し、IPv6でオリジンに接続できることが条件です。メール、管理画面、その他そのプロキシを通らないサービスも考慮してください。Webサイトが開けても、サーバー上のすべてのサービスがIPv4ユーザーに対応したことにはなりません。

AAAAレコードだけのドメインにIPv4ユーザーはアクセスできますか？

別の変換サービスがないIPv4専用環境では、通常は直接接続できません。CDNで対応するなら、ユーザーが使う公開ホスト名に利用可能なCDNのIPv4接続口を用意し、IPv4ユーザーがIPv6オリジンへ直接接続する構成にしないでください。

CDNでIPv6を有効にすると、HTTPS証明書を交換する必要がありますか？

IPバージョンが変わるという理由だけで交換する必要はありません。ドメイン名でアクセスする場合は、クライアントからCDN、CDNからオリジンのそれぞれについて、証明書、信頼関係、名前の一致が正しいことが重要です。エッジ証明書が正常でも、オリジン証明書が接続要件を満たしているとは限りません。

IPv4ユーザーがアクセスできれば、IPv6でのオリジン接続も正常だと証明できますか？

できません。キャッシュから応答している可能性があり、デュアルスタックのオリジンにはIPv4で接続している場合もあります。キャッシュを明示的にバイパスするリクエストを使い、実際の接続情報を確認してください。

オリジンへの接続はIPv6なのに、ログに記録されたユーザーIPがIPv4でも正常ですか？

正常な場合があります。接続相手はCDNのオリジン接続拠点ですが、転送ヘッダーには元のIPv4ユーザーのアドレスが入ることがあります。両者は別のアドレスです。アプリケーションで実IPを利用する際は、確認済みのプロキシからの転送ヘッダーだけを信頼し、クライアントが送ったヘッダーを無条件に信用しないでください。

DDoS対策CDNがIPv6専用オリジンに対応しない場合、サーバーを交換するしかありませんか？

そうとは限りません。その接続方式に対応するCDNへの変更、オリジンへのIPv4追加、管理下にあるデュアルスタックのリバースプロキシの設置を比較できます。中間プロキシを増やすと経路、帯域、防護、運用のコストも増えるため、サーバーの月額料金だけで判断しないでください。

導入前に二つの接続をそれぞれテストする

• IPv4ユーザーがアクセスできるかどうかは、まずCDNに利用可能なIPv4接続口があるか確認します。
• IPv6専用オリジンが使えるかどうかは、選んだプランがIPv6だけでオリジンに接続できるか確認します。
• トップページが表示されても、オリジンへの接続が成功しているとは限りません。動的リクエストか、キャッシュを明示的にバイパスするパスを検証します。
• CDN導入後も、IPv6オリジンのアクセス制御と上流側の防護を維持します。

導入前に、サイトのホスト名、オリジンのIPv6アドレス、データセンターの地域、接続ポート、HTTPSで使うホスト名の設定を整理してください。 CDN07への導入相談 を通じて適したプランを確認できます。IPv4アクセス、IPv6でのオリジン接続、実際のアプリケーションリクエストをそれぞれテストしてから本番トラフィックを切り替えましょう。公開後に「トップページは開くのに操作を完了できない」と判明する事態を避けられます。