トンネルヘルスチェック

Cloudflare は、ネットワークを Cloudflare に接続する各トンネルが到達可能で良好に動作しているかを継続的に監視します。トンネルが不健全になると、手動操作なしで、Cloudflare はトラフィックを別の経路へ自動的にステアリングします。この監視は、トンネルヘルスチェックのプローブに依存します。

トンネルヘルスチェックのプローブは、テスト対象トンネルのプロトコルでカプセル化した ICMP（Internet Control Message Protocol） ↗ ペイロードです。たとえばトンネルが Internet Protocol Security（IPsec）トンネルなら、ICMP パケット ↗ は、そのトンネルの Encapsulating Security Payload（ESP）パケット内で暗号化されます。

トンネルヘルスチェックのプローブは Cloudflare からトンネルオリジンへ向かい、応答が Cloudflare に戻ります。Cloudflare はこの応答を使ってプローブ結果を判定し、トンネル状態を算出します（詳細は以降のセクションで説明します）。

Cloudflare WAN は 2 種類のヘルスチェックを使います。

トンネルヘルスチェックは、Cloudflare からオリジンネットワークへトラフィックをルーティングするトンネルの状態を監視します。Cloudflare WAN は、これらのチェックに基づいて最適な経路へトラフィックをステアリングします。オンボーディング時に、Cloudflare のグローバルネットワークから発信するトンネルプローブが対象とする トンネルエンドポイント またはトンネルヘルスチェックターゲットを指定します。

トンネルヘルスチェックの結果は API 経由 で確認できます。Cloudflare は、Cloudflare サーバーからの個別のヘルスチェック結果を集約します。

エンドポイントヘルスチェックは、Cloudflare の分散データセンターからオリジンネットワークへの接続性を評価します。トンネルヘルスチェックとは異なり、エンドポイントプローブは Cloudflare とお客様ネットワークのあいだのインターネット健全性の大局を示すためのものです。利用可能なトンネル上を流れますが、トンネル選択やステアリングロジックには使いません。

Cloudflare グローバルネットワークのサーバーは、お客様ネットワークの名前空間の外でエンドポイントヘルスチェックを発行し、通常はトンネル終端の境界ルーターより先のエンドポイントを対象にします。オンボーディング時に、エンドポイントヘルスチェックを設定する IP アドレスを指定します。

トンネルヘルスチェックのプローブには、次の属性があります。

トンネルヘルスチェックのプローブは、トンネル経由で特定のアドレスまたはエンドポイントに Cloudflare が接続できるかをテストします。ターゲットは、到達可能であることを確認したいアドレスです。任意で、既定値はヘルスチェックの方向によって異なります（詳細は 方向 を参照してください）。

トンネルヘルスチェックのプローブには、単方向と双方向の 2 つの方向があります。

単方向ヘルスチェックのプローブは、一方向ではカプセル化されたまま、トンネル経由でオリジンに入ります（Cloudflare からオリジンへ）。応答はカプセル化されずに Cloudflare に戻り、標準のインターネット ルーティング ↗ に従ってトンネル外を進みます。

ターゲットの既定は、トンネルに customer_endpoint として指定した、パブリックにルーティング可能なオリジンです。ない場合は、カスタムターゲットを使えます。

双方向プローブは、両方向でカプセル化されたままです。プローブはトンネル経由で入り、応答もトンネル経由でカプセル化されたまま出ていきます。Cloudflare ネットワーク上の anycast IP アドレス宛てにルーターが出す ICMP 応答は、最も近い Cloudflare データセンターに到着し、Equal-Cost Multi-Path（ECMP）を使うサーバーのいずれかに着地します。応答は最も効率的な経路を取ります。

既定のパケットアドレス指定

既定では、Cloudflare はこれらのパケットの宛先を、トンネルに設定したインターフェースアドレスの Cloudflare 側にし、送信元をトンネルのクライアント側にします。たとえばインターフェースアドレスが 10.100.0.8/31 なら、Cloudflare は宛先を 10.100.0.9、送信元を 10.100.0.8 にします。

インターフェースアドレスの範囲

インターフェースアドレスフィールドは、/30 または /31 の CIDR 範囲を使います。

• /31 範囲: 指定した IP が Cloudflare 側で、もう一方の IP がクライアント側です。たとえばインターフェースアドレスが 10.100.0.8/31 なら、10.100.0.8 が Cloudflare 側、10.100.0.9 がクライアント側です。
• /30 範囲: 指定した IP が Cloudflare 側で、ブロードキャストとネットワーク識別子を除いたもう一方の IP がクライアント側です。たとえばインターフェースアドレスが 10.100.0.9/30 なら、10.100.0.9 が Cloudflare 側、10.100.0.10 がクライアント側です。

公開のカスタムターゲットを指定して双方向ヘルスチェックを設定することもできます。Azure Active Standby トンネル構成では、この方法を推奨します。

