Cloudflare Zero Trust Network Access を設定して自宅環境にアクセスする
先日、外出先でのPC操作のために無線の分割キーボードを組んだ。仕事は基本的にリモートなので使うことはあまりないと思っていたが、思いのほか使い心地がよくて気に入ってしまった。自宅で利用してもいいのだがせっかくだから外で使いたい... 多少無理やりにでも外出先で打鍵する機会を増やそう！そうだ自宅環境にリモートでアクセスできるようにしよう！
そう思ってVPNを張ろうと思っていたところ、当たり前のことに気が付く。「固定IPの取得するの面倒だしお金もかかるので嫌だな。ほかに方法はないものか」というわけで調べたり人に聞いたりしてCloudflare Zero Trust Network Accessに行き当たり、サービスを常時稼働させれば無料で利用できるし使ってみよう！となった。
ということで、この記事ではCloudflare ZTNAをセットアップして、外部NWから自宅環境にアクセスするところまでの備忘を記録する。
目次
あらかじめ用意済みのもの
以下のものはすでに調達済みのため、この手順メモの対象外とする。また、今回はIdPにGitHubを利用しているが、その他OktaやAzure AD、Googleアカウントなども利用可能なため、好きなものを用意しておけばOK。
構成/作業概要
自宅には検証用サーバとしてPROXMOXが稼働している検証環境用NW（192.168.200.0/24）がある。ここに外部からアクセスできるようにしたい。
- Cloudflare ZeroTrustのセットアップ
- Tunnelの作成
- WARPのセットアップ
はじめにCloudflare Zero Trust のサービスの設定を行い、チーム名・料金プランなどを設定する。 次に検証環境上のVMでCloudflaredサービスをインストール・アクティベーションを実施してTunnelを作成する。 最後にWARPでの認証方法・アクセス許可設定などを行う。
Cloudflare Zero Trustのセットアップ
Cloudflareにログインして、左ペインから「Zero Trust」を選択する。
Zero Trustへのアクセスが初回の場合は初めにチーム名を設定することになる。チーム名はクライアントからアクセスする際に入力するパラメータであり、 cloudflareaccess.com でユニークである必要がある。
チーム名を入力したら、Cloudflare Zero Trust のプランを選択する。ユーザが50人未満であればFreeプランで利用できる。24時間のログ保存、レイヤー７フィルタリングまでついてて無料なのは大変ありがたい。
Tunnelの作成
次にTunnelを作成するため、左ペインからネットワークを選択する。
「トンネルを作成する」からTunnelを作成してもいいが、ここでは「クライアントベースのVPNを置き換える」をクリックして設定を進めた。
その後Tunnel展開先のOSを選択し、検証環境上のVMにCloudflaredサービスをインストール・アクティベーションする。
OSの選択をするとOSに応じたインストールコマンドが表示されるのでそのコマンドをVMで実行し、cloudflaredをインストールする。インストールコマンドと一緒にCloudflareとのTunnel確立のためのコマンドが作られるので、それをコピーしてVMで実行する。
この後、「デバイスを登録する」にて、なぜか「次へ」がグレーアウトされていて進まなかったため、あとでデバイスを登録しようと「今はスキップ」をクリックした。 すると設定ウィザード全体がスキップされてしまったので、個別でデバイス登録とWARPの設定を完了させる。
この時点で、
WARPの設定
WARP認証方法の登録と紐づけ
まずは、WARPの認証方法としてIdPを追加する。今回はGitHubのアカウントを利用することにした。
「設定」→「認証」の順に遷移し、ログイン方法を新規追加する。
新規追加の方法としてIDプロバイダー一覧が出てくるので、GitHubを選択する。するとセットアップ手順が出てくるので、ガイドの通りにGitHubに情報を入力してアプリIDとクライアントシークレットを取得する。
「設定」→「WARPクライアント」→「デバイス登録権限：登録」から、「既存のポリシーを選択」をクリック。先ほど登録したGitHubによるログインルールをAccessポリシーとして登録し、保存する。
アクセスポリシーの設定
Tunnelにアクセスできるようにするため、WARPからの通信をCloudflare Gatewayに転送する必要がある。Firewallのプロキシを有効化することによって、ポリシーの適用とGateway への転送ができる。
「設定」→「ネットワーク」の順に遷移し、ファイアウォールの項目からプロキシを有効化する。
スプリットトンネルの設定
「設定」→「WARPクライアント」に遷移し、プロファイルの設定からデフォルトのプロファイルを編集する。
デフォルトのポリシーはブラックリスト形式で設定されているため、通信先（検証環境）のIPレンジがブラックリストに載っている場合は削除する必要がある。
デフォルトのポリシーには192.168.0.0/16 が登録されている。そのためデフォルトのプロファイルにあるこの設定を削除してあげる。この設定をすることによって、Tunnelから検証環境(192.168.200.0/24) への通信ができるようになる。
ここまで実施すればCloudflare側の設定が完了する。 あとはクライアント側にWARPをインストールし、「アカウント」からZero Trust Networkにログインする。ブラウザでGitHub認証が立ち上がるので、GitHubアカウント情報を入力してあげるとCloudflare ZTNAを利用してリモートの検証環境にログインできるようになった✌
ProxmoxでCloud-init を利用してVMを構築する
はじめに
検証のたびに手作業でVMを構築して、ホスト名、IP、SSH鍵、パッケージインストールなどを個別で行うのは辛い。 そんなにがっつり作りこむ必要はないけれど、毎回お決まりの処理くらいはサクッと自動でやってほしいのCloud-initを使ってみることにした。
基本的には公式ドキュメントの例をほぼそのまま実行しているので詳細などについてはそちらを参照してもらうほうがいいかもしれない。 ここでは個人的な対応内容メモやうまくいかなかったところを記録として記載しておく。
また、今回の作業で大いに参考にさせていただいたブログも置いておく。
zaki-hmkc.hatenablog.com
基本的には参考にさせていただいたZakiさんのブログにある通りに作業を進めた。
ただし、ベースとなるCloudイメージはRocky Linuxを使いたかったため、以下のリンク先からイメージを入手した。
wiki.rockylinux.org 入手したCloud イメージをProxmoxサーバに配置するのだが、正直どこに配置すればよいのかよくわからなかった。 GUI上には、ProxmoxサーバのLocal ストレージにISOイメージを配置する箇所があるので、その辺に置かせてくれればいいのだがqcow2 形式のファイルが配置できない。 そのためCLIでProxmoxサーバにログインして、取得してきたCloud イメージファイルを配置してあげる必要がある。共有しているストレージがあればそっちに配置してPROXMOXにmntしてあげてもOK。いずれにしても、PROXMOXサーバにSSHログインをしてテンプレート作成をするのでログイン先から参照できるところに配置してあげればよい。 PROXMOXサーバにSSHログインをして、qmコマンドを利用してテンプレート元となるVMのセットアップをする。
VMのIDは3ケタ、テンプレートのIDは4ケタにすることにした。ドキュメントのサンプルに習いここでは9000 でVMを作成。 このコマンドを実行するとGUI上でもVMが作成される。
ただし、この状態ではVMのガワだけ作成した状態なので、このVMに対してダウンロードしたクラウドイメージをセットする。 GUI上では、VMの「ハードウェア」からCloud-Initデバイスを追加する操作となる。
その他ブート順序の設定、コンソールの設定などについてはガイドに沿ってそのまま実行する。 以下のコマンドを実行して、ID 9000 のVMをテンプレートに変換する。 これを実行するとGUI上からもVMがテンプレートに変換されることが見える。
GUIから、テンプレートのCloud-Initを選択すると、GUI上から設定できるパラメータが参照できる。
ここでは、ユーザ作成とそのユーザでログインする際のSSHキーを設定しておく。
また、「パッケージをアップグレード」をYESにしておくと、初回起動時にパッケージを更新してくれる。 これでこのテンプレートを利用してVMをデプロイすると、Cloud-Initの設定を反映してVMを構築してくれるので、さっそくVMデプロイをしてみた。
停止状態のVMが作成されるため、「ハードウェア」「Cloud-Init」の設定が反映されているかどうかを確認する。
IPアドレスは固定で設定してあげたいので、この段階でCloud-Initに入力しておく。
問題なさそうに見えるので、VMを起動するとboot中にKernel pacnicが発生してbootが止まってしまった。
ここからRocky Linuxのシステム要件を確認してメモリやディスク容量をいじったりしてみたけど、いまいち解消しない。
ただまぁ、「kernel panic not syncing attempted to kill init exitcode=0x00007f00」で調べてみるとHW起因でトラブルが起こっている気がする。 すでにISOで手動構築済みのRocky Linux VMがあったのでそちらのHW設定を参照していると、CPUの種別の設定が違っていた。
テンプレートのCPU種別の設定はデフォルト設定でブランクとなっていたが、先に構築済みのVMでは種別が「x86-64-v2-AES」に設定されていた。
なので、こちらでも種別を「x86-64-v2-AES」に設定してあげると正常に起動してきた。これで問題なさそうだ。
Cloud-Initの設定によりパッケージ更新している様子が確認できる。 ちなみに、後から調べてみるとこの問題はAlma 9やRocky Linux 9で発生する事象らしい。リンク先にあるようにCPU種別を「host」に変更してあげてもbootできたので、そちらに変更しても回避できる問題のようだ。
Rocky Linux やAlma Linux系のコンテナを動かす時も類似の事象が出るようなので、この辺のOSをよく使う人は覚えておくといいかもしれない さて、起動したVMが事前に設定していたユーザとSSHキーでログインできることも確認できた。
このままだと起動するたびにパッケージ更新がかかるので、それを回避したい場合はCloud-initデバイスを削除しておくことを忘れずに。 ただ、せっかくCloud-initを利用するなら、GUI上で設定できるユーザやIPアドレス、パッケージ更新だけでは物足りないのでもう少しいろいろカスタマイズしていこうと思う。
その場合CLIベースでカスタマイズしていくことになるようなので、もう少し知らべてみたら挑戦してみようと思う。VMテンプレートの作成とCloud-init設定
Cloudイメージの取得と配置
scp .\Rocky-9-GenericCloud.latest.x86_64.qcow2 root@192.168.200.10:/home
VM作成
qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
qm set 9000 --scsi0 local-lvm:0,import-from=/home/Rocky-9-GenericCloud.latest.x86_64.qcow2
import-from の部分がダウンロードしたイメージのパス。
これを実行するとイメージが適用されたディスクがVMにセットされる。ハードウェア設定の追加
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
テンプレートへ変換
qm template 9000
VMデプロイとKernel panic
Proxmox無償版リポジトリ登録とアップデート
以前ESXi サーバをつぶしてProxmoxをインストールしたが、そこで満足して塩漬けにしていた。そろそろ発酵が進みマイルドになったと思うので改めて検証環境のセットアップを開始しようと思う。
前提
物理サーバへのProxmoxインストールはすでに完了しているので省略。
他のブログでも紹介されているようにProxmoxのイメージをダウンロード、isoイメージをUSBに書き込んでインストールした。
今回はproxmoxをアップデートするために無償版リポジトリの登録とアップデート、ストレージのセットアップのメモを残しておく。
無償版リポジトリの登録
デフォルトでは有償版のリポジトリが登録されており、そのままでは無償版Proxmoxのアップデートができないため、無償版リポジトリを登録する必要がある。
実施することは二つ。
CLIとGUIのどちらからでも実施できるが、今回はGUIで設定を行った。
有償版リポジトリの無効化
Proxmoxにログインし、Proxmoxサーバの「リポジトリ」を選択。
※ちなみに表示を日本語にする場合は右上のユーザのプルダウンをクリックするとLanguage から日本語を選択できる。
URLに「enterprise」が入っているリポジトリを選択し、「無効」をクリック。画面では以下二つのリポジトリが無効化対象。
これで有償版リポジトリの無効化は完了。
無償版リポジトリの登録
同じ画面から無償版リポジトリを簡単に登録することができる。
「有効/無効」ボタンの隣にある「追加」ボタンをクリックし、「No-Subscription」を選択し、「追加」ボタンをクリックするだけで登録が完了する。
追加後は「pve-no-subscription」と記載された以下のURLが登録されているので確認する。
これで無償版リポジトリの登録が完了。Proxmoxのアップデートの準備ができた。
ちなみに、同様の操作はCLIでもできる。ProxmoxサーバにSSHでログインし、リポジトリの File に記載されているパスを参照するとそれぞれのリポジトリの記述などがある。コメントアウトで無効化、既存の記載を真似してリポジトリ追加が可能。
Proxmoxアップデート
アップデート作業の一番面倒で手間がかかるのが、互換性の確認だ。
互換性の確認を怠れば利用している機能や動作に問題が生じ、利用できなくなる可能性がある。あわてて切り戻したりしても、中途半端に戻ってより一層ひどい状況になることだって珍しくない。
そのため、先にリリースノートを確認して影響範囲を把握し、アップデートを取捨選択、さらには作業前にサービスを停止してバックアップを取ることも大事だ。
でも今回はそんなことは気にしない。なぜならずっと塩漬けで利用していなかったサーバなので何も考えずに更新してしまえ。
本当はHWとの互換性くらいは確認したほうがいいかもしれないがまぁ大丈夫だろう。エイヤエイヤ
アップデート作業だけなら簡単だ。
ProxmoxサーバにSSHでログインしてaptコマンドでアップデート・アップグレードを実行するだけだ。
apt update
apt full-upgradeそれぞれエラーなどがなく完了したらProxmoxサーバを再起動してあげれば完了。
ちなみにきちんとバックアップ取ったりする場合はこちらの記事を参考にされるといいかもしれない。
これでしばらく塩漬けにしていたHome Laboサーバの準備ができたので、ぼちぼちと検証して遊んでいこうと思う。
