この記事は公開されてから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に通す必要がある）
この２つの実装方式は併用することも可能です。エージェントをインストールできない環境からのアクセスは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による実装による利点は非常に大きいと感じました。
4