これらのパケットは、設定済みのトンネルを通って Cloudflare とのあいだを流れ、Cloudflare ネットワークと各サイトのあいだのトラフィック経路を完全に把握できます。IPsec トンネルでは、ヘルスチェックパケットを受け入れるトラフィックセレクターを設定する必要があります。

双方向または単方向のヘルスチェックの設定方法は、トンネルを追加する を参照してください。

公開 IP 範囲を使うレガシーヘルスチェックシステムをお使いのお客様には、次を推奨します。

• トンネルヘルスチェックのターゲット IP アドレスを、172.64.240.252/30 プレフィックス範囲内のいずれかに設定する。
• 送信元 IP アドレスが設定済みトンネルヘルスチェックターゲット（例: 172.64.240.253/32）と一致するパケットにマッチし、それらをトンネル経由で Cloudflare に戻すポリシーベースルートを適用する。

トンネルヘルスチェックのプローブには、request と reply の 2 種類があります。種類ごとに、送信元アドレスと宛先アドレスは方向に依存します。この設定の変更方法は、トンネルを追加する を参照してください。

request スタイルのヘルスチェックでは、ペイロードプローブは ICMP request です。

単方向プローブでは、送信元アドレスはトンネルの Cloudflare 側（パブリックにルーティング可能なアドレス）で、宛先はオリジンルーター（同じくパブリックにルーティング可能）です。オリジンルーターはプローブを受け取り、送信元と宛先を逆にした ICMP 応答を作り、トンネル外へ送ります。

双方向プローブでは、送信元アドレスはトンネルの Cloudflare 側インターフェースアドレス（プライベートにルーティング可能なアドレス）で、宛先はトンネルのインターフェースアドレス（同じくプライベートにルーティング可能）です。オリジンルーターはプローブを受け取り、送信元と宛先を逆にした ICMP 応答を作り、トンネル内へ送ります。

reply スタイルのヘルスチェックでは、ペイロードプローブは ICMP 応答です。

単方向プローブでは、宛先アドレスはトンネルの Cloudflare 側（パブリックにルーティング可能なアドレス）で、送信元はオリジンルーター（同じくパブリックにルーティング可能）です。オリジンルーターはプローブを受け取り、変更せずに応答としてトンネル外へ送り返します。

双方向プローブでは、宛先アドレスはトンネルの Cloudflare 側インターフェースアドレス（プライベートにルーティング可能なアドレス）で、送信元はトンネルのインターフェースアドレス（同じくプライベートにルーティング可能）です。オリジンルーターはプローブパケットを受け取り、宛先がトンネル経由でルーティングされるため、変更せずに応答としてトンネル内へ送り返します。

flowchart TB
accTitle: 双方向 request スタイル
accDescr: Cloudflare とオリジンのあいだの、双方向 request スタイルのトンネルヘルスチェックプローブと応答の流れを示します。
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_request([ICMP Echo Request])
   bare_echo_request --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_request([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request --> Internet([Internet])
   Internet --- encapsulated_echo_request_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_request([ICMP Echo Request])
   received_bare_echo_request --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: 双方向 reply スタイル
accDescr: Cloudflare とオリジンのあいだの、双方向 reply スタイルのトンネルヘルスチェックプローブと応答の流れを示します。
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: 単方向 echo request
accDescr: Cloudflare からオリジンへ向かい戻る、単方向 echo request ヘルスチェックの流れを示します。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Request])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Request])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

flowchart TB
accTitle: 単方向 echo reply
accDescr: Cloudflare からオリジンへ向かい戻る、単方向 echo reply ヘルスチェックの流れを示します。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

お客様のトラフィックを処理するよう設定された各 Cloudflare データセンターが、トンネルヘルスチェックのプローブを送ります。Cloudflare がこれらのプローブを送る頻度は、トンネルと場所によって異なります。この頻度は、API またはダッシュボード で health_check の rate を変更し、トンネルごとに調整できます。rate は low、mid、high に設定でき、既定は mid です。

実際の頻度の計算では、Cloudflare データセンター内のサーバー数、または動的にプロビジョニングされる名前空間では、お客様名前空間がプロビジョニングされたサーバー数を考慮します。頻度は動的で、Cloudflare ネットワークの規模に依存します。

健全なトンネル でプローブ試行が失敗すると、失敗を検出した各サーバーは正確な結果を得るため、すぐに最大 2 回追加でプローブします。トンネルがダウンしており、プローブが成功を返し始めた場合も同様です。Cloudflare グローバルネットワークのサーバーは最大で 1 秒ごとにプローブを送るため、ネットワークは毎秒数百のヘルスチェックパケットを受信します。各 Cloudflare データセンターは、プローブの一部としてヘルスチェックパケットを 1 つだけ送ります。トラフィック量としては比較的わずかです。

トンネルの健全性状態は、正常、劣化、ダウンの 3 つです。

正常なトンネルは劣化したトンネルより優先され、劣化したトンネルはダウンしたトンネルより優先されます。

Cloudflare WAN は、オンボーディング時にトンネルルートの優先度を割り当てた ときに設定した優先度に基づいて、トラフィックをトンネルへステアリングします。値が小さいトンネルルートが、値が大きいルートより優先されます。

