これまで自宅用の VPN はルーターの機能の L2TP/IPSec を使っていました。しかしながら、Android 12から L2TP/IPSec が使えなくなったり、もともと接続元のネットワーク環境次第で接続できないという制約もあり、VPN を WireGuard に乗り換えることにしました。

WireGuard は Linux カーネルに組み込まれている VPN プロトコルで、特にセキュリティとパフォーマンスを売りにしています。

構成はこんな感じです。VPN 接続用の IP アドレスは固定です。

  • 自宅側
    • ルーター
      • ヤマハのダイナミックDNSサービスで IP アドレスを引ける
    • VPNサーバー(ファイルサーバー)
      • openSUSE Leap 15.5
      • LAN側アドレス (eth1): 192.168.10.2(インターネットには直接つながってない)
      • VPN側アドレス: 192.168.2.1
      • ポート: 51820
  • リモート側
    • Android 14 スマートフォン
      • VPN側アドレス: 192.168.2.2
    • Android 13 タブレット
      • VPN側アドレス: 192.168.2.3
    • openSUSE Leap 15.6 ノートPC
      • VPN側アドレス: 192.168.2.4

秘密鍵・公開鍵を作成する

VPN に参加するサーバーとクライアントそれぞれの秘密鍵・公開鍵を作ります。openSUSE が動いている PC で以下のコマンドでそれぞれ作成します。

wg genkey | tee privatekey | wg pubkey > pubkey

privatekey と pubkey に秘密鍵と公開鍵それぞれが保存されます。合計3回実行することになります。

VPNサーバー側の設定

今回の説明の範囲外ですが、ルーターでポートフォワーディングの設定をしておきましょう。必要なポートはUDP 51820です。192.168.10.2 に転送するようにしておきます。

まずは VPN サーバー自体のネットワーク設定です。WireGuard そのものにはプロトコル上、サーバーとクライアントという関係はなく、どちらもサーバーでありクライアントなシンプルな構成です。後は WireGuard をどのような用途で使うかによって設定が変わってくるため、WireGuard の説明を見るときに、用途を意識してドキュメントを見ないと混乱するので注意が必要です。

今回は自宅で常時起動しているファイルサーバーを VPN サーバーの役割を持たせて、自宅のネットワークにつなぎたい端末からこのサーバーに繋いで使用することにします。ここからはいつもの Arch Wiki に感謝ですが、「特定のユースケース: VPN サーバー」 を見ることで、この用途の設定方法がわかります。

はじめに、転送とファイアウォールの設定です。YaST でやってしまいましょう。

  • YaST > 「ネットワーク設定」 > 「ルーティング」を開き、「IPv4 転送を有効にする」をON
  • YaST > 「ファイアウォール」 で使用しているゾーンで「ポート」 > 「UDP ポート」 に 51820 を追加

次に、WireGuard の設定をしていきます。wg コマンドで設定する方法もあるのですが、設定ファイルを直接作成するのが手っ取り早いです。

/etc/wireguard/wg0.conf

[Interface]
PrivateKey = VPNサーバーの秘密鍵
Address = 192.168.2.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth1 -j MASQUERADE

[Peer]
PublicKey = Android 14 スマートフォンの公開鍵
AllowedIPs = 192.168.2.2/32

[Peer]
PublicKey = Android 13 タブレットの公開鍵
AllowedIPs = 192.168.2.3/32

[Peer]
PublicKey = openSUSE Leap 15.6 ノートPCの公開鍵
AllowedIPs = 192.168.2.4/32

この設定から、VPN 用のインタフェース wg0 を作成します。Systemd を使用して、起動時に WireGuard インタフェースを立ち上げる便利スクリプトの wg-quick を使います。

systemctl enable --now wg-quick@wg0

クライアントの設定―openSUSE Leap 15.6

