対処の候補:
- Magic Transit プレフィックスから、インターネット上の宛先 IP へ traceroute を実行します。
- CPE で、このトラフィックを破棄する uRPF の strict モードやアンチスプーフィングが有効になっていないかを確認します。
- CPE が uRPF の strict モードや、このトラフィックを破棄するほかのアンチスプーフィング機構を強制していないかを確認します。強制している場合は、loose モードへの変更を依頼します。
- そのほかの回避策:
- より広い（less-specific）プレフィックスがある場合は、Cloudflare がより狭い（more-specific）プレフィックスを広告しているあいだ、その広いプレフィックスを ISP へ広告し続けられます。たとえば、Cloudflare がインターネットへ
/24を広告し、その親の/23を ISP へ広告します。 - ISP へ
/24を広告し続けることもできますが、推奨しません。ISP からの inbound トラフィックが Cloudflare を迂回し、Magic Transit の DDoS 保護の対象外になるためです。
- より広い（less-specific）プレフィックスがある場合は、Cloudflare がより狭い（more-specific）プレフィックスを広告しているあいだ、その広いプレフィックスを ISP へ広告し続けられます。たとえば、Cloudflare がインターネットへ
対処の候補:
- Magic Transit プレフィックスを設定している拠点の、すべての CPE egress ポートに MSS クランプが設定されていることを確認します。
- トラフィックフローの両端でパケットをキャプチャし、TCP SYN-ACK で広告されている MSS 値を確認します。たとえば、リモート側のインターネット IP と、自社の Magic Transit 機器で取得します。
- 問題が MTU または MSS の設定に関係するかを素早く確認するには、Magic Transit プレフィックス内のテスト機器の LAN インターフェースで、MSS クランプを一時的に下げます。これで解消する場合は、プレフィックス向けの MSS クランプを調整する必要があることが分かります。エッジ CPE のすべての egress インターフェースに、正しい MSS クランプが適用されていることも確認してください。
たとえば、Magic Transit プレフィックス上にホストされているサーバーを、ブラウザーで開けない場合です。
対処の候補:
- Magic Transit プレフィックスを設定している拠点の、すべての CPE egress ポートに MSS クランプが設定されていることを確認します。
- トラフィックフローの両端でパケットをキャプチャし、TCP SYN-ACK で広告されている MSS 値を確認します。たとえば、リモート側のインターネット IP と、自社の Magic Transit 機器で取得します。
- 問題が MTU または MSS の設定に関係するかを素早く確認するには、Magic Transit プレフィックス内のテスト機器の LAN インターフェースで、MSS クランプを一時的に下げます。これで解消する場合は、プレフィックス向けの MSS クランプを調整する必要があることが分かります。エッジ CPE のすべての egress インターフェースに、正しい MSS クランプが適用されていることも確認してください。
対処の候補:
- IPsec/GRE トンネルを通過するトラフィックに、MSS クランプが正しく適用されていることを確認します。トンネルの両端でパケットキャプチャを行い、TCP SYN-ACK で広告されている MSS 値を調べます。
- Magic Transit プレフィックスに接続しているファイアウォールの、IPsec 内部トンネルインターフェースの MSS 設定を確認します。Magic Transit の GRE トンネル（MTU 1476 バイト）を通過する inbound パケットの断片化を避けるため、おおよそ 1300 バイトに設定します。GRE トンネルでは、GRE カプセル化のオーバーヘッドを考慮し、元の値から 24 バイトを引いて MSS を調整します。
- これでも解決しない場合は、Cloudflare に連絡し、問題が起きているプレフィックス上の特定のエンドポイント IP に対して
clear don't fragmentビットを有効にしてもらい、解消するかを確認します。
Cloudflare の緩和機能が、Magic Transit プレフィックス宛ての正当なトラフィックを破棄していると思われる場合は、次の手順を行います。
- Network analytics ページを開きます。
- All traffic タブで Add filter を選び、対象のトラフィックフロー向けにフィルターを設定します。送信元 IP、宛先 IP、プロトコル/ポートなどです。
- 分析結果を確認し、どの Cloudflare の緩和システムがトラフィックを破棄したかを特定します。たとえば、DDoS Managed Rules、Advanced TCP/DNS Protection、Network Firewall です。
- DDoS Managed Rules が破棄した場合:
- 破棄したルールがカスタマイズ可能かを確認します。可能な場合は DDoS Overrides を開きます。そこで、このエンドポイント IP をオーバーライドに追加し、感度を下げて適用する新規または既存のオーバーライドを作成／修正できます。
- ルールがカスタマイズできず、Cloudflare の常時有効な標準 DDoS 緩和の一部である場合は、Cloudflare サポートチームに連絡して支援を依頼します。
- Advanced TCP Protection（ATP）が破棄した場合:
- グローバルルールのモードが Mitigation のときは、
monitoring向けのフィルターを設定すると、ATP はこのトラフィックフローを破棄しなくなります。 - さらに支援が必要な場合は、Cloudflare サポートチームに連絡してください。この緩和システムのバックエンド設定を調整できます。
- グローバルルールのモードが Mitigation のときは、
- Advanced DNS Protection が破棄した場合:
- 特定のリージョンまたはデータセンターで受信したトラフィックに、より低い感度を適用するルールを作成できます。作成後、ルールのモードを
monitoringに変更できます。 - または、グローバルルールのモードを
mitigationからmonitoringに変更できます。
- 特定のリージョンまたはデータセンターで受信したトラフィックに、より低い感度を適用するルールを作成できます。作成後、ルールのモードを
- Network Firewall が破棄した場合:
- 破棄の原因となった Network Firewall ルールを確認します。
- ルールを編集するか、無効にできます。トラフィックを許可する新しいルールを追加し、破棄するルールより上に配置することもできます。
対処の候補:
- Cloudflare Magic Transit のリース IP を使っている場合は、CPE が Cloudflare のリース IP へ正しく NAT しており、egress トラフィックを Magic Transit の IPsec/GRE トンネル経由で転送するポリシーベースルーティングが正しく設定されていることを確認します。
- Network Firewall ルールが egress トラフィックを許可しているかを確認します。Network Firewall はステートレスであり、設定したルールは ingress と egress の両方に適用されます。
- Network Analytics で egress トラフィックフローが見えるかを確認します。Magic Transit プレフィックスへ戻る inbound トラフィックフローも確認します。トラフィックに緩和が適用されていないかも確認します。
問題が TCP だけに現れ、UDP/ICMP は成功する場合は、CPE の GRE/IPsec トンネル上の MSS と MTU の設定を確認します。CPE またはエンド機器でパケットキャプチャを行い、交換された SYN-ACK の値を確認します。