• 直近 5 分間のトンネルヘルスチェックの少なくとも 0.1% が失敗し（失敗は少なくとも 2 回）、トンネルがダウンでない場合、Cloudflare WAN はそのリンクを損失ありとみなし、トンネル状態を劣化にします。
• Cloudflare WAN が失敗を 2 回必要とするのは、パケット 1 つの損失だけでペナルティが発動しないようにするためです。
• その後 Cloudflare WAN は、トンネルステータスをただちに劣化にし、優先度ペナルティを適用します。

• 直近 1 秒間の少なくとも 3 サンプルのヘルスチェックがすべて失敗すると、Cloudflare WAN はトンネルを正常または劣化からただちにダウンへ遷移させ、そのトンネル経由のルートに優先度ペナルティを適用します。
• ダウン状態の判定は、劣化状態の判定より優先されます。つまり、トンネルはダウン、劣化、正常のいずれか 1 つにしかなりません。

Cloudflare WAN が健全でないルートを特定すると、次のペナルティを適用します。

• 劣化: 優先度に 500,000 を加算します。
• ダウン: 優先度に 1,000,000 を加算します。

失敗ペナルティの値は意図的に極端で、ルーティング設定 時に割り当てた優先度の値を常に上回ります。

ルートを完全に削除する代わりにペナルティを適用することで、冗長性を保ち、トンネルが 1 本だけのお客様向けの選択肢も残します。ペナルティは、複数トンネルが不健全な場合にも対応します。

Cloudflare データセンターがダウンした場合、Cloudflare のグローバルネットワークはお客様のプレフィックスをアドバタイズせず、パケットを次に近いデータセンターへルーティングします。Cloudflare のグローバルネットワークとダッシュボードのシステムステータスは、Cloudflare System Status ↗ を参照してください。

トンネルがダウン状態になると、グローバルネットワークサーバーは前述の間隔でプローブを出し続けます。プローブが正常を返すと、正常なパケットを受信したグローバルネットワークサーバーは、ただちにさらに 2 回プローブします。2 回のプローブが正常を返すと、Cloudflare WAN はトンネルステータスを劣化にします（連続 3 回の成功プローブでは、ダウン状態の条件を満たさなくなるためです）。

劣化状態のトンネルは、直近 30 回のプローブの失敗率が 0.1% 未満になると正常へ遷移します。この遷移には最大 30 分かかることがあります。

Cloudflare WAN のトンネルヘルスチェックシステムは、トンネルを正常から劣化またはダウンへすばやく遷移させ、劣化またはダウンから正常へはゆっくり遷移させます。この動作をヒステリシスと呼び、フラッピングや間欠的なネットワーク障害によるルーティング変更を防ぎます。

2 本のトンネルと、関連するルーティング優先度を考えます。ルート値が小さい方が優先されます。

• トンネル 1、ルート優先度 100
• トンネル 2、ルート優先度 200

両方のトンネルが正常なとき、ルーティング優先度はトラフィックをトンネル 1 だけに向けます。ルート優先度 100 がトンネル 2 より優先されるためです。トンネル 2 は、トンネルヘルスチェックのプローブ以外のトラフィックを受け取りません。エンドポイントヘルスチェックは、トンネル 1 経由でのみオリジンネットワーク内の宛先へ流れます。

トンネル 1 と Cloudflare のあいだのリンクが使えなくなると、Cloudflare グローバルネットワークのサーバーは次のヘルスチェックプローブで障害を検出し、ただちにさらに 2 回プローブします（トンネルが当初正常だった場合）。

グローバルネットワークサーバーが、これら追加 2 回のプローブから適切な ICMP 応答パケットを受信できないと、そのサーバーはトンネル 1 をダウンとラベル付けし、トンネル 1 の優先度を 1,000,100 に下げます。優先度はトンネル 2 へ移り、Cloudflare WAN はそのグローバルネットワークサーバーに到着するパケットをただちにトンネル 2 へステアリングします。

トンネル 1 をダウンにした接続問題が解消されたとします。次のヘルスチェック間隔で、発行元のグローバルネットワークサーバーは成功したプローブを受信し、トンネル健全性を検証するためただちにさらに 2 回プローブします。

3 回のプローブがすべて成功すると、Cloudflare WAN はトンネルをダウンから劣化へ遷移させます。この遷移の一環として、そのルートの優先度ペナルティを減らし、優先度は 500,100 になります。トンネル 2 の優先度は 200 のため、トラフィックはトンネル 2 を流れ続けます。

グローバルネットワークサーバーはトンネル 1 のプローブを続けます。5 分間のヘルスチェック失敗率が 0.1% を下回ると、Cloudflare WAN はトンネルステータスを正常にします。Cloudflare はトンネル 1 のルーティング優先度を 100 に完全に戻し、トラフィックステアリングはデータフローをトンネル 1 に戻します。

トンネル健全性の問題の切り分けは、トンネル健全性のトラブルシューティング を参照してください。