Cloudflare Magic WAN ヘルスチェックが全然上がらないとき

概要

クラウド環境で、Magic WAN のトンネルヘルスチェックの折返しが帰ってこず、ヘルスチェックがダウン判定になることがありました。
こちらのケースもありますが、今回はちょっと違って CPE 発の「いきなり ICMP Echo Reply」を、クラウド出口のファイアウォールが通してくれなさそうです。

二番目の矢印を誰かがポリシーで落としてる。

CPE は顧客側の IPsec 終端装置

ヘルスチェックのパケット

From	To	Type	モニターが期待する動作
CPEのIP	Cloudflare_各DCの自分IP	ICMP Echo Reply	折返えされて自分に戻ってくる

課題

場合によっては、折返しのパケットが途中のルータのポリシーで破棄されることがあります。
そのあたりのポリシーをユーザではなんともできないことがあります。

対策

• ヘルスチェックへの折返しもトンネルを通すようにする
  • ヘルスチェックの送信元は CPE のIP ではなく、Cloudflare 指定の 172.64.240.252/30 から選ぶ
  • CPE では「送信元が 172.64.240.252/30 の場合、トンネルインターフェースに転送」と書く
• そもそも、Cloudflare の 各IP をトンネルインターフェースにルーティングできれば良さげですが、IP 公開もないので、この対応

ヘルスチェックのパケット

From	To	Type	モニターが期待する動作
172.64.240.253 or 254	Cloudflare_各DCの自分IP	ICMP Echo Reply	折返えされて自分に戻ってくる

折返しもトンネル（vti1）を通り、経路中で破棄されることがなくなりました。

設定の一例

sudo ip route flush table 1000
sudo ip rule add from 172.64.240.252/30 table 1000 prio 100
sudo ip route add default dev vti1 table 1000

キャプチャ（トンネルインタフェースに折返し、TTLが一つ減る）

Capturing on 'vti1'
    1 0.000000000 172.64.240.254 → <CF_IP> ICMP 84 Echo (ping) reply    id=0x0b63, seq=0/0, ttl=64
    2 0.000051618 172.64.240.254 → <CF_IP> ICMP 84 Echo (ping) reply    id=0x0b63, seq=0/0, ttl=63

その他の方法

他にヘルスチェックの折返しをトンネルに流す方はいくつかありそうですが、柔軟さでは上記が良さげです。

その他だと

• トンネルが上がったら、デフォルトルートをトンネル側に優先度の高めで切って、トンネルから除外したいもの（デバイスへのSSHとか）は個別にスタティックで物理に放る、というスクリプト
• 受信したICMPパケットは転送表を無視して、受信したインタフェースに折り返す、という機能

あたりでしょうか。

一方、折返しをトンネルに流さず、ヘルスチェックのタイプを ICMP Echo にするというのもありますが、この場合は中間のファイアウォールなどでセッションなどが作られ、無駄に Echo Reply を待つ、というような弊害も考えられます。

本家の解説