Cloudflare Accessでホストのドメインを公開せずにZTNAを構築する

Cloudflare Accessでホストのドメインを公開せずにZTNAを構築する

Clock Icon2023.05.01 05:24

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

前回、Cloudflare AccessによるZTNAの実装についてご紹介させていただきました。

今回はZTNAのもうひとつの実装方法として、Private Networkという実装方法をご紹介したいと思います。

Cloudflare Access (Private Network) とは

前回のブログの実装方法はPublic Hostnameという実装になり、今回のご紹介する実装方法はPrivate Networkという実装になります。
Public Hostnameでは、DNSの権威管理をCloudflare上で行い、アクセスするホストのドメインを公開する必要があったのですが、難しい場合もあるかと思います。
Private Networkでは、ホストのドメイン公開することなく、社内リソースをセキュアにアクセスすることができます。

Public HostnameとPrivate Networkの相違点

2つの方式には以下のような相違点があります。

  • Public Hostname
    • DNS権威管理とホストのドメイン公開をCloudflareのDNSサービス上で行う必要があります。
    • エージェント(Warp)を必須としません。(インストールしても良いです)
    • HTTP/HTTPS、SSH、VNCをウェブブラウザを使って接続させることができます。
    • 任意のTCPプロトコルにクライアントにインストールしたCloudflaredを使って接続させることができます。
    • IdPによる認証情報、デバイスポスチャ等による様々なアクセス制御が可能です。
  • Private Network
    • エージェント(Warp)を必須とします。
    • TCP、UDP、ICMPプロトコルを制限なしに接続させることができます。
    • ネットワークレイヤー(IPアドレスとポート)によるアクセス制御に加え、Warpを介して取得できる情報(IdPの認証やデバイスポスチャ)によるアクセス制御が可能です。
    • アクセス先のリソースであるプライベートIPアドレスをSplit TunnelルールによってIncludeする必要があります。(=Cloudflareに通す必要がある)

この2つの実装方式は併用することも可能です。エージェントをインストールできない環境からのアクセスはPublic Hostnameで、エージェントをインストールできる環境からのUDPやICMP等のプロトコルにアクセスしたい場合はPrivate Networkでというようなかたちです。

やってみる

アーキテクチャイメージ

今回構築するアーキテクチャは以下のようになります。

Cloudflaredトンネルの設定

コネクタからCloudflareに張るトンネル設定から行います。

もし、既に作成したトンネルを使う場合は、既存のトンネル設定を編集してください。コネクタ側のCloudfalredインストールもしている場合もその手順もスキップします。

コネクタの環境に合わせたインストール手順に従い、インスタンスにログインしてCloudflaredのインストールを完了させます。

Amazon Linuxの場合は以下のように設定していきます。

curl -L --output cloudflared.rpm https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm && 

sudo yum localinstall -y cloudflared.rpm && 

sudo cloudflared service install {install token}

アプリケーションの設定

ブログ用アプリケーションを作成します。
Private NetworkのタブでアクセスさせたいプライベートネットワークのIPアドレスレンジを追加します。

ApplicationsでPrivate Networkのアプリケーションを作成します。

アクセス先のプライベートIPアドレスを入力します。

アクセス制御はグループではなく、Private Network用のポリシーを作成して制御します。この設定は、GatewayのNetwork Firewall Policiesの中に作られますが、通常のNetwork Firewall Policyと違い、IPアドレスとポートによる制限に加え、Warp経由でアクセス時に送られるIdPの情報やデバイスポスチャの条件を加えることができます。

続いてSSH用アプリケーションも作成しますが、同様の手順です。

エージェントWarpのインストール

Warpをクライアント端末にインストールしていない場合はインストールします。

Split Tunnelの設定

通常、RFC 1918で定められているプライベートIPアドレス空間は、Cloudflareにトラフィックを通す必要がないので、Split Tunnelの設定でCloudflareに通す通信の対象から除外します。
Warpでもインストール後デフォルトでプライベートIPアドレスといくつかのCloudflareに関係するIPアドレスとの通信が除外される設定が入っています。
しかし、Private Networkでは、VPN技術と同じようにプライベートIPアドレス空間と仮想的にやり取りを行うようになるため、通信を除外するではなく、Cloudflareへのトラフィックに含める必要があります。
そのため、接続したいPrivate NetworkのIPアドレスをSplit Tunnelの通信除外設定から外してあげる必要があります。
今回は、172.16.0.0/16を除外設定から外してあげます。

アクセスしてみる

WarpのインストールとWarpのレジストレーションが完了した端末からアクセスします。
ウェブブラウザを開いて、ブログ用アプリのプライベートIPと接続ポートでアクセスします。
http://172.31.7.192:1313

アクセスの裏でWarpで通した認証情報を使ってアクセスできます。

続いて、SSHクライアントソフト等を使ってSSH用アプリのプライベートIPと接続ポートでアクセスしてみます。

こちらもアクセスの裏でWarpで通した認証情報をアクセス条件として判定されています。もし、Warp認証の時の認証情報がアクセス条件を満たしていない場合はSSHの認証画面が表示されません。
SSHの認証のためのユーザー名とパスワードなどを入力して、認証が通るとアクセスできます。

まとめ

このようにPrivate Networkによる実装方法をとることで、ホストのドメインを公開せずにZTNAを実装することが可能となります。Warpをインストールできない環境からアクセスさせたい場合はPublic Hostnameで実装する必要がありますが、そうでない場合は、Private Networkによる実装による利点は非常に大きいと感じました。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.