清水理史の「イニシャルB」

tailscale続報 QNAPで動かす&ACLでアクセス制御する&インターネット接続暗号化

 以前レポートしたtailscaleの続報をお届けする。今回は、以前の回で紹介できなかった、QNAP製NASで動かすためのビルド方法とACLを使ったアクセス制御、さらに最新のバージョン紹介する1.6.0で追加された「exit node」機能を用いたインターネット接続について紹介する。なお、「tailscaleって何?」という方は、前の記事を参照してほしい。

QNAPのNASで「tailscale」を動かす

 まずは、QNAPのNASでtailscaleを動かすための方法を紹介しよう。

[Windowsの機能の有効かまたは無効化]で、Windows 10でWSL 2を利用可能にしておく

 QNAP向けのパッケージは正式にはサポートされていないが、有志が作成したQPKG builderを利用することで、簡単にパッケージをビルドすることができる。

 Linux環境があるなら、そちらを利用した方が楽だが、Windowsでビルドしたいという場合は、事前に以下の環境を用意しておく。

Microsoft StoreからUbuntuなどをインストールしておこう
Docker Desktop for Windowsをインストールし、WSL2との連携をオンにする

 Dockerに関しては、インストール後に設定画面で「Use the WSL 2 based engine」をオンにすることで、WSL2から呼び出せるようにしておけばいい。

 準備が整ったら、パッケージビルド用のコードをダウンロードする。Powershellで以下のように入力して「https://github.com/ivokub/tailscale-qpkg.git」をgit cloneで取得するのが楽だが、gitに不慣れならZIPでダウンロードして展開しても構わない。

gitでコードをクローン

 コードを入手したら、次の画面のように「make out/pkg」コマンドを使ってビルドするだけだ(makeコマンドがない場合はsudo apt install build-essentialを実行)。自動的にビルドに必要な環境がDockerを使ったコンテナで用意され、必要なファイルのダウンロードや実際のビルドが自動的に実行される。

make out/pkgでパッケージをビルドする

 完了すると、実行フォルダー配下の「out」にある「pkg」フォルダーに、プラットフォームごとのパッケージが作成されるので確認しよう。

 今回はQNAPのNAS「TS-253D」で利用するので「Tailscale_v1.4.5_x86_64.qpkg」だが、ARM系のCPUを搭載したモデルの場合は、自分の利用しているモデルのCPUを確認し、適合するパッケージを選んで利用する必要がある。

QNAPの2ベイNAS「TS-253D」
パッケージが作成される

 パッケージ作成できたら、NASの共有フォルダーにQPKGファイルをコピーし、AppCenterからインストールする。この際、次の2つの操作が事前に必要になる。

  • QVPN Serviceのインストール
    (いっしょにインストールされるtunモジュールが必要)
  • SSH接続の許可
QVPN Serviceが必要

 設定ができたら、AppCenterからパッケージを手動でインストールする。この際「デジタル署名警告」が表示されるので、「リスクを理解した上でこのアプリケーションをインストールします。」にチェックマークを付けてインストールする。

パッケージを手動インストール

 パッケージがインストールできたら、QNAPにSSHでアクセスし、次のコマンドを実行してインストール先のフォルダーに移動する。

getcfg SHARE_DEF defVolMP -f /etc/config/def_share.info
(パッケージインストール先のフォルダー名を取得。/share/CACHEDEV1_DATA/など)
cd /share/share/CACHEDEV1_DATA/.qpkg/Tailscale
(パッケージのフォルダーに移動)

 最後に、次のコマンドでtailscaleを起動し、表示されたURLをPCにコピーして任意のウェブブラウザーからアクセスして認証すれば接続は完了だ。

./tailscale -socket var/run/tailscale/tailscaled.sock up
tailscaleを起動してウェブ経由で認証を行う

