ドメインを Cloudflare に追加し、DNS レコードをプロキシ すると、ドメインを名前解決した訪問者は、オリジンサーバーの実 IP ではなく Cloudflare IP アドレスを受け取ります。オリジンの IP アドレスは隠され、Cloudflare はリクエストを最適化、キャッシュ、保護したうえで転送できます。
Cloudflare には、プロキシされたホスト名が共有する複数の IP アドレス範囲 ↗ があります。これらの IP アドレスが、Cloudflare の anycast ネットワーク の基盤です。同じ IP アドレスを世界各地のデータセンターから広報するルーティング方式で、各訪問者のリクエストは近いデータセンターへ送られます。
プロキシされた DNS レコード へのトラフィックはすべて、オリジンサーバーに届く前に Cloudflare を通ります。オリジンは個々の訪問者 IP からの通信を受けなくなり、代わりに Cloudflare IP アドレス ↗ からの通信を受けます。これらの IP は、プロキシされたホスト名が共有します。
オリジンのファイアウォールから見ると、少数の送信元から大量のトラフィックが来ているように見え、レート制限 や自動ブロックが働くことがあります。訪問者トラフィックはすべて Cloudflare IP から来るため、これらの IP をブロックすると(誤ってでも)訪問者はアプリケーションに届きません。
上記の指針は、Cloudflare の HTTP プロキシを使うドメインに適用されます。Magic Transit は動作が異なります。Web リクエストをプロキシするのではなく、ネットワーク層で IP ネットワーク全体を保護します。Cloudflare は BGP であなたの IP アドレス範囲(プレフィックス)を広報します。ネットワーク宛てのトラフィックは、検査と DDoS フィルタリングのあと、インフラへ転送されます。
Cloudflare IP アドレスを意図せずブロックしないよう、オリジンの Web サーバーでも Cloudflare IP アドレスを許可してください。
.htaccess ファイル ↗ で明示的に許可するか、iptables ↗ を使います。
次の例は、iptables ルールで Cloudflare IP アドレス範囲を許可する方法です。下の $ip を Cloudflare IP アドレス範囲 ↗ の 1 つに置き換えます。そのページに載っている各 IP 範囲に対して、このコマンドを 1 回ずつ実行します。
# For IPv4 addresses
iptables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT
# For IPv6 addresses
ip6tables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPTより具体的な手順は、ホスティングプロバイダーまたはサイト管理者に問い合わせてください。
過去の DNS レコードやメールサーバー設定などでオリジンの IP アドレスが分かると、Cloudflare のセキュリティ保護を迂回して、サーバーへ直接トラフィックを送れます。これを防ぐには、Cloudflare IP アドレス、または信頼できるパートナー、ベンダー、アプリケーションの IP 以外からのトラフィックをすべてブロックします。
たとえば、次のコマンドで iptables を更新 ↗ できます。
# For IPv4 addresses
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP
# For IPv6 addresses
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROPより具体的な手順は、ホスティングプロバイダーまたはサイト管理者に問い合わせてください。
Cloudflare IP アドレスを意図せずブロックしないよう、外部ツールで次を確認してください。
- WordPress 向けなど、セキュリティプラグインが Cloudflare IP アドレスを許可していること。
- ModSecurity ↗ プラグインが最新であること。
オリジンサーバーを守る追加の推奨事項は、オリジンサーバーの保護 ガイドを参照してください。
プロキシされたホスト名が共有する Cloudflare IP アドレスを使いたくない Enterprise のお客様には、次の 2 つの選択肢があります。
- Bring Your Own IP (BYOIP): Cloudflare が、リースまたは所有している IP(IP アドレス範囲)をすべての ロケーション ↗ で広報します。
- 静的 IP アドレス: Cloudflare がドメインに静的 IP アドレスを設定します。詳細はアカウントチームに問い合わせてください。
Business および Enterprise のお客様は、カスタム SSL 証明書をアップロード すると、ドメインが他のお客様のドメインと共有する Cloudflare IP の数を減らせます。
Cloudflare の IP 範囲が変わる頻度は高くありません。変わる場合は、本番投入の前に IP 範囲の一覧 ↗ へ追加されます。Cloudflare API を使い、設定をプログラムで最新に保つこともできます。
Cloudflare は公開エグレス IP 空間として 172.64.0.0/13(172.64.0.0–172.71.255.255)を使います。この範囲は RFC 1918 のプライベート空間ではありません。RFC 1918 が対象とするのは 172.16.0.0/12(172.16.0.0–172.31.255.255)で、172.64.0.0/13 とは重なりません。
AWS VPC のルートテーブルには、Transit Gateway や VPN 接続向けに 172.16.0.0/12(または 172.16.0.0/8 のようなより広いスーパーネット)を含むルートがあることがあります。このルートが Internet Gateway ではなく内部ターゲットを向いていると、Cloudflare の 172.64.x.x トラフィックが Internet Gateway に届く前に取り込まれます。この範囲を使う Cloudflare データセンターから、接続エラー(521、522)が起きます。
解消手順:
- AWS VPC のルートテーブルを確認し、内部ターゲット(Transit Gateway、VPN Gateway、NAT Gateway、VPC ピアリング接続)に向かう
172.x.x.x範囲のルートがないかを調べます。 - 送信先
172.64.0.0/13、ターゲットを Internet Gateway にした、より具体的なルートを追加します。AWS のルーティングでは、より具体的なルートが優先されます。 - または、広いルートを RFC 1918 の範囲である
172.16.0.0/12に絞ります。この範囲には 172.64.0.0/13 は含まれません。
セキュリティグループの監査ではこの問題は見えません。セキュリティグループはルーティング層ではなく、インスタンスレベルで評価されるためです。