さて、TailScaleに大満足なのですが、かねてからの
HeadScaleに挑戦しました。
ご存じない方の為に書いておくと
Tailscaleの認証サーバーの部分をオープンソース版の管理サーバーに置き換えたのが
HeadScaleです。
クライアント側は引き続きTailScaleのソフトを使えるようになっています。
そう敵対する関係ではないのです。
TaileScaleの管理サーバーはTailScaleの会社が管理していて、かつ認証はOAuth2.0
が使われているので何かしらの認証に依存します。TailScaleの管理サーバーが
落ちると巻き添えになるわけです。
そこに依存しない為にHeadScaleがあります。
ということで、魅力的ではあるのですが、HeadScaleの機能はTailScaleの管理サーバー
には及ばないようです。
まあ最低限のことはできるので、VPNとしては使えます。
このHeadScaleの導入ですが、とっても大変でした。（涙）
日本語の解説も少なくDockerでの運用が多く、通常の運用事例というものが
少ないです。かつ海外でも少ないですね。
公式の情報が頼りですが、印象としては寡黙な感じです。（笑）
まあ必要なことは書いてあるんですけどね。
まずインストールからなのですが、Dockerの事例が多いですが、
https通信をさせるという時点ではまります。（笑）
DockerにTrafikというやつをまぜてproxyを使うらしいのですが、
Dockerに慣れてないので、私には高度すぎます。（涙）
ということで通常インストールを選びました。
aptですね。 すらっと入りました。
ここからが地獄でした。
ポートが8080と9090を使うみたいです。
がみるとhttp通信です。ただサーバーのFQDNはhttpsを要求します。
すると証明書が必要になりますね。
そうLet's Encryptの出番になってくるのです。
設定ファイルにSSL通信のパラメータがある感じで、自動で設定してくれそう
な感じもしますが、わからない。
ということで悟ったのがReverse Proxyをかまして、内部ポートへ
転送するんだと理解しました。
そうすればhttp通信を外部からはhttpsで受け取れます。
Proxyで吸収する方法ですね。私もnextcloudでやっているやり方です。
ProxyといえばNginxです。難しいからTrafikを推奨していると解説されていましたが、
私的にはNginxのほうが経験があるので、わかりやすいです。
探すと公式でNginxの事例が書いてありました。ありがたい。
リバースProxyの神髄はパラメータで何を渡すかが肝です。
公式通りに設定したら動きました。
Magic DNSはまだ動いてないのですが、実装されていないのかこれから調べます。
認証ですが、TailScale側でログインサーバーを指定して
Tailscale up すると、HeadScaleサーバー側で行う実行コマンドが表示されます。
これをHeadScaleサーバー側で実行すれば認証されます。
ここはTailScaleと違うところですね。
一時的に別の方法で、HeadScale側と通信しないといけません。
今回は本当に大変でした。
知識をフル動員した感覚です。DNSで認証サーバー用のFQDNを作るところから
です。楽しいですよね。
設定用GUIが公式ではないなど、TaileScaleに比べるとまだまだですが、
自分に主権を持つというＯＳＳの理念を体現できていますので、
満足でした。
長いことの悲願が達成できました。
主権を取り戻したい方はぜひ、アドバイスは惜しみませんので聞いてください。
ではでは。
