清水理史の「イニシャルB」
NAT経由でもDS-Liteでも安全にリモートアクセスできる「Cloudflare Access」 VPN不要でわが家もゼロトラストに！
2020年11月24日 06:00
Cloudflareの「Cloudflare Access」は、ネットワーク環境を問わず、外部からローカル（およびSaaS）リソースへのアクセスを可能にするサービスだ。
大手CDN事業者として知られる同社のネットワークを中継させることで、NATやファイアウォールによる障壁を回避しつつ、認証された高速なリモートアクセス環境を構築できる。社内のウェブサーバーはもちろんのこと、リモートデスクトップや任意のポートへの接続も可能となるテレワーク向けのサービスだ。
「VPNソリューション」記事一覧
50ユーザーまで無料
「Cloudflare for Teams」は、デバイスや場所を問わず、あらゆるアプリケーションに高速かつ安全にアクセス可能にするサービスだ。
同社は、このサービスを「従来の境界型ネットワークとVPNを置き換える『ゼロトラストアクセス（デバイス管理をしないので実質は「ニア」ゼロトラスト）』サービス」と定義しているが、簡単に言うと、ウェブサーバーや社内PCなどのローカルリソースを簡単、かつ安全に外部へと公開し、インターネット経由での高速かつ認証付きのリモートアクセスを実現できるサービスとなる。
同様のサービスは従来から提供されていたのだが、昨今のテレワーク需要に伴って「Cloudflare for Teams」とリブランディングされた格好だ。有料サービスも存在するが、基本は同社が得意とするフリーミアムモデルで、50ユーザーまで無料で利用できるサービスとして提供されている。
Cloudflare for Teamsは、クライアントのアクセス状況確認やポリシーベースのアクセス制御を提供する「Cloudflare Gateway」と、リモートアクセス機能を提供する「Cloudflare Access」の2つから構成される。
そして後者である「Cloudflare Access」の仕組みとしては、同社のCDN網を利用したリバースプロキシと「Argo Tunnel」を利用したリソースとの接続となる。
上は、同社のドキュメントに掲載されている図だが、画面右側の「Data Center」という部分が、社内サーバーなどのリソースとなる。
通常、こうした社内のリソースは、ファイアウォールなどで外部からのアクセスが禁止されているし、中小規模の環境ではNATの内側に存在していて、外部からのアクセスが難しいケースがほとんどだ。また、最近増えてきたIPoE IPv6サービスでは、IPv4がMAP-EやDS-Liteでの接続となって利用できるポートが限られることから、外部からのアクセスが困難となる。
しかし、Cloudflare Accessでは、Argo Tunnelの技術を利用し、サーバー上でcloudflaredコマンドでトンネルを作成することでCloudflareのネットワークと接続している。これは内部からのアクセスとなるので、ファイアウォールやNATの影響を考慮することなく、暗号化された安全な経路を確立できる。
このように、Cloudflareのネットワークへと接続されたリソースは、図の左側にある「User」部分からのアクセスのように、インターネット経由で外部アクセスが可能となるわけだ。
ただし、そのまま公開されるわけではなく、必ずCloudflareのCDNを経由する点がポイント。
CDNやDNS機能を提供するために世界中に配されたエッジがリバースプロキシとして機能するようになっており、インターネットからリソースへのアクセスの際、送信元のドメインでユーザーを区別したり、Microsoft Azure ADやGoogleアカウントといった外部のIdP（Identity Provider）と連携し、ユーザー認証を強制することができる。
つまり、外部に公開されたリソースは、何らかの認証を受けないとアクセスできないため、社員だけ、許可した相手だけ、などのように、利用者を限定することができるわけだ。
同様に、トンネルを使った内部リソースの公開は、「ngrok」などのサービスを利用することで可能だが、こうしたサービスとの最大の違いは、この認証（およびポリシーによるアクセス制御）が可能な点にある。
Cloudflare Accessの使い方
それでは、実際の利用方法を見ていこう。
本サービスを利用するには以下の前提条件を満たす必要がある。
- ドメインを所有している
- ドメインのDNSを変更できる
Cloudflare for Teamsのサービスにサインアップして最初にするのが、ドメインの登録とDNSの変更となるため、あらかじめドメインを取得しておくことをお勧めしておきたい。
なお、このドメインは、例えば社内のウェブサーバーを公開する際、「http://wwww.tnkeng.work」のような名前をCloudflare Accessで与えるために利用したり、アクセス可能なユーザーを自社ドメインのアカウントを所有しているユーザーのみに制限したりするときに利用する。
冒頭でも触れた通り、Cloudflare AccessはCloudflare for Teamsブランドで提供されており、各種設定もCloudflare for Teamsの画面から実行する。だが、筆者が試した時点では、Cloudflare for Teamsの画面から設定すると英語のUIのままとなるほか、ポリシーの設定がうまく反映されないケースもあったので、今回はCloudflare Accessの画面から設定を行った。
では、ドメインの登録を終えたら、公開するリソースのための設定を進めていこう。
1.ログインメソッドの追加
ログインメソッドは、ユーザーを認証する方式だ。
手軽なのは、「One-Time Pin」を用いたメールアドレスによる認証だ。ログイン時にメールアドレスを入力すると、CloudflareからメールでPINコードが送られてくるので、これを入力することで認証する方式となる。
なお、具体的にどのようなメールアドレスのアクセスを許可するかは、後述するポリシーで設定する。
今回は、この「One-Time Pin」に加え、Azure ADによる認証も追加した。Azure ADとの連携には、Microsoft 365などのサービスの加入が前提になるのはもちろん、Azure PortalでアプリケーションIDやクライアントシークレットを取得したり、APIアクセスを許可するなどの設定が必要だ。
具体的な設定方法はCloudflareの設定画面に表示されるので、それを参考に設定を進めればいいだろう。
2.ポリシーの設定
続いて、アプリケーションのポリシーを設定しよう。
まず、ポリシーの前に、アプリケーション名として「www」や「rdp」「smb」などの名前とサブドメインを設定する。これにより、「www.tnkeng.work」や「smb.tnkeng.work」などの宛先で、外部からの接続が可能になる。
そして、ポリシーを設定する。
ポリシーは、アプリケーションへのアクセスを許可・拒否するための条件となる。例えば、「IP範囲」を指定してサテライトオフィスのユーザーからの接続を許可したり、「メール」で特定のメールアドレスのユーザーのみを許可したりできる。
今回は、「次で終了するメール」を利用し「@tnkeng.work」を設定した。これにより、上の設定で、Azure ADによる認証の際に「@tnkeng.work」のユーザーのみのアクセスが許可される。
また、アクセス時に「One-Time Pin」を選択した場合でも、「@tnkeng.work」ドメインのメールアドレスにしかPINが送られなくなる。こうして、外部アクセスを制限できるわけだ。
3.Argoは無効でもOK
ちなみに、Cloudflareの設定にある「Traffic」から「Argo」の設定ができるが、これは無効のままで構わない。
後述するように、アプリケーションの接続のために利用するArgo Tunnelは、Argoサービス自体が無効でも問題なく利用できる（Argoそのものは、従量課金の有料サービスなので注意）。
アプリケーションを公開する
Cloudflare側の設定が完了したら、いよいよ公開するサーバー側の設定をする。
1.cloudflaredのインストール
冒頭で触れたように、公開するサーバーは、Argo TunnelでCloudflareのネットワークへと接続される。このため、まずはサーバーにArgo Tunnelの接続に必要なモジュールをインストールする。以下のサイトで、Linux、Docker、macOS、Windowsの各モジュールがダウンロードできるので、インストールしておく。
例えば、Ubuntuなら、次のようにインストールできる。
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb
sudo dpkg -i cloudflared-stable-linux-amd64.deb
2.証明書の取得
続いて、Cloudflareのネットワークとの間にトンネルを張る際に必要な証明書を取得する。
sudo cloudflared tunnel login
GUI操作が可能な環境であれば自動的にウェブブラウザーが起動するが、そうでない場合はアクセス用のURLが表示されるので、これを適用なPCにコピーしてアクセスし、表示されたウェブページでアクセスを許可する。
すると、「cert.pem」というファイルがダウンロードされるので、これをホームディレクトリの「.Cloudflare」へ保存しておく。
なお、「config.yml」ファイルを作成しておくことで、後述する接続情報をファイルとして保存しておくことができる。また、デーモンとして動作させることもできるが、今回はシンプルに、全て手動で実行することにする。
3.cloudflaredによる接続
さて、準備ができたら、cloudflaredコマンドを使ってトンネルを張る。
コマンドの詳細については、「Cloudflare Access Additional Protocols」のウェブページを参照してもらうとして、ここでは3つのアプリケーションを公開する方法を紹介する。
以下コマンドの最初がポート80のウェブサーバー、2番目がポート5201のiPerf3サーバー、3番目がリモートデスクトップ（RDP）接続用のbastion（要塞ホスト）だ。
sudo -b cloudflared tunnel --hostname www.tnkeng.work --url http://localhost:80
sudo -b cloudflared tunnel --hostname app.tnkeng.work --url tcp://localhost:5201
sudo -b cloudflared tunnel --hostname rdp.tnkeng.work --bastion
RDPは、bastionを利用することで、このLinuxマシンを中継させて同一ネットワーク内のWindowsマシンへとアクセスすることになる。
なお、このように複数セッションを実行することで、同一マシン上で複数のポートを公開可能となるが、検証時はバックグラウンド実行の「-b」オプションも外して、1つずつ動作を確認することをお勧めする。
リモートから接続する
最後に、リモートから接続する。ウェブサーバーは比較的簡単だが、TCPやRDPの場合は、クライアント側でも中継が必要になるので若干複雑だ。
1.ウェブサーバーへの接続
ウェブサーバーへの接続は簡単だ。先のコマンドによって「www.tnkeng.work」として公開されているので、リモートのPCでウェブブラウザーを起動し、このアドレスにアクセスすればいい。
ウェブブラウザーでCloudflare Accessの認証画面が表示されるので、先に選択した認証方法（PINかAzureAD）を選択してユーザー認証を実行すると、ウェブサーバーへとアクセスが転送され、ウェブブラウザーに画面が表示される。
2.iPerf3の接続
iPerf3の場合は、クライアント側でもcloudflaredの接続が必要になる。
このため、Windows版などを上記のサイトからダウンロードしてインストールしておく。ただし、クライアントは証明書は必要ないので、「cloudflared login」による認証や、「cert.pem」のダウンロードは不要だ。
Powershellやコマンドラインで次のコマンドを実行する。
cloudflared access tcp --hostname app.tnkeng.work --url localhost:5201
これで、ローカルからCloudflareのネットワークに接続される。実際のアプリは、ローカルのcloudflaredを経由して接続することになるので、以下のコマンドでiPerf3を実行すればいい。
iperf3 -c 127.0.0.1
コマンドを実行するとウェブブラウザーが自動的に起動し、ウェブサーバーのときと同様に認証ページが表示される。選択した方式でユーザー認証されれば、自動的にiPerf3が実行される。
ちなみに、transix環境で公開したサーバーへのiPerf3の結果は右のようになる（クライアント側ネットワークは「auひかり ホーム10ギガ」）。速度はとても高速だ。
3.RDP接続
RDPは、ここではbastionで構成したので、「--destination」で接続先のPCも含めて以下のように設定する必要がある。
cloudflared.exe access rdp --hostname rdp.tnkeng.work --url localhost:2244 --destination 192.168.1.29:3389
この状態でリモートデスクトップ接続を開き、接続先に「localhost:2244」を指定すると、同様にウェブブラウザーでの認証後、リモートデスクトップ接続が開始される。
このほか、SMB（Windowsファイル共有）も可能となっており、こちらのドキュメントにある設定を参考にすることで、接続できることを確認できた。
ただし、ドキュメントにも記載されているが、Windowsクライアントの場合、エクスプローラーなどから共有フォルダーを指定する際にポートを指定することができない。かといって、標準のポート445をcloudflaredで指定しようとすると、Serverサービスなどで予約されているため指定できないことになる。
なので、ServerおよびTCP/IP NetBios Helperサービスを無効化する必要があり、実用的ではない。SMBアクセスに関しては期待しない方がいいだろう。
手軽で安全
以上、Cloudflare Accessを実際に試してみたが、若干、設定や使い方に慣れが必要なものの、どんな環境（回線）でも安全で、しかも高速にリソースを公開できるようになる。外部IdPによる認証やポリシーによるアクセス制御ができるので、安心して使えるサービスと言えそうだ。
個人的には、SMBによる外部からのNASアクセスに期待していた部分が大きいのだが、残念ながらSMBはクライアント側の設定が面倒で実用的ではない。今回紹介したように任意のポートも公開できるが、基本的にはウェブベースのサービスを公開するために利用するのがよさそうだ。
今回は、ローカルリソースのみを紹介したが、もちろんクラウド上のサービスも公開できる。AzureやAWSの仮想マシンにアクセスするなどの用途にも使えるし、外部のSaaSアプリケーションにAzureADなどの認証を加えるという使い方もできる。使い方次第では非常に便利なサービスと言えそうだ。
清水 理史
製品レビューなど幅広く執筆しているが、実際に大手企業でネットワーク管理者をしていたこともあり、Windowsのネットワーク全般が得意ジャンル。最新刊「できる Windows 10 活用編」ほか多数の著書がある。