トンネルヘルスチェック

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 アドレスを指定します。

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

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

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

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

ターゲットのデフォルトは、トンネルに customer_endpoint として指定された、パブリックにルーティング可能なオリジンです（存在する場合）。それ以外では、カスタムターゲットを使えます。

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

デフォルトのパケットアドレス指定

デフォルトでは、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 トンネルでは、ヘルスチェックパケットを受け入れるトラフィックセレクターを設定する必要があります。

双方向または単方向のヘルスチェックの設定方法は Add tunnels を参照してください。

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

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

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

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

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

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

reply 形式のヘルスチェックでは、ペイロードプローブは ICMP response です。

単方向プローブでは、宛先アドレスはトンネルの 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 のレートを変更して調整できます。レートは low、mid、high に設定でき、デフォルトは mid です。

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

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

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

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

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

• 直近 5 分間のトンネルヘルスチェックのうち少なくとも 0.1% が失敗し（かつ失敗が少なくとも 2 回）、トンネルがダウンでない場合、Cloudflare WAN はそのリンクをロスありとみなし、トンネル状態を劣化にします。
• パケット 1 つだけの損失でペナルティが付かないよう、Cloudflare WAN は失敗を 2 回必要とします。
• その後 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 に戻します。

トンネルヘルスの問題の解決方法は トンネルヘルスのトラブルシューティング を参照してください。