NetworkManager の接続の追加に WireGuard があり、これで接続できます。入力する必要の値は

  • openSUSE Leap 15.6 ノートPC 用の秘密鍵
  • ピア(接続相手: つまり、この場合サーバー)の設定
    • VPNサーバーの公開鍵
    • Allowed IPs (VPN を通して通信するアドレスレンジ)
      • LANとVPNのアドレスレンジ: 192.168.10.0/24, 192.168.2.0/24
      • 自宅LAN経由でインターネットに出たい場合は 0.0.0.0/0 を指定して、全部を VPN 経由にすることも可能

クライアントの設定―Android スマートフォン

Wireguard の接続アプリは Play Store から入手できます。NetworkManager と同様に手入力でもよいのですが、以下のようなファイルを PC 上で作成して QR コード化して送ることもできます。

[Interface]
Address = 192.168.2.3/24
PrivateKey = Android端末の秘密鍵
DNS = 192.168.10.1
MTU = 1420

[Peer]
PublicKey = VPNサーバーの公開鍵
AllowedIPs = 192.168.10.0/24, 192.168.2.0/24
Endpoint = 外からアクセスできるルーターのホスト名:51820

ファイル名を android-phone.conf とすると、QR コードは次のようにして作成できます。

qrencode -t ansiutf8  < android-phone.conf

qr コマンドでも同じことができます。

alpのgrafana workloadを制御してみる

By Syuta Hashimoto @ 2023-12-21 08:00

さて、毎度ながらの説明ですが、ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

今日は19日の記事の続きで、alpで動かしたgrafana workloadの制御コマンドを見てみたいと思います。

grafana-container-manage.sh create

grafanaコンテナを作成します。

grafana-container-manage.sh install

grafanaコンテナを動かすのに必要なファイル類をホストの/usr/local/binや/etcにインストールします。

スクリプト内の処理は、ホストのルートをマウントして、label-installというスクリプトを実行していました。

grafana-container-manage.sh start

grafanaコンテナをスタートします。

grafana-container-manage.sh uninstall

installコマンドでインストールしたファイル類などを削除します。こちらもスクリプト内の処理はホストのルートをマウントして、label-uninstallというスクリプトを実行していました。

grafana-container-manage.sh stop

grafanaコンテナをストップします。

grafana-container-manage.sh rm

grafanaコンテナを削除します。

grafana-container-manage.sh rmcache

garfanaイメージを削除します。内部で実行されるコマンドは、podman rmiです。

grafana-conatiner-manage.sh run

grafanaコンテナを実行します。

grafana-container-manage.sh bash

grafanaコンテナ内のbashを実行します。

grafana-container-manage.sh logs

grafanaコンテナのログを表示します。

コンテナのライフサイクルがわかっていれば、各コマンドの意味がわかるかと思います。

uninstallを実行すると、当然grafana-container-manage.shも削除されます。再び使うためには、19日の方法でイメージのinstallラベルを実行します。

# podman container runlabel install registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/grafana:latest

また、rmcacheでイメージを削除後、createをしようとするとイメージのpullが始まります。まぁ当然ですね。

実行時、runだとgrafanaのコンテナの中のシェルが動いたため、cerateからstartを実行する方法が安全そうでした。

基本的にはpodmanコマンドのラップですが、installなど一部処理を簡単に実行できるようになっているので、ぜひ試してみてください。

alpでgrafana workloadを動かしてみる

By Syuta Hashimoto @ 2023-12-19 08:00

さて、毎度ながらの説明ですが、ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

ここ何回かalpについて記事を書いていて、やっとわかってきました。SUSE/openSUSEは、ホストとの連携が必要などの単に動かすだけでない処理が必要なアプリのインストールや準備処理を、コンテナに内包して、workloadとして動かす、という戦略をとってるものがります。その時に利用するのが、podmanのlabel付け(実行コマンドにlabelをつける)と、そのlabel名で呼び出すrunlabelオプションです。

今回はgrafanaをマニュアルに従って動かしてみます。

grafanaサーバーのセットアップ

まず、workload内包コンテナを探します。

