WARP で Local Domain Fallback と Split Tunnel を試してみる

ユーザー端末のゼロトラスト化を進める中で、必須となるSWGやZTNAを運用する際、どうしても経路除外をする必要ケースも出てきます。Local Domain Fallback、Split Tunnelsの使い所や動作について説明します。

#Cloudflare Zero Trust

#Cloudflare

#WARP

#ゼロトラスト

#SASE

酒井剛

2023.06.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Cloudflare Zero Trust の WARP をPCにインストールすると、自動的に通信は最寄りの Cloudflare のエッジに到達し、Cloudflare Gateway や Cloudflare Access の機能を通って目標の宛先へトラフィックが届けられます。

しかし、目標宛先のサービスや運用の特性上、Cloudflare のプラットフォームを迂回させて通信させる必要のあるトラフィックが出てくることもあるかと思います。

そこで今回は、「Local Domain Fallback」と「Split Tunnel」によって通信を制御するユースケースとその動きを試してみたいと思います。

そもそも基本的なこと

インターネット通信の基本ではありますが、宛先と通信する際にインターネット上の住所（宛先）として「www.example.com」のようなドメインが使われます。
まずドメインの名前解決をした後、得られたIPアドレスに対して通信が接続されます。

Local Domain Fallback

Cloudflare Zero Trust では、世界最速かつDNS over HTTPSやDNSフィルタリングなどの機能を有したパブリックDNSリゾルバを提供します。
WARP を有効にすることにより、ドメインの名前解決のためのDNSクエリを Cloudflare に要求するようになります。
Local Domain Fallback は、特定のドメインの名前解決を Cloudflare ではなく、他のDNSリゾルバに向けて要求する必要がある場合に利用されます。

例えば、社内イントラのリソースへ通信する際、それらのドメインはパブリックに公開されておらずイントラサーバーで提供している場合、DNSクエリを Cloudflare ではなくイントラサーバーへ向けるのに Local Domain Fallback を使います。

全体的な通信の中で考えると Local Domain Fallback が制御する範囲は下図のようになります。

Split Tunnel

Split Tunnel は名前解決の結果、IPアドレスを取得した後、実際の宛先との通信の際に Cloudflare を経由しないように制御します。Split Tunnel によって除外された通信は、既存のISP網を経由するようになります。

Split Tunnel を利用するケースとしては、送信元IPアドレスを制限しているサービスへアクセスする際に、契約しているISP事業者が払い出すIPアドレス（拠点IPなど）に固定したい場合です。
こちらの解決策としてはその他に、Cloudflare では Dedicated egress IPs というサービスが提供されているので、そちらの利用も可能です。

その他のユースケースでは、WARP とは別のVPNサービスを並用している場合です。通信を制御する機能がバッティングしてしまうため、Split Tunnel の設定でVPNの通信については除外が必要です。その他にも注意点がありますので、実際にVPNと並用する際はこちらを確認してください。

他にも社内リソースやプライベートIPアドレスとの通信においても Split Tunnel で除外対象とします。Split Tunnel 設定はIncludeモードとExcludeモードがあるので、デフォルトのExcludeモードの場合は、これらのIPアドレスも対象とします。
※Excludeモードは、Split Tunnel で設定したものだけが、Cloudflare 経由を除外するモードです。
※Includeモードは、Split Tunnel で設定したものだけが、Cloudflare 経由となるモードです。

証明書ピニング（Certification Pinning）やPythonやnpmで独自の証明書を参照していることで通信できない場合には、TLS復号機能のバイパスするルールを作成する（Do Not Inspectルール）、またはアプリケーションが Cloudflare のroot証明書を参照できるように設定することで解決が可能なので Split Tunnel の設定は非推奨となります。

全体的な通信の中で考えると Split Tunnels が制御する範囲は下図のようになります。

Local Domain Fallback の動作確認

準備

「www.example.com」というドメインにプライベートIPアドレスを返すDNSサーバーを社内LANにたてます。
zoneファイルはこのような感じで用意しています。

$ORIGIN example.com.
$TTL 43200
@    IN SOA ns1.example.com. root.example.com.(
     2015072501 ;Serial
     10800 ;Refresh
     10800 ;Retry
     86400 ;Expire
     3600 ;Minimum
)

example.com. IN NS ns1.example.com.
ns1                 IN A  192.168.10.104
proxy               IN A  192.168.100.2
main                IN A  192.168.100.3
www                 IN A  192.168.100.4
esxi                IN A  192.168.24.60

また、このDNSサーバーは「192.168.10.104」のIPアドレスを持たせています。

それでは、Cloudflare Zero Trust の設定をします。
Settings > WARP Client で設定するWARPのプロファイルを選択します。

