トンネルヘルスチェック

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

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

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

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

トンネルヘルスチェックは、Cloudflare からオリジンネットワークへトラフィックを送るトンネルの状態を監視します。Magic Transit は、利用できる最良の経路へトラフィックを振るために、これらのチェックに依存します。オンボーディング時に、Cloudflare のグローバルネットワークから発信するトンネルプローブの対象となる トンネルエンドポイント またはトンネルヘルスチェックターゲットを指定します。

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

エンドポイントヘルスチェックは、Cloudflare の分散データセンターからオリジンネットワークへの接続性を評価します。トンネルヘルスチェックと異なり、エンドポイントプローブは Cloudflare と自ネットワークのあいだのインターネット健全性の全体像を示すためのものです。利用できるトンネルを通りますが、トンネル選択やステアリングの判断には使いません。

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

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

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

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

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

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

双方向プローブは、両方向ともカプセル化されたままです。プローブはトンネル経由で入り、応答もトンネル経由でカプセル化されたまま出ます。自ルーターから Cloudflare ネットワーク上の anycast IP アドレスへ向かう ICMP 応答は、最も近い Cloudflare データセンターに到着し、Equal-Cost Multi-Path（ECMP、等コストマルチパス）でいずれかのサーバーに載ります。これにより、応答は最も効率の良い経路を通ります。

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

デフォルトでは、Cloudflare はこれらのパケットの宛先を、トンネルに設定したインターフェイスアドレスの Cloudflare 側にし、送信元をトンネルのクライアント側にします。たとえばインターフェイスアドレスが 10.100.0.8/31 なら、宛先は 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 範囲を使うレガシーのヘルスチェックシステムをお使いの場合、Cloudflare は次を推奨します。

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

トンネルヘルスチェックプローブの種類は、リクエストとリプライの 2 つです。種類ごとに、送信元と宛先アドレスは方向によって変わります。この設定の変更は トンネルを追加する を参照してください。

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

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

双方向プローブでは、送信元アドレスはトンネルの Cloudflare 側のインターフェイスアドレス（プライベートルーティング可能なアドレス）、宛先はトンネルのインターフェイスアドレス（こちらもプライベートルーティング可能）です。オリジンルーターはプローブを受け取り、送信元と宛先を入れ替えた ICMP 応答を作り、トンネルへ送ります。

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

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

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

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

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

flowchart TB
accTitle: 単方向エコーリクエスト
accDescr: Cloudflare からオリジンへ向かい、戻る単方向エコーリクエストヘルスチェックの流れです。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Request])
   bare_echo_probe --> tunnel[トンネル]
   tunnel --- encapsulated_echo_probe([トンネルプロトコル < ICMP Echo Request >])
   encapsulated_echo_probe --> Internet([インターネット])
   Internet --- encapsulated_echo_probe_2([トンネルプロトコル < ICMP Echo Request >])
   encapsulated_echo_probe_2 --> origin_tunnel(トンネル)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Request])
   received_bare_echo_reply --> origin(オリジン)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([インターネット])
   Internet_2 --> cloudflare

flowchart TB
accTitle: 単方向エコーリプライ
accDescr: Cloudflare からオリジンへ向かい、戻る単方向エコーリプライヘルスチェックの流れです。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[トンネル]
   tunnel --- encapsulated_echo_probe([トンネルプロトコル < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([インターネット])
   Internet --- encapsulated_echo_probe_2([トンネルプロトコル < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(トンネル)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(オリジン)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([インターネット])
   Internet_2 --> cloudflare

自トラフィックを処理するように設定した各 Cloudflare データセンターが、トンネルヘルスチェックプローブを送ります。Cloudflare がプローブを送る頻度は、トンネルと拠点によって変わります。トンネルごとに、API またはダッシュボード で health_check の頻度を変更できます。頻度は low、mid、high のいずれかにでき、デフォルトは mid です。

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

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

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

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

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

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

• 直近 1 秒で少なくとも 3 サンプルのヘルスチェックがすべて失敗すると、Magic Transit はただちにトンネルを健全または劣化からダウンへ移行し、そのトンネルを通るルートに優先度ペナルティを適用します。
• ダウン判定は劣化判定より優先されます。つまり、トンネルの状態はダウン、劣化、健全のいずれか 1 つだけです。

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

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

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

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

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

トンネルがダウン状態になると、グローバルネットワークサーバーは前述の間隔でプローブを出し続けます。プローブが健全に戻ると、健全なパケットを受け取ったグローバルネットワークサーバーはただちにあと 2 回プローブします。その 2 回も健全なら、Magic Transit はトンネル状態を劣化にします（連続 3 回の成功では、ダウン状態の条件を満たさなくなるためです）。

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

Magic Transit のトンネルヘルスチェックは、健全から劣化またはダウンへの移行は速く、劣化またはダウンから健全への移行は遅くします。この動作をヒステリシスと呼び、フラッピングや間欠的なネットワーク障害による経路変更を防ぎます。

2 本のトンネルと、それぞれに紐づくルーティング優先度を考えます。ルート値が小さい方が優先です。

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

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

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

グローバルネットワークサーバーが、この追加 2 回のプローブに対する正しい ICMP 応答パケットを受け取らないと、そのサーバーはトンネル 1 をダウンとラベル付けし、トンネル 1 の優先度を 1,000,100 に下げます。優先度はトンネル 2 へ移り、Magic Transit はそのグローバルネットワークサーバーに到着したパケットをただちにトンネル 2 へ振ります。

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

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

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

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