# podman search grafana

あれ?一覧にworkloadのコンテナが出てきません。直接レジストリ名を指定してみます。

# podman search registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/grafana

表示されました。

では、イメージをpullしてワークロードを実行します。

# podman container runlabel install 
registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/grafana:latest

容量があり1分ほど時間がかかりましたが、準備が完了しました。

grafanaのworkloadは、grafana-container-manage.shというスクリプトを用意してくれ、これを使ってコンテナの作成や実行などを行います。

まずは、コンテナを作成します。

# grafana-container-manage.sh create

すぐにコンテナが作成されました。

では、コンテナをgrafanaのサーバーと共に実行します。

# grafana-container-manage.sh start

今は指示通りコマンドを叩いてるだけですが、それぞれが何をしているかを見てみるのも楽しそうですね。

grafanaクライアントのセットアップ

今回はalpを動かしているホストをクライアントにしようと思います。

クライアントには、以下の2つのパッケージをインストールし、サービスを再起動します。

パッケージのインストール

  • golang-github-prometheus-node_exporter
  • golang-github-prometheus-prometheus

サービスの再起動

  • systemctl restart prometheus-node_exporter.service
  • systemctl restart prometheus

grafanaでの表示

では、grafanaを設定していきます。

ブラウザからgrafanaにアクセスします。

http://[ALP_HOST_IP]:3000

ログイン画面が表示されるので、ログインします。初期設定は両方ともadminとなっています。ログイン後、パスワード変更画面になりますので新しいパスワードを設定します。

ログイン後画面

ログインしたら、ホストのprometheusからデータを取得します。

上段の真ん中にある「DATA SOURCES」をクリックし、種類の一覧が表示されるので一番上の「Prometheus」を選択します。

Prometheus server URLに、Prometheusを動かしているマシンのurlを指定します。デフォルトでポートは9090です。僕の場合、alpを動かしているホストなのでhttp://192.168.122.1:9090となりました。

ホストのlibvirtのゾーンで9090を開放し、画面下部の「Save & test」ボタンをおすと、Successfullyと出てきました。

サンプルで用意されているDashboardsを読み込んでみます。マニュアルはバージョンが古いようで、僕が試した時は以下の手順になりました。

  1. 左上のハンバーガーメニューから、Dashboardsを選択する
  2. 右側にある「New」のボタンをクリックして出てくるドロップダウンから、Importを選択する
  3. Import via grafana.comに、405と入力して「Load」をクリックする
  4. prometheusをクリックして、データソースを選択する 手順通りだと一つのため、それを選択する
  5. 設定が読み込まれるので、下の「Import」をクリックする

無事、グラフが表示されました。

Grafanaダッシュボード

grafanaを制御するスクリプトには他にもアンインストールやキャッシュ削除などのオプションがありますので、追って紹介しようと思います。

alpのCockpitでpodmanを制御してみる

By Syuta Hashimoto @ 2023-12-15 08:00

さて、毎度ながらの説明ですが、ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

今日はalpで動かしているCockpitから、podmanを制御してみたいと思います。

まず、左側に「Podmanコンテナー」というメニューがあるので、そこを選択します。

すると、画面にPodmanサービスを有効化というボタンが表示されるので、クリックして有効化します。(すみません、スクショを撮り損ねてしまいました)

すると、イメージやコンテナーなどを制御できる画面が表示されます。

Podmanコンテナーの画面

かなり直感的な操作ができそうです。

では、コンテナーを作成してみます。右下にある「コンテナーの作成」をクリックすると、コンテナー作成ダイアログが表示されます。

試しでnginxを作成してみます。

コンテナーの作成ダイアログ

イメージの所にnginxと入れると、候補が表示されて、そこから選ぶことができました。

また、ポートマッピングもしておきます。「インテグレーション」タブで設定できました。

コンテナーのポートマッピング

左下の「作成して実行する」をクリックします。すると、イメージのダウンロードが始まりました。