Local Domain Fallback を選択します。

Local Domain Fallbackするドメイン（ここではwww.example.com）、DNSサーバーのIPアドレス（192.168.10.104）を入力して、保存します。

動作確認

WARP をインストールしたWindows端末で Local Domain Fallback の動作を確認していきます。
まず「www.example.com」の名前解決をします。

C:\Users\sakai.takeshi>nslookup www.example.com
サーバー:  warp-svc
Address:  fd01:db8:1111::2

権限のない回答:
名前:    www.example.com
Address:  192.168.100.4

先程、インターナルに用意したDNSサーバーのzoneファイルに記載したレコード（プライベートIPアドレス）を返しています。

続いて、Local Domain Fallback の設定には記載しなかった、「www.example.com」の親ドメインである「example.com」の名前解決を試してみます。

C:\Users\sakai.takeshi>nslookup example.com
サーバー:  warp-svc
Address:  fd01:db8:1111::2

権限のない回答:
名前:    example.com
Addresses:  2606:2800:220:1:248:1893:25c8:1946
          93.184.216.34

こちらは、Local Domain Fallback の設定には記載されていなかったので、グローバルで名前解決されるIPアドレスが返されています。つまり、Cloudflare の DNSリゾルバーが名前解決を行っています。

Split Tunnel の動作確認

準備

Split Tunnel はIPベースとドメインベースで設定が可能です。
IPベースは当然指定したIPへの通信を Cloudflare を経由せずに通信させる動きとなります。
一方ドメインベースはドメインが名前解決によって返されたIPアドレスを動的に解釈して、それらのIPアドレスへの通信を Cloudflare を経由せずに通信させる動きとなります。

どちらも確認してみましょう。

前置きであったユースケースのように、送信元IPアドレスを制限しているサービスを利用するために、Cloudflare の送信元IPアドレスではなく、拠点IPを送信元IPとして接続するケースを確認していきます。

確認のために、送信元IPアドレスを調べるWebサイトを使います。こういったサイトはいくつかありますので、３つの別々のサイトにそれぞれ「Split Tunnelの設定をしない」、「IPアドレスベースでSplit Tunnelの設定をする」、「ドメインベースでSplit Tunnelの設定をする」のようにして、動作の違いを確認していきます。

以下の３サイトを選定しました。

送信元IPアドレスを調べるサイト	Split Tunnelの設定内容
CMAN	Split Tunnelの設定をしない
UGTOP	IPアドレスベースでSplit Tunnelの設定をする
NORDVPN	ドメインベースでSplit Tunnelの設定をする

UGTOP はIPアドレス指定で Split Tunnel の設定をするので、事前に名前解決した時のIPアドレスを調べておきます。NORDVPN はドメインベースですが、こちらのIPアドレスも確認しておきます。

dig www.ugtop.com +short
ugtop.com.
219.94.129.26

dig nordvpn.com +short
104.17.49.74
104.17.50.74

Cloudflare Zero Trust で Split Tunnel の設定を行っていきます。
先程の Local Domain Fallback と同じで Settings > WARP Client で設定するWARPのプロファイルを選択し、Split Tunnels を選択します。

UGTOP はIPアドレスで登録をします。

NORDVPN はドメインで登録をします。

動作確認

それでは用意ができましたので、Split Tunnel の動作を確認してみます。
WARP をインストールしたWindows端末で検証していきます。

特に Split Tunnel の設定をしていなかったCMANにアクセスします。

「104.16.0.0/12」は Cloudflare のIPアドレスレンジなので、Cloudflare を経由したことが分かります。

IPベースで Split Tunnel の設定をしたUGTOPにアクセスします。

「133.206.0.0/16」は私の契約しているインターネット回線の BIGLOBE のIPアドレスレンジになります。Cloudflare は経由せず、既存のISP網を抜けていっていることが分かります。

最後にドメインベースで Split Tunnel の設定をしたNORDVPNにアクセスします。

こちらも同様に「133.206.0.0/16」は私の契約しているインターネット回線の BIGLOBE のIPアドレスレンジになるので、Cloudflare は経由せず、既存のISP網を抜けていっていることが分かります。

まとめ

Local Domain Fallback と Split Tunnel の利用ケースのまとめと、動作確認を行ってみました。
名前解決および宛先への接続の際に Cloudflare を経由させることで、フィルタリング・ウィルススキャン・CASBスキャン・DLPなどなどによるセキュリティの強化やログの一元集約といった利点があるので、極力除外させたくないですが、制約上どうしても Local Domain Fallback と Split Tunnel を使う必要が出てくることはあるかもしれません。
SSE製品を導入する際に本記事が参考になれば幸いです。