アクセス制御機能であるACLを設定する

 ACLは、tailscaleを組織で利用したり、外部ユーザーとマシンを共有したりする際に必要となるアクセス制御機能だ。

 tailscaleでは、標準設定では同じ組織に所属するマシンの通信が許可されており、クライアントアプリで「Allow Incoming Connections」をオフにする(チェックを外す)ことで、そのマシンへの接続を拒否できる仕組みになっている。

 通常はこの機能だけでもアクセス制御が可能だが、ACLを利用することで、さらに細かな制御が可能になる。

 例えば、次のようなことが可能だ。

 上図は、簡単なACLの設定例だ。左側が社内で右側が社外を示し、それぞれのユーザーに対して異なるアクセス制御設定で「nas01」へのアクセスをコントロールしている。

 社内は、「tokyo」という地域と「manager」という職種の2つのグループで構成されており、それぞれに異なるアクセス権が設定されている。

 具体的には、上のユーザーはmanagerグループで許可されているように、nas01だけでなく全てマシンの全てのポートに対してアクセス可能だが、下のユーザーはtokyoグループにしか所属していないため、nas01に対して80と5000の2つのポートでしかアクセスできない。

 このようなグループごとのアクセス制御に対するACLは、図の同じ色で示された部分のように記述する。

    { "Action": "accept", "Users": ["group:manager"], "Ports": ["*:*"] },
    { "Action": "accept", "Users": ["group:tokyo"], "Ports": ["nas01:80,5000"] },

 「manager」は「"Ports": ["*:*"]」なのでマシンを問わず、全てのポートにアクセス可能だが、「tokyo」は「"Ports": ["nas01:80,5000"」なので、nas01のポート80とポート5000にしかアクセスできない。

 このようにtailscaleのACLでは、ユーザーをグループごとに分けたり、グループごとにアクセスできるマシンやポートを制限したりできる(ユーザーごとに設定することも可能)。

 続いて、図の右側の社外ユーザーの制御を見てみよう。

 こちらは、上図の青い部分の記述でアクセスが制御される。

{ "Action": "accept", "Users": ["autogroup:shared"], "Ports": ["tag:public:7001"]}

 ここでは、オートグループという概念を利用する。文字通り、動的にメンバーを構成可能なグループで、ここで利用している「shared」はtailscale上でマシンを選択して接続を共有した外部ユーザーのアドレスを示す。

 このように、マシンを共有するたびに、共有相手となるユーザーが自動的に「shared」グループに登録されるため、共有相手が増える度にACLを書き換えるような手間がかからないことになる。

 また、共有するマシンも個別のマシン名ではなく「"Ports": ["tag:public:7001"]」とタグで指定している。

 このタグは、マシンごとに設定可能で、マシン側でtailscaleを起動する際に、次のようにタグを付けて起動することで利用できる。

sudo tailscale up --advertise-tags=tag:public

 このようにマシンごとにタグを付けて管理することで、社内ユーザーのみが利用可能なマシンと外部に公開してもかまわないマシンを明確に区別することができる。

 もちろんタグが乱立すると管理が煩雑になるため、タグにはオーナーが必要だ。それが上図のACL内の赤で記述した「TagOwners」の部分になる。つまり、タグを設定できるのは社内ユーザーの中でも特定のユーザーのみに限られることになる。

"TagOwners": {
  // manager allowed to tag servers as public
    "tag:public": [ "group:manager", ],

 こうした機能により、tailscaleでは、マシンに対して複雑なアクセス制御をすることができる。具体的には以下のようなアクセス制御が可能で、これらを組み合わせることもできる。

  1. 外部ユーザーに対してのマシンの共有
  2. ユーザーごとのアクセス制御
  3. グループやオートグループごとのアクセス制御
  4. マシンに対してのアクセス制御
  5. ポートに対してのアクセス制御
  6. タグに対してのアクセス制御

 例えば、ウェブサイトの制作時に顧客に対して「443」のみを許可して内容を確認してもらったり、開発者向けのAPIアクセスだけを許可したり、ゲームのポートのみを許可してマルチプレイを楽しんだりと、特定のユーザーに対して限定的に公開されたポートのみを使ってVPN接続を共有できる。こうした柔軟な設定が可能な点も、tailscaleの魅力と言えるだろう。

社内ノード経由で使ってインターネットに接続する

 最後に、最新のバージョン1.6.0で追加されたexit node機能について紹介する。

 この機能は、tailscaleに接続されている特定の端末のうち、exit nodeに設定した特定の端末を経由してインターネットに接続するための機能だ。

 Wireguadで言えば、端末のAllowed IPsを「0.0.0.0./0」にする設定と同じだ。VPN内部の端末(tailscale接続済みの端末)への接続にだけでなく、インターネット接続を含む全ての通信をexit node経由で行うことになる。

 テレワークなどで自宅から会社のリソースへアクセスするようなケースでは、インターネット接続はそのままに、VPN内の端末に接続するときのみtailscaleで通信する従来のスプリットトンネル方式の方が、VPNのトラフィックを軽減できるため好ましい。

 しかしながら、カフェやファストフード店、空港、駅などで提供されている公衆無線LANのうち、暗号化されてないSSIDやWEPを利用するSSIDに接続するようなケースでは、会社(VPN内)のリソースにアクセスするときだけでなく、インターネット接続もVPNを利用して暗号化したいというニーズもある。exit nodeは、こうしたニーズに応える新機能というわけだ。

 使い方は簡単だ。まず、端末でIPフォワードを有効にする。

 その後、exit nodeにしたい端末(会社やクラウド上の端末)で、「--advertise-exit-node」オプションを付けてtailscaleを起動する。

 続いて、tailscaleの管理画面でexit nodeをオンにする。上の画面でオプション設定した端末がexit nodeとして設定可能になるので、詳細画面でオンにするだけだ。

 準備ができたら、クライアント(1.6.0が必要)で「Use exit node」を選択し、インターネット接続に経由させたい端末を選択すればいい。

 試しに、筆者宅の環境で利用してみたが、以下の画面のようにexit nodeオンとオフの状態で接続元の情報が変化していることが確認できる。これにより、端末とexit nodeの間の通信がWireguardによって暗号化されたことになる。外出先で公衆無線LANを使うときのセキュリティ対策として活用できるだろう。

exit nodeオフ時
exit nodeオン時

 この機能のいいところは、exit nodeを複数構成しておくことで、柔軟に経由先を変更できる点だ。あまり使うことはないかもしれないが、海外のIPアドレスを持つexit nodeを用意しておくことで接続元を海外にすることなどもできる。簡単に設定できる割に柔軟性が高く、利便性の高い機能と言えるだろう。

 このようにtailscaleは非常にアグレッシブで新機能に貪欲なサービスだ。その分、クライアントのアップデートが頻繁で管理が大変だが、同社のことなので、そのうちクライアントの自動アップデートもサポートしてくれることだろう。

清水 理史

製品レビューなど幅広く執筆しているが、実際に大手企業でネットワーク管理者をしていたこともあり、Windowsのネットワーク全般が得意ジャンル。最新刊「できる Windows 10 活用編」ほか多数の著書がある。