イメージダウンロード中

少しすると、無事実行中になりました。

コンテナー実行中

ホストのブラウザからアクセスすると、nginxが起動していることが確認できました。

停止や削除などの操作も一通り画面から行えました。Podman、というかコンテナーの基礎知識は必要だなとは思いましたが、かなり直感的で使いやすかったです。

alpでfirewalldをpodmanで動かしてみる

By Syuta Hashimoto @ 2023-12-12 22:22

ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

さて、今日は公式ドキュメントにある、firewolldをpodmanで動かす手順をやってみようと思います。

まず、alpにログインし、alp用のfirewalldのコンテナを特定します。

# podman search firewalld

そうすると、ドキュメントにも乗っているalp用ワークロードが搭載された registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld のイメージが見つかります。

次に、手順の通り、alpからパッケージとしてのfirewalldを削除します。alpはイミュータブルなため、通常のzypperコマンドではなく、専用のtransactional-updateコマンドで暫定的な削除を行い、リブートすることでそれがシステムに適用されます。

# transactional-update pkg remove firewalld
# reboot

では、イメージのワークロードを実行します。

# podman container runlabel install \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld

他のイメージの実行時にも触れましたが、podmanは実行コマンドにラベルを貼ることができ、runlabel コマンドでそのラベルを指定して実行することができます。一連のalpワークロード用イメージは、installといったラベルにホストの設定などの処理を持たせています。

ドキュメントによると、firewalldはpolkitやsystemdなどの準備をしてくれているようです。

そう言えば、冒頭にdbusとpolkitの設定ファイルが必要、と書いてあったのですが、特に用意はせず、、、さて、どうなるでしょうか。

インストールが終わったので実行します。

# podman container runlabel run \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld

コンテナが実行されました。ではコンテナ経由でfirewall-cmdを実行してみます。

# podman exec firewalld firewall-cmd --list-all-zones

すると、zoneが表示され、firewall-cmdが実行可能なことがわかりました。

なお、firewalldのコンテナはホストを制御する関係上、privilegedで動いています。また、podmanを使っている場合、systemdとも統合されていて、systemctlコマンドで制御することが可能です。例えば、コンテナの起動は以下のコマンドで代替できます。

# systemctl start firewalld

なお、firewalldやfirewall-cmdのマニュアルをコンテナ経由で見る方法もドキュメントに書かれていました。

firewalldならば、

# podman run -i --rm \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld \
man firewalld

firewall-cmdならば、

# podman run -i --rm \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld \
man firewall-cmd

で参照可能です。 manコマンドをコンテナの中で呼び出しているわけですね。

個人的に、firewalldをコンテナで実行する利点欠点が見えていない所があり、そのあたりも追って調査考察してみたいと思います。

openSUSE 15.5 で試したのですが、GlusterFS の中の glusterd は peer との通信にデフォルトで IPv6 で通信しています。 /etc/hosts に IPv4 アドレスでホスト名を指定してもそこを見ません。
IPv4 で通信させるためには、 /etc/glusterfs/glsuterd.vol に

option transport.listen-backlog 1024

と言う行を追加する必要があります。

第四世代の Intel CPU を使ったマシンで openSUSE を使っていると、シャットダウンコマンドで電源をOffにしようとしても( poweroff など)電源が切れません。一旦切れたようになりますが、再度起動してしまいます。この動作は、なぜか Windows と BSD (Dragon Fly BSD)では起こらず Linux のみ起こる現象のようです。 openSUSE 意外に Debian でも現象を確認しています。

色々調べたのですが、正解にはたどり着けず、毎回手動で電源を落としていました。そうすると、マジックパケットを飛ばして WOL による起動ができなくなり、ちょっと不便に感じていました。

結局、Kernel の詳しい人に正解をいただきました。Grub のオプションに
xhci_hcd.quirks=0x2000
を付けるのだそうです。これでちゃんと電源が切れ、さらに WOL も動くようになりました。