2月 052024
 

以前のエントリで「bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する。」と、いうエントリを書きました。そして、一個前のエントリ「NiPoGi GK3Pro ミニ PC 購入。」では MINI PC には VMware ESXi ではなく bhyve で仮想環境を構築した。と、書いています。

bhyve は基本的にコマンドをチマチマ打っていく状態だったので『GUI で簡単に仮想サーバ構築とかできないのかなぁ?』と思って探してみるとあるようですねぇ。 FreeBSD の ports にはなっていないようですが、GitHub からダウンロードできるようです。

https://github.com/DaVieS007/bhyve-webadmin

ここから bhyve-webadmin-master.zip をダウンロードして展開します。
今回ダウンロードしたのは BVCP という bhyve をウェブベースの GUI で管理できるものになります。
インストール先の FreeBSD では bhyve の環境が整っている必要があります。上記の「bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する。」のエントリ中の『1. FreeBSD 母艦側の設定』の部分の設定をまず先済ませておく必要があります。

 
1.インストール
展開後にその中にある install.sh を実行します。以下、簡単なテキストキャプチャです。
指定するのは唯一データを管理するディレクトリを指定するのみです。今回は /opt/bhyve を指定しました。

# unzip bhyve-webadmin-master.zip
<略>
# cd bhyve-webadmin-master
# ./install.sh

                    ██████╗ ██╗   ██╗ ██████╗██████╗ 
                    ██╔══██╗██║   ██║██╔════╝██╔══██╗
                    ██████╔╝██║   ██║██║     ██████╔╝
                    ██╔══██╗╚██╗ ██╔╝██║     ██╔═══╝ 
                    ██████╔╝ ╚████╔╝ ╚██████╗██║     
                    ╚═════╝   ╚═══╝   ╚═════╝╚═╝     

            Bhyve Virtual-Machine Control Panel under FreeBSD
        
 N  2024-02-05 09:38:25 | BVCP | Initialising BVCP-Backend 1.9.8-p9 Application

  [>] Generating Entropy ... [9BA2FE3E0EC4B6D72CF2E6760FF5B0AA]

 Welcome to initial setup menu!
 The Software is located at: /var/lib/nPulse/BVCP

 The Software is producing pseudo filesystem scheme for virtual machines using symlinks
 Where to create metadata, iso_images, database, config, logs: (Does not need much space), default: [/vms]_> /opt/bhyve
<略>
 N  2024-02-05 09:40:08 | BVCP | Initialising BVCP-Backend 1.9.8-p9 Application
 N  2024-02-05 09:40:10 | BVCP | Starting Database ...
 (!) Admin Credentials recreated,
   - User: admin
   - Password: LmZH4kXD

 N  2024-02-05 09:40:10 | SW | Program exited gracefully...
Installation Finished!
Navigate: https://[your-ip]:8086
#

 
BVCP のデータ管理用ディレクトリを指定してインストールすると上記のようになって終わります。ウェブログインするパスワードが表示されているので覚えておきましょう。

インストール先についてですが、以下のようになっています。

  • BVCP のベースプログラムは /var/lib/nPulse/ にインストールされます
  • /etc/rc.conf に bvcp_enable=”YES” という文字列が追加されます
  • /usr/local/etc/rc.d/ 内に bvcp-backend bvcp-frontend bvcp-helper の三つのファイルが追加されます
  • データ保存先の /opt/bhyve/ が作成されます

 
上記のディレクトリ、ファイルを全て削除することによりまっさらな状態(uninstall した状態)となります。

 
2.仮想マシン作成前の準備
インストール後ウェブブラウザから https://wanchan.running-dog.net:8086 などとアクセスします。

インストール時に控えていた admin とそのパスワードでログインし、まずは右上をクリックしアカウントの管理として Account Settings から自分のメールアドレスを登録しましょう。

 
新規にアカウントを作成したら admin をログアウトして、新しいユーザでログインし直してと。
仮想マシンが利用する HDD イメージを保存するストレージを指定します。大容量のディレクトリを指定しましょう。

NFS 領域も指定できます。Active 系 bhyve 母艦がダウンすると NFS 上にゲスト OS のイメージがあるので Standby 系を Active にしてゲスト OS を起動できたりするので冗長構成が取れそうですね。

 
次にネットワークを設定します。
VLAN などの設定は母艦の FreeBSD 側で先に設定しておく必要があります。必要であれば設定しておきましょう。この辺り VMware ESXi 的に言うと vmnic0 に VLAN 単位の vSwitch を生成して、それを仮想マシンで利用する。みたいな雰囲気ですね。
母艦の FreeBSD が利用できないネットワークインターフェースは当然 bhyve でも利用できません。
pptdevs 経由で仮想マシン側にデバイス渡したくても BVCP の UI にデバイスを渡すオプションは今のところ無いようです。

ネットワークを作成する場合は em0 とか re0 などを一個含めておくと、bridge300 番台を生成してくれます。母艦側の FreeBSD の VLAN インターフェースも指定可能です。
その後、仮想マシンを作成したタイミングで tap300 番台を自動生成してくれ、かつ、それを bridge として追加してくれるようになります。
母艦側の NIC を含めないネットワークを作成すると、それは裏 LAN 的な、外に出ていかないネットワークとなります。

これで、アカウント・ストレージ・ネットワークの設定が完了しました。

 
3.仮想マシン作成
ここまで来たらいよいよ仮想マシンの追加をします。一番最初は OS の雛形を指定することになります。

対応している OS は FreeBSD・Linux・Windows になります。まぁ、それだけあれば十分か? macOS は FreeBSD かな?デバイスの形態が全く違うけど・・。 VyOS は Linux ですな。では Solaris は? まぁ、その話は置いといて・・f(^^;;。

雛形を作成したら次に作成した OS を選択して詳細を設定していきます。まぁ、GUI なので直感的に設定ができますよね。

色々細かい設定とかありますが、まずは OS をインストールしなければならない。
Virtual Hardware のところでは CPU 数やメモリ容量の変更ができます。

インストールのために CD-ROM Drive を指定します。ISO イメージを、データを管理するディレクトリ内に設置します。今回の環境での場所としては /opt/bhyve/iso_images/ になります。このディレクトリ内に保存します。

次に HDD イメージを作成します。登録したストレージ内に必要な容量を選択します。
その次に追加された HDD イメージの詳細設定を行います。

Name / Description は書いておいたほうが良いでしょう。 LUN Slot は気分的な設定値ですが、仮に HDD を複数接続したときに番号をずらしたほうが良さそうな雰囲気ですよね。
Attach Disk にチェックを入れると OS 側で HDD を認識するようになります。

作成した HDD は 今回の環境では NFS 領域の /media/Strage/ に vm_images というディレクトリが作成され、その中に格納され /media/Strage/vm_images/ubuntu01_disk01.img になります。 仮想マシン登録時に指定した Machine Name の ubuntu01 (小文字になる)と Name / Description で指定した disk01 を合わせたファイル名になります。

最後にネットワークを指定します。
自分が接続したいネットワークの指定と、ドライバを指定します。ドライバは FreeBSD 的に言うと vtnet0 と em0 の二つが選べます。 WindowsOS をインストールするときは Intel Pro 1000 を指定したほうが良いかもです。

 
これで設定がぜんぶ完了しましたかね。

 
4.いよいよ起動
では左上にある緑色の Start ボタンを押しましょう。そして起動後に現れる VNC Console をクリックすると別ウィンドでコンソールが表示され OS がブートするところを確認できます。その後 OS のインストールを進め、再起動してインストール完了。
apt -y update などで最新の OS 状態にしたり apt-get install でパッケージを色々インストールして最低限の環境を構築すれば良いですね。

ここで一旦 OS を停止して /media/Strage/vm_images/ubuntu01_disk01.img をバックアップしておけば、もう一個 OS を作成したいときにタネ用 HDD として利用できます。
新規に ubuntu02 とかを作成するときに Create Virtual Disk のところでうまいこと指定することができます。

あと、起動時に毎回コンソールに入る状態になっているのですが、一番上の Options の中の Wait for console: を No にすると、コンソール画面を開く必要はなくスルっと起動するようになります。

 
自分で作成した環境で、コマンドベコベコ打って仮想マシンを作成していたとき、WindowsOS は中々起動できなかったのですが BVCP を利用すると簡単に起動させることができます。
母艦側には潤沢な資源が必要になりますが、僕が試してみたところ Windows11 Pro と Window Ssever 2019 が起動できて動作しています。
まぁ、Windows11 の場合は BypassTPMCheck と BypassSecureBootCheck は必須になりますが、ここでは省略します;-)。

とまぁ、比較的簡単に bhyve を利用したウェブ UI の仮想環境が構築できました。

 
今回の BVCP を利用した bhyve 環境は、新規の仮想環境の構築となります。今までコマンドベースで自分の趣味を反映した bhyve 環境で用意したモノを再利用しようとしてもほぼ利用できません。
例えば BVCP 環境下で作成した FreeBSD のディスクイメージを自分がコマンドベースで作成した bhyve 環境に持っていって起動しようとしても、ブート時のデバイス認識のところでエラーになって起動しなかったりします。その逆もしかりです。

今までのコマンドベースで構築した環境・仮想マシンを捨てて、新しく BVCP 環境に移行するか、コマンドラインベース環境と同居するか悩みます。が、やっぱ GUI 環境のほうが楽だね。になると思いますが・・f(^^;;。

 
5.そろそろエンディング
前回のエントリでは Intel Celeron N5105 な NiPoGi GK3Pro ミニ PC で VMwareESXi が動作しないような環境(動作したとしてもデバイスを認識しないような PC の構成)においても FreeBSD が動作するのであれば bhyve による仮想環境が構築可能である。と記載しています。
そこに今回 GUI ベースで bhyve を動作させることにより、ますます bhyve のしきいが低くなりました。これで楽しさが広がりますねぇ;-)。

これは僕の仮想マシン一覧になりますが、母艦は FreeBSD/amd64 14.0-RELEASE で動作しております。仮想マシンとして動作している freebsd03 は FreeBSD/amd64 13.2-RELEASE で、現在起動中です。
この freebsd03 内では qemu を利用した chroot で中に入る環境があって、そこは FreeBSD/arm64 13.2-RELEASE の環境が構築されており ports のコンパイルなどを行っております。

こんな非常にややこすぃーい環境も構築できるのが良いっ!! ;-P

1月 272024
 

前回の Beelink MINI S 購入に引き続き、もう一個 MINI PC を購入してみしました。

と、いうのも比較的小型の OS が可動する装置としては Raspberry Pi を持っているのですが、どうも FreeBSD 14.0-RELEASE を arm7 とか arm64 で動作させるのに嫌気が差してきて『素直に amd64 で良いじゃん。』と、なり、今回の MINI PC の購入となったのでありました。

今回購入したのは NiPoGi GK3Pro ミニ PC というらしいです。これは Intel の第 12 世代プロセッサである Intel Celeron N5105 を搭載しています。メモリは 8GB で SSD は 256GB です。このスペックで 15,000yen 前後なので、随分と安い。今だと Raspberry Pi 4 とかと同じくらいではないかなぁ・・。値段的にも一緒であれば、 arm64 でなくとも良いよねぇ。みたいな・・。

ただ、値段が安いだけのことはあります。SSD は NMVe ではなく、SATA 接続の M2.SSD です。

安さの秘訣を一覧にしてみましょう。あ。全て FreeBSD/amd64 14.0-RELEASE で認識した内容です。

  • SSD は上にも書いた通り M2 SATA で 256GB の容量
  • サウンドカードは USB 接続の C-Media Electronics Inc. USB Audio Device で snd_uaudio.ko で認識
  • Bluetooth も USB 接続で Realtek Bluetooth Radio で ng_ubt.ko で認識されますが利用できるかは知りません
  • WiFi は Realtek RTL8821CE で if_rtw88.ko で認識できますが、まだ利用できません。これは PCIe にぶるさがっているっぽい

 
この辺りで基本的にプライスダウンしている感じでしょうか。ほとんどのデバイスが USB にぶるさがっているので BIOS の画面から Disable にできません。『FreeBSD で利用できないデバイスなんて要らないよー。』とか思って BIOS 画面覗いても Disable にする項目がないです・・。orz

pciconf -lv してみると none が 11 個もありますが、これは Intel の Celeron プロセッサを使っている PC のパターンでしょうか。

あと、悲しいことに、最近の PC のはずなのに USB-C ポートがありません。これは結構ショックでかい・・。orz。

 
この PC の使い方
さてと。気を取り直して・・。
例の如く、この手の中華製 MINI PC は付属の WindowsOS の出どころが非常に怪しいので、サクっと削除。
Windows Product Key Viewer という Windows のプロダクトキーを確認するアプリでチェックしてみると、やはり “B” のみが並んでおりました。これは Beelink SER4 を購入してチェックしたときにと一緒ですね。

しょーがないので FreeBSD 専用の PC にすることにしました。チョイスした OS は FreeBSD/amd64 14.0-RELEASE です。 CPU の Intel Celeron N5105 には Intel のバーチャリゼーション機能が搭載されているので vmm.ko を kldload した場合は bhyve で仮想環境が構築でき、また、起動時に vmm.ko を kldload していなければ virtualbox が起動できます。

この手の MINI PC って VMware ESXi が動作しなかったり、動作してもデバイスを認識してくれなかったりするので FreeBSD をインストールして仮想環境を構築するのはアリです。まあ、 VMware ESXi は Broadcom に買収されて、その後無料版の VMware ESXi がなくなることになるので FreeBSD+bhyve は今のところチョー注目株です;-)。
AlmaLinux+Docker の環境よりしきいが低いですかね。

ただ、その場合、メモリ 8GB はちょっと量が少ないので 16GB に拡張したほうが良いですかね。
Intel の Celeron N5105 のサイトを見ると対応メモリは 16GB までのようです。

HDMI の上の黒いパーツのネジを一本外して、横にスライドさせると内部にアクセスできます。

MINI PC の上のフタを開けると 2.5 インチの SATA SSD が装着できます。その下にメモリスロットが一個あって default で 8GB のメモリが入っいます。メモリ換装は簡単そうです。 M2.SATA SSD を換装するか、換装せずに 2.5 インチ STAT SSD を増設するか、微妙ではありますね。

ちなみに、上記の写真に写っているのは銅板ではありません。ただ単にテカリのあるプラスチックです:-|。

 
あ。そーそー。この MINI PC は、一個目の HDD として追加の 2.5 インチ STAT SSD が認識され、内蔵の M2.SATA SSD は二個目として認識されます。ちょっとーっ!! この辺りもおかしいよねぇ・・。 orz

以下は mount コマンドの結果。

/dev/ada1p2 on / (ufs, local, soft-updates, journaled soft-updates)
devfs on /dev (devfs)
/dev/ada1p1 on /boot/efi (msdosfs, local)
/dev/ada1p3 on /home (ufs, local, soft-updates, journaled soft-updates)
/dev/ada1p4 on /usr (ufs, local, soft-updates, journaled soft-updates)
/dev/ada1p5 on /var (ufs, local, soft-updates, journaled soft-updates)
/dev/ada0p1 on /opt (ufs, local, soft-updates)
<以下略>

 
何もかも怪しい筐体です・・。orz。

 
FreeBSD もインストールしたし virtualbox に WindowsOS もインストールしたので、これは外に持ち出しも OK っぽい。
仕事でデータセンタ行ったとき、IP アドレス付加したあとに inetd 経由で sredird が動作すればポートサーバ風に利用できてコンソール接続も可。なんてこともできるし。

小さいので夢が膨らみます;-)。

 
最後にですが、全然デバイスが認識できていない pciconf-lv の結果を添付してこのエントリは終了とします;-)。

hostb0@pci0:0:0:0:      class=0x060000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x4e24 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4e61 subvendor=0x8086 subdevice=0x2212
    vendor     = 'Intel Corporation'
    device     = 'JasperLake [UHD Graphics]'
    class      = display
    subclass   = VGA
none0@pci0:0:4:0:       class=0x118000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x4e03 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Dynamic Tuning service'
    class      = dasp
xhci0@pci0:0:20:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4ded subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
    subclass   = USB
none1@pci0:0:20:2:      class=0x050000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4def subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = memory
    subclass   = RAM
none2@pci0:0:21:0:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Serial IO I2C Host Controller'
    class      = serial bus
none3@pci0:0:21:1:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de9 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Serial IO I2C Host Controller'
    class      = serial bus
none4@pci0:0:21:2:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dea subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
none5@pci0:0:22:0:      class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4de0 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Management Engine Interface'
    class      = simple comms
ahci0@pci0:0:23:0:      class=0x010601 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dd3 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = mass storage
    subclass   = SATA
none6@pci0:0:25:0:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc5 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
none7@pci0:0:25:1:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc6 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
sdhci_pci0@pci0:0:26:0: class=0x080501 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc4 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = base peripheral
    subclass   = SD host controller
pcib1@pci0:0:28:0:      class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x4db8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:1:      class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x4db9 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-PCI
none8@pci0:0:30:0:      class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = simple comms
none9@pci0:0:30:3:      class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dab subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus
isab0@pci0:0:31:0:      class=0x060100 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4d87 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = PCI-ISA
hdac0@pci0:0:31:3:      class=0x040300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4dc8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake HD Audio'
    class      = multimedia
    subclass   = HDA
none10@pci0:0:31:4:     class=0x0c0500 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da3 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake SMBus'
    class      = serial bus
    subclass   = SMBus
none11@pci0:0:31:5:     class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x4da4 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Jasper Lake SPI Controller'
    class      = serial bus
re0@pci0:1:0:0: class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
rtw880@pci0:2:0:0:      class=0x028000 rev=0x00 hdr=0x00 vendor=0x10ec device=0xc821 subvendor=0x10ec subdevice=0xc821
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8821CE 802.11ac PCIe Wireless Network Adapter'
    class      = network

 
では。さようなら。

11月 042023
 

ずいぶんと久しぶりに iPhone を買い替えました。 そもそも iPhone は高いモノなので、ここのところ何回か Android 端末を購入していたのですが、今まで利用していた iPhone8 はいよいよ最新の iOSが動作しなくなる。とのことなので一番新しい iPhone15 を購入することにした。

ちなみに iPhone8 を購入したのは 2017 年 10 月とかになってます。途中、二年ほど使用したあと、一回リコールで本体を交換しています。その後更にバッテリー交換を一回。いやぁ。ずいぶんと iPhone8 を使い続けたものでした;-)。

 
今回は iPhone15 を購入しました。一番安い端末ですが、以下の点が購入の決め手でした。

  • 価格が安い
  • ダイナミックアイランド搭載
  • USB-C が利用可
  • そもそも iPhone8 は iOS17 に対応していない
  • iPhone8 のバッテリがだいぶヘタってきた

まぁ、フツーに誰もが新しい iPhone に買い換える要因と言えるでしょうか・・。あ。写真は macOS を介した iPhone8 のデータ移行中。

購入履歴的エントリな意味合いが濃いのでネタに特化した記事内容などは特にないです。と、いうか、iPhone とか iOS についてはそこいら中にネタがゴマンとあるのであえて書かなくても良いかぁ。みたいな雰囲気;-)。
カメラがどうとか、ロック解除とかとかいまさら書くことも無いでしょみたいな。

 
あ。チタンのこと、書いておきましょうか。実は、僕はもうかなり前からチタン信者で、 iPhone15 Pro で『チタンボディ』と言われて「あぁ。なるほどねぇ♪」的な状態です。無理して iPhone にチタン無くとも・・。みたいな、半分負け惜しみ的な・・。;-P。

まず、腕時計。左側がステンレス、右側がチタン。いやぁ。二つを比べるともう、持った段階で全然違う。

実は、右側のシチズンの腕時計はもう 10 年くらい前に買っているんだけど、購入時に同じモデルでもステンレス製とチタン製の両方があって・・。チタン製を持った瞬間「あ。こっちください。」となりました。それくらい軽さにインパクトがあった。

 
もう一個チタンで一式揃えているのはキャンプ道具。コッヘル・マグ・スプーン・フォークはチタンは当たり前で、ペグまでチタンで揃えています。これはザック背負って山行きの時などは本領発揮する(のではないか)と、思っています;-)。

と、いうことで、別なところで軽さが必要な部分にはもう、チタンを導入しているので iPhone には無理にチタンは必要ねぇだろう。と、いうのが今回頭のスミのほうにありました;-)。

 
さてと。ネタ的に、もうひとつ書くとしたら USB-C でしょうか。

まず、iPhone15 の USB-C は USB2.0 の速度と、言われています。まぁ、写真や楽曲の転送くらいなので USB3.0 の転送速度でなくとも良い感じ。

充電速度は速くないかなぁ。どちらかというと遅い感じ。これは接続している USB ポート側の電力供給力の問題でもあるのかもしれない。

 
ただ、USB-C は偉大です。

実はテレワークのために会社支給の NotePC を自宅で使うために USB-C の HUB を購入しました。

この USB-C な HUB は USB ポートにキーボードとマウスを接続し HDMI も接続して、画面転送できるというしろモノ。写真的にはこんな感じ。あ。USB-C なので、当然電源供給もできています。

もともと NotePC の USB-C ポートに接続するために購入して、テレワークのために利用するのでケーブル類はずっと付けっぱなし。これを iPhone15 に接続したところ・・。

おやおや。iPhone の画面が HDMI で接続したディスプレーに表示されました。 iPhone15 を横にして U-NEXT アプリでアニメを鑑賞してみるとディスプレーにはフル画面で、横表示で再生してくれます。すげっ。

これについては Android 端末も脱帽でしょう。ただ、僕が普段、エントリーレベルの Android 端末を利用しているために『default で画面を HDMI 表示』してくれるモノを購入していないののかもしれないですが・・。

画面の他にキーボードはフツーに文字入力できます。マウスもフツーに使えてクリックしてアプリが起動します。

USB-C な iPad 持ってないんだけど、それと似たような感じなのかな? USB-C はやっぱり良いっ!! てのは確認できました。いやぁ。 iPhone15 が出るまで待って(と、いうか USB-C 対応の iPhone が出るまで待って)いて良かった。

 
しかし、iPhone15 の画面をディスプレーに映す機会がどれだけあるのか微妙です。例えば U-NEXT は PC でも閲覧可能なので無理して iPhone15 の画面を HDMI 接続してディスプレーで見る必要ないし・・。既に mac mimi 持っているので iPhone15 にキーボードやマウス付ける必要ないし・・。

あ、そー言えば、 mac mini から外部カメラとして利用でけた。この機能も iPhone8 には無かった機能だ;-)。

 
とまぁ、こんな感じで普段使いで既に利用している感じ。今回は Apple ストアで購入しました。今まで利用していた iPhone8 は 9,000yen で Apple に引き取ってもらいました。
iPhone15 は 9 月中頃に注文して、届いたのが 10 月 03 日でした。約一ヶ月ほど使い込んでのエントリ記載。と、いう感じです。

 
最後にですが、 iPhone8 から iPhon15 にしたら『ギガ』の減り方が早いですな。まぁ、iPhone15 が目新しくて使い続けてしまった。と、いうのもあるかもしれませんが、 5G に接続するようになったから。と、いうのも起因しているかもしれません。 Y!mobile の 3 ギガのプランでは『ギガ』が足りないかも・・。

5 ギガプランを契約している IIJmio や、ギガ活でほぼ無料で利用している povo2.0 にオフロードしないとやっていけない雰囲気・・。

上手に SIM を使うようにして行こう。と、思う今日この頃。

9月 282023
 

いやぁ。まいった。 FreeBSD 14-RELEASE/amd64 になったら if_iwlwifi.ko が正常動作するようになって FreeBSD でいよいよ待ちに待った WiFi6 が利用できるようになるのかと思いきや・・。
ぜーんぜんそんなことはなくて FreeBSD 14.0-BETA3 で bhyve から Intel AX200 を試してみたけど、やっぱり 802.11a 止まりですな。 802.11ac さえも相変わらず利用できない。一体いつまで待てば FreeBSD で高速な WiFi が利用できることになるのやら・・。

ちなみに FreeBSD 13.2-RELEASE/amd64 では一応 if_iwlwifi.ko は 802.11a では利用可能になりました。しかし、これが suspend/resume に対応していない。 resume すると利用不可になるデバイスなのでまるで利用する気にならない・・。orz。
なので、僕はずっと USB な if_rtwn_usb.ko を利用しています。一応 802.11a での通信になってしまうのだけど supend/resume には対応しているので、そこはかとなく使い続けている状態です。

 
今回は、今 FreeBSD をインストールして利用している ThinkPad X13 で Intel Wi-Fi 6 AX200 を 802.11ac or ax で利用するために bhyve を利用して ubuntu をインストールします。
そして ubuntu 側で Wi-Fi 6 AX200 を利用するのですが、一応、前提条件を書いておきます。

  • 今回 ubuntu はルータとして利用しません。IPv4/IPv6 のデアルスタクにすると設定むづかしくてしょーがない・・。
  • 母艦の FreeBSD はネットワーク的にはフツーに通信できる状態として、それとは別にブリッジ経由で bhyve の ubuntu と通信します。
  • データのやり取りは bhyve な ubuntu 側の wlp0s6 を利用し、母艦の ThunPad X13 上の FreeBSD に橋渡しします。
  • 母艦の FreeBSD の /home/takachan を bhyve な ubuntu に NFS マウントするとこでデータ転送の手間を省きます。

 
上記を図にするとこんな感じ。

 
母艦側の FreeBSD の default gateway を bhybe の ubuntu の 172.16.1.11 にすると母艦側の通信は ubuntu の wlp0s6 を抜けて WiFi6 な通信が可能になるのだけど、戻りパケットの設定などを上位のルータに設定して上げる必要があったりとか、IPv4/IPv6 デアルスタクにすると色々ややこしくなるのでやめました。

 
では、母艦の FreeBSD に必用な設定と bhyve 側 ubuntu のインストールと設定を見ていきましょう。

 
1. FreeBSD 母艦側の設定
まず、 FreeBSD の母艦側の設定を行います。

今回、 bhyve を動作させるために、まず packages をインストールします。今回はこれだけインストールしました。

$ pkg info | grep bhyve
bhyve-firmware-1.0_1           Collection of Firmware for bhyve
edk2-bhyve-g202308_3           EDK2 Firmware for bhyve
uefi-edk2-bhyve-csm-0.2_4,1    UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
vm-bhyve-1.5.0                 Management system for bhyve virtual machines

 
続いて起動時の設定を行います。

 
o./boot/loader.conf

# bhyve
vmm_load="YES"
hw.vmm.amdvi.enable=1
pptdevs="2/0/0"

 
bhyve を利用するには vmm.ko を kldload する必要があります。そして hw.vmm.amdvi.enable=1 にします。
しかし、 vmm.ko は仮想環境で排他利用となります。以前のエントリで書いていますが VirtualBox を利用する場合は vmm.ko を kldunload する必要があります。

pptdevs=”2/0/0″ は pciconf -lv で確認した PCI デバイスを bhyve で利用するための設定です。以下は pciconf -lv の例です。

$ pciconf -lv | grep -A 3 iwl
iwlwifi0@pci0:2:0:0:        class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0080
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6 AX200'
    class      = network

 
if_iwlwifi.ko を利用したデバイス iwlwifi0 は PCI バスの 2:0:0 に割り当てられているので、/boot/loader.conf で上記のように割り当ててあげます。

次に bhyve の起動設定です。

 
o. /etc/rc.conf

vm_enable="YES"
vm_dir="/opt/bhyve"

 
vm_enable=”YES” と vm_dir=”hoge” を設定しました。他に zfs のオプションとかなんか色々あるみたいですが、ひとまず不要なので省き、一番簡単な設定のみとしました。

これで一旦再起動します。

 
2. bhyve の準備と OS のインストール

o.ネットワーク設定
bhyve では仮想スイッチを利用します。まぁ『仮想スイッチ』と、言ってもただ単にブリッジインターフェースを作成するのみです。

母艦側 FreeBSD のネットワークの状態は lo0 と wlan0 があるのみです。 wlan0 は if_rtwn_usb.ko を利用した 802.11a で 5G の周波数に接続するフツーの NIC です。

ここに bhyve の ubuntu と通信するための『仮想スイッチ』を準備してしてあげます。

# service vm start
# ifconfig tap0 create
# sysctl net.link.tap.up_on_open=1
# vm switch create -a 172.16.1.1/24 public
# vm switch add public tap0
#
# ifconfig -a
lo0: flags=8049 metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
<一部略>
wlan0: flags=8843 metric 0 mtu 1500
        inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::20f:ff:fe8d:2c72%wlan0 prefixlen 64 scopeid 0x2
        inet6 2001:470:fe36:5678::32:1 prefixlen 64
<一部略>
vm-public: flags=8843 metric 0 mtu 1500
        ether 3e:ce:d6:69:ff:84
        inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap0 flags=143
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        groups: bridge vm-switch viid-4c918@
        nd6 options=9
tap0: flags=8943 metric 0 mtu 1500
        options=80000
        ether 58:9c:fc:10:fc:0e
        groups: tap
        media: Ethernet autoselect
        status: no carrier
        nd6 options=21
        Opened by PID 2627

 
bhyve で利用する tap0 を作成します。次の sysctl はまぁ、おまじない。次に『仮想スイッチ』を public という名で vm switch create します。ついでに IP アドレスを付加します。

ifconfig -a で確認すると vm-public と tap0 が作成されました。
vm-public は bridge インターフェースで vm switch add public tap0 コマンドにより tap0 を内包しています。かつ vm-public には 172.16.1.1/24 の IPv4 アドレスが付きました。 bhyve 側の ubuntu は FreeBSD 側から見ると tap0 ですが ubuntu 側では enp0s2 として認識してそこに 172.16.1.11/24 のアドレスを付加すると母艦と bhyve 側の ubuntu で通信が可能になります。

母艦側の wlan0 は全く触ることはありません。

 
ネットワークの設定ができたので、bhyve の ubuntu をインストールしていきましょう。

まず、原型を作成します。

# service vm start
# vm create -t ubuntu ubuntu
# cd /opt/bhyve
# ls -aCF
.config/    .img/       .iso/       .templates/ ubuntu/
#
# vm install ubuntu .iso/ubuntu-23.04-live-server-amd64.iso
<以下略>

 
/etc/rc.conf に記載した vm_dir の /opt/bhyve の下に色々できています。 /opt/bhyve/.templates/ の下にファイルを一個作成します。

o./opt/bhyve/.templates/ubuntu.conf

loader="uefi"
cpu=2
memory=2G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
graphics="yes"
graphics_port="5900"

 
このファイルを作成して、iso イメージを /opt/bhyve/.iso/ に設置してから vm install ubuntu を実行しましょう。そして、インストールします。あ。なんか、 ubuntu23 はメモリが 512MB ではインストーラが起動しないようです。1GB とか 2GB のメモリ量にしてあげましょう。

インストール中はネットワークは利用できないので利用する iso イメージは最低限インストールできるものをチョイスします。

これでイントールは完了しましたかねぇ。

o. bhyve の ubuntu の起動スクリプト

#!/bin/sh

case $1 in
'start' )
    bhyve -c 2 -m 1G -w -H -S \
          -s 0,hostbridge \
          -s 1,virtio-blk,/opt/bhyve/ubuntu/disk0.img \
          -s 2,virtio-net,tap0 \
          -s 3,fbuf,tcp=0.0.0.0:5900 \
          -s 4,xhci,tablet \
          -s 5,lpc -l com1,stdio \
          -s 6,passthru,2/0/0 \
          -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
          ubuntu
    ;;
'tm' )
    tmux new-session -d -s mugi-ubuntu 'sudo /opt/bhyve/bin/vm_ubuntu.sh start'
    sleep 3
    ifconfig tap0 | grep status
    ;;
'stop' )
    bhyvectl --force-poweroff --vm=ubuntu
    ;;
'ls' )
    bhyvectl --get-stats --vm=ubuntu
    echo;echo
    echo "tmux list-sessions"
    echo "tmux attach -t ubuntu"
    ;;
'*' )
    echo vm_ubuntu.sh { start | stop | ls | tm }
    ;;

esac

exit 1;

 
bhyve でゲスト OS を起動するにはずいぶんと難儀です。上記のスクリプトは /opt/bhyve/bin/vm_ubuntu.sh という名で準備しました。
ちと、説明が必要ですかね。

まず、 start オプションのパラメータですが、-s は PCI BUS を想定してください。ディスク・ネットワーク・コンソール・USB、そして pptdevs で渡された Intel Wi-Fi 6 AX200 になります。このパラメータでまず、ubuntu が起動できるかと思います。

しかし、ここまでたどり着くまでにはずいぶんと色々苦労したので bhyve の起動オプションは本当に難儀したぞぉ。簡単に bhyve の ubuntu とか FreeBSD が起動するとは思わないほうが良い。色々検索して情報を探してくだされ。 BIOS でのブートとか UEFI でのブートとか、google に聞くと古い情報とかごまんとあって、最新の情報を拾ってくるのは中々悩ましい・・。

 
次の tm オプションですが、これは tmux を介してバックグラウンドで動作させます。 tmux については個別に勉強してください。コマンドのサワリだけ書いておきます。

# tmux list-sessions
ubuntu: 1 windows (created Wed Sep 27 12:31:41 2023)
# tmux attach -t -ubuntu
<以下略>

 
tmux list-sessions で tmux のセッションを確認して、そのセッションに tmux attach -t -ubuntu でアタッチするとコンソールが表示されます。コンソールから抜けるには tmux のコマンド C-b d を打ちます。

もしかしら ubuntu では tmux 使えないかも・・。
もうひとつのコンソールへのアクセス方法があります。 ports から net/tigervnc-viewer をインストールします。そして、以下のコマンドを打ちます。

$ vncviewer localhost:5900
<以下略>

 
上のほうで /opt/bhyve/.templates/ubuntu.conf というファイルを作成しましたが、そのとき graphics_port=”5900″ を指定していると思います。また bhyve 起動時にも -s 3,fbuf,tcp=0.0.0.0:5900 というオプションを指定しています。これが vncviewer でアクセスするポートになります。

コンソールに接続できたので ubuntu の設定を色々していくことにします。まぁ、僕は ubuntu はあまり得意ではありませんので、このあとはサワリだけ説明することにします。

そして、次に行きます。

 
3. 母艦と bhyve の ubuntu との通信
bhyve の ubuntu 側で ip addr をたたくと以下のインターフェースが確認できると思います。

$ ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp0s2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlp0s6:  mtu 1500 qdisc noqueue state UP group default qlen 1000

 
enp0s2 が 母艦側との通信インターフェースで wlp0s6 が WiFi6 です。

まず、母艦の 172.16.1.1 と通信する enp0s2 設定からです。

o./etc/netplan/99-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s2:
      dhcp4: false
      addresses: 
        - 172.16.1.11/24
#     gateway4: 172.16.1.1
      nameservers:
        addresses: [192.168.1.34]
        addresses: [192.168.22.251]

 
さーっ!! yaml の設定に悩んでくだされーっ!! なんでまともに設定できんのだ?! とウンザリすることでしょう・・。orz
設定完了後 sudo netplan apply のコマンドを打って、で設定を反映して、そしてうんと怒られてください;-P。

無事に設定が完了すると、FreeBSD 母艦と bhyve との間の 172.16.1.0/.24 のセグメントで通信ができるようになります。

ここまでできたら母艦側から ssh 接続できるようになるので、作業が格段にしやすくなります。

 
続いて wlp0s6 側の設定を見ていきます。 enp0s2 は母艦との接続のためだけのインターフェースですが wlp0s6 は外部との通信を行います。 ubuntu は WiFi6 に対応しているので Intel Wi-Fi 6 AX200 を利用する通信はむちゃくちゃ速いです。

o./etc/netplan/50-cloud-init.yaml

network:
    wifis:
        wlp0s6:
            optional: true
            access-points:
                "AP80211AX":
                    hidden: true
                    password: "PASSWORD"
            dhcp4: false
            addresses:
              - 192.168.1.48/24
              - 2001:470:fe36:abcd::48:1
            gateway4: 192.168.1.1
            nameservers:
              addresses: [192.168.1.34]
              addresses: [2001:470:fe36::ffff:34]

 
WiFi の SSID は AP80211AX で パスフレーズは PASSWORD です。この AP はステルス機能を有効化しているので hidden: true を設定しています。
IP アドレスについては IPv4/IPv6 デアルスタクです。 IPv4 gateway は設定していますが IPv6 gateway は ra で降ってきます。ネームサーバも IPv4/IPv6 両方のアドレスを指定しました。

これまた書き方にうんと悩んだあと sudo netplan apply のコマンドを打って設定を反映して、そしてうんと怒られてください;-P。

これで ubuntu 側の設定は完了です。

 
4. bhyve の ubuntu の設定と実際に利用してみる
ubuntu では設定というか、dep を apt-get install で色々好きなものをインストールしてください。
ここでは特には書かないです。

唯一必要だったのが NFS クライアント側の設定でしょうか。母艦の FreeBSD 側で NFS Server を有効にして /etc/exports を書きます。 /home/takachan を NFS のマウントポイントとして 172.16.1.0/24 から許可します。
ubuntu 側では /etc/fstab に母艦の FreeBSD の /home/takachan を /home/takachan/takachan 辺りにマウントするようにします。

NFS の設定が完了したら、試しに iso イメージをダウンロードしてみましょう。

まずは母艦の FreeBSD で wget を実施し、次に ssh で bhyve の ubuntu にログインしたあとに wget してみました。

$ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 1%[                    ]   7.35M  1.84MB/s   残り3m 49s  
^C
$ ssh 172.16.1.11
ubuntu $ cd takachan
ubuntu $ wget http://ftp.iij.ad.jp/pub/FreeBSD/releases/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-amd64-bootonly.iso
FreeBSD-14.0-BETA3-amd64 4%[>                   ]  20.66M  10.2MB/s   eta 38s
^C
ubunru $

 
母艦側の FreeBSD のホームディレクトリで wget で iso イメージを取得すると大体 16Mbps の速度が出るか出ないか。これは USB の if_rtwn_usb.ko を利用して 802.11a で通信する FreeBSD で一番速い WiFi の速度です。
次に bhyve の ubuntu に ssh して NFS マウント先で wget すると FreeBSD側 の $HOME で wget するのと同じ状態になります。ただ、ubuntu 側で wget すると速度が全然違い 80Mbps 出ています。これは Linux での iwlwifi ドライバが正常に動作していることを示しています。そして、この速度はうちの外部接続ネットワークの限界です。

 
宅内の他の PC やサーバとデータをやりとりするときは ubuntu 側の 192.168.1.48 側のアドレスでデータをやり取りすることにより高速に転送することが可能です。

 
こんな感じで、いつまで待っても FreeBSD で WiFi の 802.11ac or ax が利用できないのを bhyve の ubuntu で通信速度を稼ぐ。と、いうちょっと荒業を、今回は使ってみました。

おかげで bhyve にずいぶんと詳しくなったぞぉーっ!! みたいな f(^^;;。

一点だけ注意点があるかも。母艦の FreeBSD は suspend/resume に対応していても bhyve で動作する OS が動作しないかな? FreeBSD の resume 後 vm lsit で Running 状態だったゲスト OS は動作がおかしくなる傾向が見受けられました。
が、これは当然でしょうかねぇ・・。考えてみると FreeBSD 側で Intel Wi-Fi 6 AX200 は supend/resume に対応してないので、たとえ pptdevs で ubuntu に渡していても resume 後は利用出来ない状態に陥ります・・。orz。

FreeBSD 14-R で if_iwlwifi.ko が suspend/resume に対応してくれるとともっと幸せになれるのだけれど、それはリリースされてみたいと解らないかなぁ。

 
と、いうことで、皆さんもせっかく持っている内臓の、 FreeBSD では中々利用できない Intel 系の WiFi チップ。 bhyve の ubuntu で有効利用するのもありなのかなぁ。と、いうのが今回のネタだったのでありました。

bhyve のこと、今後、ネタとして書く機会あるかな?

7月 012023
 

「リコリス・リコイル」をアニメ好きの人に教えてもらって見たら、確かに面白い。会社への往復で、スマートフォンで U-NEXT で見てたらなんとっ!! 『ギガ』が 4 ギガくらい消えて無くなった。 DVD で見るようにしたんだけど、画質が違うのねぇ。 U-NEXT などはテレビに対抗しないとならないので、画質がずいぶんと綺麗で驚いた次第・・。今更、 DVD もねーぞー。みたいな。

 
と、いうことでいきなりアニメの話ですが・・。

「リコリス・リコイル」の中に登場する『喫茶リコリコ』の風景。

コレ見るとさぁ・・。どうみても座布団が CPU に見えてしまうのよ。僕・・。

日本全国探しても、喫茶リコリコの座布団が CPU に見えてしまうのは僕だけだろうなぁ。

二枚の座布団は千束とたきなで使っているので、実質 6Socket なマザーボードなのだろうなぁ。みたいな;-)。あ。けど、実質 4Socket で千束はどこからか一枚持ってきたのかな?

 
と、いうことで座布団と CPU の比較。これがなくてただキャプチャ上げただけだと、著作権法にひっかかる。

とりあえず、手持ちの CPU で土台がムラサキでコア部分が金色の CPU を 6 枚並べてみた。

おーーっ!! 喫茶リコリコだぁっ!!

『本当に、座布団が CPU に見えるんですね。』 (たきな風に読んで;-)
『そーよっ!! すごいだろぉ。 ウォールナットもロボ太も持ってねーぞ。』(千束風に読んで;-)

あ。第 5 話の最後の部分ね;-P。

 
今度は P54C を並べてみた。あ。486 も混ざっているけど;-)。

ふむー。これはちょっと違うか。やっぱりコア部分がゴールドに輝いていたほうが座布団に見える。

せっかくなので Athlon も並べてみた。

土台がセラミックなのは 4 個しか持ってなかった・・。

で、このままでは Intel がかわいそうなので、Socket370 も並べてみた。

こちらは黒土台にシルバー。Celeron Dual な CPU。ピンのマークがあるけど、座布団に見えなくも無い。数が足りなかったので緑のヤツも並べました。

 
と、いうことで、非常にバカなことをしているようだが、見えてしまったものはしょーがない。実際に並べてみて『あぁ。やっぱり座布団は CPU に見えるよねぇ。』と、実感するのであります。

皆さんはどう思います? ;-P。

 
このサイトでは「リコリス・リコイル」の画像を著作権法第 32 条に定める比較研究を目的として引用しました。
「リコリス・リコイル」は Spider Lily/アニプレックス・ABCアニメーション・BS11 の著作物です。

6月 282023
 

自分でも、強引な手法だなぁ。と、思ってしまいます。

まず、 Windows11 Pro 上で動作している Hyper-V サーバがあります。その下で FreeBSD/amd64 13.2-RELEASE が動作しております。

Hyper-V の母艦である Windows11 Pro は NotePC なので WiFi 使ったり RJ45 使ったり VPN 使ったりするので Hyper-V のサーバとクライアントの間の「仮想スイッチ」はブリッジ、それはつまりは仮想スイッチマネージャの「接続の種類」で[外部ネットワーク]を選択することはほぼ不可能(利用する物理ネットワークによって毎回変更する必要がある)なのであります。

母艦側で複数のネットワークアダプタを利用する場合は、どうしても NAT、それはつまりは[内部ネットワーク]をチョイスするしかないのであります。

Hyper-V の仮想スイッチが NAT になると、色々と制約を受けます。まず、 DHCP を克服する必要があります。これについてはウェブ上に、設定方法について、色々書かれたドキュメントがあるのでそちらを参考にしてください。

いろいろ設定すると Hyper-V のクライアント (俗に『仮想マシン』と、言いますな) は NAT 配下で、固定 IPv4 アドレスで動作させることが可能になりました。

Hyper-V の母艦からは仮想マシンに対して ssh などのアクセスができるようになります。が、当然リモートのマシンからは Hyper-V 管理下の仮想マシンへはアクセスできません。

あと、仮想マシンのネットワークは NAT が入るのでこれまた色々と制約受けます。上に書いた、外部からのアクセスができません。他に NFS マウントできません。 gif トンネル張れません。とか・・。

 
そもそも、 Hyper-V の母艦の外部のネットワークに IPv6 がない場合、仮想マシンは IPv6 を利用することができません。あれ? Hyper-V の NAT 仮想スイッチで IPv6 喋れるのか?

どうして仮想マシン側に IPv6 が欲しいのだ? -> だって、IPv4 は NAT なので上記の制約受けるじゃん。それなら、トンネルでも良いから IPv6 でどっかーんっ!! と抜けていきたいじゃん。

と、いうのが発想の原点にあります。

と、いうことで図を書いてみました。

簡単に説明します。

  • 真ん中に Windows11 Pro の Hyper-V サーバがいます
  • Windows11 Pro の Hyper-V サーバは上位のネットワークとは IPv4 アドレスのみが降ってくるネットワークに接続しています
  • Hyper-V 配下の仮想マシンは FreeBSD/amd64 13.2-RELEASE です
  • Hyper-V サーバと仮想マシンの間には NAT の仮想スイッチが入っています
  • NAT の仮想スイッチは仮想マシンが固定 IPv4 アドレスを利用できるようにしています

 
これが現状、フツーにできる Hyper-V 環境です。この状態で、仮想マシン側に IPv6 グローバルアドレスを付加して、IPv4 の NAT 超えをあきらめ、IPv6 で外部との通信をできるようにして色々楽しめる状態にします。

  • 仮想マシンの FreeBSD は wireguard で外部に接続します
  • wireguard で作成した VPN トンネルの中に gif トンネルを通します
  • 仮想マシンに IPv6 が通ったので様々通信ができるようになります

 
トンネルの多段ですね。
図の左側は VyOS と wireguard のサーバは別々に描かれていますが、最近の VyOS を使うと一個にまとめられると思います。僕の環境では未だに VyOS-1.1.8 を利用していますので wireguard は別サーバに構築しました。

 
wireguard と VyOS の置き場所によって仮想マシンの IPv6 の通信速度は圧倒的に変わります。色々考えてみてください;-)。

と、いうことで、次に設定を見ていきましょうか。

 
1. 仮想マシン側の wireguard の設定
今回、仮想マシンは FreeBSD/amd64 13.2-RELEASE なので wireguard は ports から簡単に入ります。 net/wireguard をインストールしましょう。もしかしたら wireguard-kmod-0.0.20220615_1 がインストールされるかもしれませんが、実際には利用しません。

wireguard-kmod-0.0.20220615_1 をインストールした場合には /boot/modules/if_wg.ko がインストールされますが 13.2-RELEASE からは OS 標準で /boot/kernel/if_wg.ko が用意されています。フツーに wireguard_enable=”YES” すると /boot/kernel/if_wg.ko が利用されます。

僕の環境では wireguard-2,1 、wireguard-kmod-0.0.20220615_1 、 wireguard-tools-1.0.20210914_1 がインストールされました。

次に設定です。

が、その前に、まず最初に wireguard では鍵のペアを作成する必要があります。

# cd /usr/local/etc/wireguard/
# wg genkey > server.key
# wg pubkey < server.key > server.pub
#
# wg genkey > client.key
# wg pubkey < client.key > client.pub
# 
# chmod 600 *.key 
#

 
サーバ側とクライアント側のキーの両方を作成しましたが、これを利用します。

続いて設定を見ていきます。今回は wireguard のトンネルを一個作成するだけですので wg0.conf のみです。複数に接続する場合は wg1.conf wg2.conf などと設定フアイルを複数書きます。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = 8LJDuAU9Ste2ySHRmgHnOAyk+E4ZMbw+vCBbMHXMbZU=
Address = 192.168.254.11/32

[Peer]
PublicKey = 17CucZLVbS1Jt/8LXREvrDGEnYunIA2RYYjlJhxftlk=
AllowedIPs = 192.168.254.1/32, 10.20.65.201/32
Endpoint = 10.20.65.15:51820

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は作成した鍵ファイルの client.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。 wireguard で接続するためだけに利用するので /32 で指定します。ただ、サーバ側と同じレンジが良いでしょう。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は server.pub の内容を記載します。
  • AllowedIPs は wireguard サーバの wg0 インターフェイスの IPv4 アドレスを記載します。
  • AllowedIPs にはもう一個 IPv4 アドレスを記載します。 gif トンネルの接続先 IPv4 アドレスを “,” で区切って記載します。詳細についてはあとで書きます。
  • Endpoint は wireguard が動作しているサーバの IPv4 アドレスと Port 番号を記載します。

 
だいたいこんな感じで良いと思います。非常に簡単な設定ですね。ただ、一点。 [Peer] 側の設定の AllowedIPs の設定がクセモノです。
AllowedIPs に wireguard サーバ側の wg0 インターフェースの IP アドレスを書いただけでは wireguard サーバとしか通信ができません。

『wireguard サーバ側で NAT の設定を入れてないから他のネットワークと通信できんのか?』と思い、wireguard サーバ側の設定を色々いじってしまうのですが、そうではなく、クライアント側がどこと通信したいのか、AllowedIPs に記載することにより通信が可能となります。

今回は wireguard トンネルを抜けいてったあと gif トンネルを張りたいので VyOS の IPv4 アドレスを AllowedIPs に追加しました。 10.20.65.0/24 と通信したい場合は AllowedIPs には wireguard サーバの wg0 インターフェースの IPv4 アドレスと 10.20.65.0/24 を追加で書けば良いです。

で、自動起動するように設定を書きます。 /boot/loader.conf に明示的に if_wg_load=”YES” と書かずともカーネルモジュールがロードされます。

・/etc/rc.conf

wireguard_enable="YES"
wireguard_interfaces="wg0"

 
これでクライアント側の設定は完了です。

次にサーバ側の設定を見ていきましょう。

 
2. wireguard のサーバ側の設定
上のほうでも書きましたが、 wireguard のサーバは自前で用意せずとも VyOS で利用可能です。 VyOS-1.3 以降から wireguard に対応したんだったかな? 詳細なバージョンは覚えていませんが・・。

今回、僕は wireguard サーバも FreeBSD 側で作成しました。インストールは ports からですが、クライアント側のと同様のモノをインストールしました。

鍵は既に作成したので、それを使いまわしましょう。すると、サーバ側で用意するのは設定フアイル一個のみです。

・/usr/local/etc/wireguard/wg0.conf

[Interface]
PrivateKey = aJbypbTUy5LB+EIPd6FHf25D2rbTw9l+x5o7fBLL+Ec=
Address = 192.168.254.1/24
ListenPort = 51820

[Peer]
PublicKey = F8kvub6jdPnl99rISnffYtilNVEswDUo+sqGWzc7FRY=
AllowedIPs = 192.168.254.11/32

 
[Interface] の 設定は自分側の設定を記載します。

  • PrivateKey は server.key の内容を記載します。
  • Address は wg0 インターフェイスに付加する IPv4 アドレスです。

続いて [Peer] の設定で、これは wireguard のサーバ側に関する設定になります。

  • PublicKey は client.pub の内容を記載します。
  • AllowedIPs は wireguard クライアントの wg0 インターフェイスの IPv4 アドレスを記載します。

 
以上で設定は完了です。 /etc/rc.conf にクライアントのと同じ設定を追加して wireguard を起動します。サーバ側とクライアント側の両方で service wireguard start を実行すると wg0 インターフェースが生えてきます。

双方の wg0 の IPv4 アドレスに ping を打ち、到達性を確認します。この時点で ping が当たらない場合は設定情報が間違っています。なおしてください。そもそも wireguard のサーバとクライアントの物理インターフェース間で通信できることを確認します。

 
双方の wg0 に付加された IPv4 アドレスに ping が当たるようになったら OK。クライアント側の [Peer] 設定の AllowedIPs に記載した VyOS の IPv4 アドレスに ping が当たることを確認します。
上にも書いた通り 10.2.65.201 だけでなく、もっと他のマシンにも接続したい場合はクライアント側で設定してみてください。

 
最後に wireguard の wg0 トンネルをぬけて gif トンネルを掘ります。 gif トンネルが掘れると Hyper-V の仮想マシンにはグローバルな IPv6 アドレスが付加されます。 IPv6 を利用することにより IPv4 で受けていた NAT の制約から開放されることになります。パチパチパチっ!!

と、いうことで IPv6 gif トンネルの設定については以前書いているのでそつらを参考にしてください。

IPv6 Over IPv4 トンネルを dtcp から VyOSへ。

 
移動する PC 上で Hyper-V を動かしたとき、その下で動作する仮想マシンはネットワーク的に色々な制約を受けるモノです。今回は多段トンネルでその問題を解決してみました。

  • 仮想マシンは NAT ネットワークで gif トンネルが利用できないので wireguard なトンネルを掘る
  • wg0 を抜けて gif トンネルを掘る
  • IPv4 は NAT ネットワークなので IPv6 の直アクセスで NAT 問題を回避
  • 仮想マシンに IPv6 アドレスが付加されたので仮想マシンのネットワークはもーサイコーっ!!

 
こんな感じの手順で今回の構成を構築しましたが、フツーここまでやる?

ってか、まあ、Hyper-V が動作するのは WindowsOS なので、ネットワーク的に色々な制約が多すぎてやりたいことができない。
ネットワークはトンネルで抜けて色々やりましょう。と、いう雰囲気ですが・・。

一点だけ。まだ検証してないし、計算が必要だと思うのですが・・。 MTU って、一体いくつになるの? f(^^;;。

6月 042023
 

最近はテレワークから会社に出社するように変更したので、週に 3 回ほど会社に行くようになりました。会社に行く日は 05:30 起きです。

と、いうことで前ふりはここまで。

この間 05:30 に起きて部屋の中をうろちょろしていたらなんか臭うんですな・・。『なんだろ?この焦げ臭さ??』などと思っていたのですが、朝、近所で火事でもあったのか?と思ったけど消防車のサイレンとか特にない・・。

と、いうことで、夜中に何かしら動いていて怪しいのと思ったのは・・。まずはスマートフォンを確認。で、iPhone8 を触ってみたら熱い・・。『ふむー。夜中の充電中に熱が出たか?』と、思ったのだけど、なんか、ミョーに臭う・・。

ちなみに僕のスマートフォンの充電風景はこんな感じ。

都合 5 台のスマートフォンを充電しております。充電専用の台だったりしますが、この写真は今回の事件のあとに撮りました。iPhone の下のテーブルの黒いシミに注目。詳細はここからです;-)。

で、こちらは AC アダプタを接続するタップ。

コンセント単位にスイッチが付いているものをチョイスしています。少しでも安心・安全・電気を使わないように心がけての気持ちから。

 
で、今日は会社に行く日なので、チンタラチンタラできないません。とりあえず、充電器が接続されているタップのスイッチをオフにして出社。

出勤途中や会社で iPhone8 を使うと、やはり、ミョーに焦げ臭い・・。

と、いうことで家に帰って再度確認。

iPhone8 はケーブルではなく Qi 充電しているのですが、その充電器をひっくり返してみました・・。

あらぁ・・。(@_o)。

あぶねーっ!! 見事に焦げ付いていますっ!!

5V 2.4A の AC アダプタからケーブルを経由して Qi 充電器 (800yen くらいで購入した、どこにでも売っているツヤ) を接続し、その上に iPhone8 を載せて充電していたのですが・・。

木製のテーブルは Qi 充電器直下が炭になっております。

Qi 充電器が熱を帯びて、テーブルが焦げた雰囲気です。 (@_o)
異臭の原因は Qi 充電器が熱で熱くなり、プラスチック側が溶けだし、そのまま木製のテーブルを焦がした可能性があります。

もし、電源タップ側のスイッチをオフにせず、そのまま会社に行っていたら・・。Qi 充電器の上に iPhone がないとはいえ、Qi 充電器が通電していたとしたら、木製のテーブルが燃えだしていたかもしれません・・。『火事』ですな・・。orz

 
バッテリーが爆発するとかはよくある話ですが、 Qi 充電器も木のテーブルを焦がすほどのパワーがあるとは思いませんでした・・。

今回の教訓。

  • 触ってみて熱くなっているモノは壊れる前兆? 火が出る前兆?
  • スマートフォンを充電する場合は木製テーブルの上ではなく、鉄や石の上のほうが安全

皆様もお気をつけくだされ・・。

4月 292023
 

以前のエントリで「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」や「AlmaLinux8 の VRF。」なんてのを書いていますが、それの改訂版です。

 
なんか、色々調べてみると Linux 方面では bridge を有効にするには全部で三つの方法があるのだそうな。

  • bridge-utils を使う
  • nmcli を使う
  • ip link set dev を使う

 
以前の経験から、古いアーキテクチャである bridge-utils は既に rpm にもなっていない。かつ、IPv6 通信ができない。と、いうことでもう利用してはいけないのであります。IPv6 通信ができない。と、いうのは上記のリンクにも書いています。

nmcli を利用すると、設定情報は Almalinux8 の場合は /etc/sysconfig/network-scripts/ 配下にファイルとして保存してくれるんだけど、これが Almalinux9 になると、保存先が変わって記載方法も変わるのであまり使いたくない・・。

直感的に『あぁ。設定しているなぁ。』と感じるのは ip link set dev なコマンド達でしょうか。今回はこれをメインで bridge 設定をしていきたいと思います。

 
がっ!!

まず、 VRF の設定をしてルーティングテーブルを複数持つ環境を構築し、Docker コンテナを NAT なしで起動するための bridge 化。そしてっ!! 以前利用していた bridge-utils を捨てたのは Docker コンテナで IPv6 を利用するため。

と、いう、これはまさしく地獄絵図;-P。

 
どんな状態になっているか?と、いうと・・。

$ nmcli dev status
DEVICE           TYPE      STATE            CONNECTION      
eth0             ethernet  接続済み         eth0            
eth1             ethernet  接続済み         eth1            
eth2             ethernet  接続済み         eth2            
eth3             ethernet  接続済み         eth3            
eth4             ethernet  接続済み         eth4            
br0              bridge    接続済み (外部)  br0             
br1              bridge    接続済み (外部)  br1             
br4              bridge    接続済み (外部)  br4             
mgmt0            vrf       接続済み (外部)  mgmt0           
lb0              vrf       管理無し         --              
docker0          bridge    接続済み (外部)  docker0         
docker_gwbridge  bridge    接続済み (外部)  docker_gwbridge 
veth32347c8      ethernet  管理無し         --              
lo               loopback  管理無し         --              

 
多少並び直していますが、インターフェースはこれだけあります。結構多いほうだと思います;-)。

一応、表にしてみました。今回は絵はナシで・・。

物理 IF VRF bridge IPv4 IPv6 説明
eth0 br0 192.168.22.0/24 2001:470:fe36:face::/64 外部からのアクセス用で Docker ホストとコンテナで同一セグメント
eth1 br1 192.168.52.0/24 2001:470:fe36:cafe::/64 DB アクセスなどのバックヤード用で Docker ホストとコンテナで同一セグメント
eth2 192.168.111.0/24 2001:470:fe36:111::/64 同一ネットワーク上の NFS サーバへのアクセス用
eth3 mgmt0 192.168.1.0/24 2001:470:fe36:1::/64 外部からの ssh などのメンテナンス用
eth4 lb0 br4 192.168.202.0/24 ロードバランサ配下のためなし ロードバランサ用閉域セグメントで Docker ホストとコンテナで同一セグメント

 
セグメントはそれぞれ記載しましたが、インターフェースにつける実際のアドレスは 218 です。 IPv4/IPv6 共に 218 を設定しています。

 
Docker ホストにはインターフェースが全部で 5 個。
VRF を設定するルーティングテーブルは全部で 3 個。 eth0,eth1,eth2 が所属する default のルーティングテーブル。 eth3 はメンテナンス用なので mgmt0。 eth4 はロードバランサセグメントなので lb0。

5 個のインターフェースの内、Docker コンテナでも同一セグメントを利用するために bridge が存在していますが、それは 3 個。
Docker コンテナのネットワーク接続は色々なパータンを想定。

  • Service-Segment への接続みのウェブサーバ
  • Service-Segment と Access-Segment への接続する WordPress 用サーバ
  • LB-Segment への接続のみの負荷分散を考慮したウェブサーバ
  • LB-Segment と Access-Segment への接続するウェブアプリケーションサーバ

 
Service-Segment は外部からの直接アクセスを想定。 Access-Segmen はバックヤードで DB 接続や tomcat への接続を想定。 LB-Segment はロードバランサ配下の閉域セグメント。

ロードバランサは上位に apache を用意しましたが、上位のロードバランサからの閉域セグメントとして VRF を設定して、かつ、それを bridge して Docker コンテナに直接アクセスするように設定しました。

それにしても、フツー、ここまでするかねぇ?! みたいな;-)。

 
では、実際に設定を見てい行きましょう。

まず、 /etc/sysconfig/network-scripts/ 配下の ifcfg-eth* のファイルですが、フツーの設定で問題ありません。ルーティングテーブルが存在するインターフェースの設定ファイルのみに GATEWAY= や IPV6_DEFAULTGW= を指定してあげてください。
rule-eth* や route-eth* は今回は用意しませんでした。

 
1. VRF の設定
VRF の設定は /etc/rc.local 内に記載します。

ip link add dev mgmt0 type vrf table 10
ip link set dev mgmt0 up
ip link set dev eth3 master mgmt0
ip link set dev eth3 up
ip route add default via 192.168.1.1 table 10
ip route add ::/0 via 2001:470:fe36:1::1 table 10

ip link add dev lb0 type vrf table 4
ip link set dev lb0 up
ip link set dev eth4 master lb0
ip link set dev eth4 up
ip route add default via 192.168.202.1 table 4

route delete default
route delete default
route delete default
route add default gw 192.168.22.1

route delete -host 192.168.1.1
route delete -host 192.168.202.1

ip route del ::/0 via 2001:470:fe36:1::1
ip route del ::/0 via 2001:470:fe36:face::1
ip route del 2001:470:fe36:1::1/64
route -6 add default gw 2001:470:fe36:face::1

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

 
こんな感じでしょうか。/etc/iproute2/rt_tables に table 4 とか 10 の名前を書いても良いですが、数値で管理する場合は不要です。

ルーティング設定を色々いじっているのは、ルーティングテーブルが美しくならないのでコマンドで正しいルーティング情報にしているためです。

こうなっているのが美しいかなぁ・・。と、思っています。

$ ip route show
default via 192.168.22.1 dev eth0 
192.168.22.0/24 dev eth0 proto kernel scope link src 192.168.22.218 metric 100 
192.168.52.0/24 dev eth1 proto kernel scope link src 192.168.52.218 metric 101 
192.168.111.0/24 dev eth2 proto kernel scope link src 192.168.111.218 metric 102

$ ip route show table 10
default via 192.168.1.1 dev eth3 
broadcast 192.168.1.0 dev eth3 proto kernel scope link src 192.168.1.218 
local 192.168.1.218 dev eth3 proto kernel scope host src 192.168.1.218 
broadcast 192.168.1.255 dev eth3 proto kernel scope link src 192.168.1.218 
 
$ ip route show table 4
default via 192.168.202.1 dev eth4
broadcast 192.168.202.0 dev eth4 proto kernel scope link src 192.168.202.218 
local 192.168.202.218 dev eth4 proto kernel scope host src 192.168.202.218 
broadcast 192.168.202.255 dev eth4 proto kernel scope link src 192.168.202.218 

$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:470:fe36:111::/64 dev eth2 proto kernel metric 102 pref medium
2001:470:fe36:cafe::/64 dev eth1 proto kernel metric 101 pref medium
2001:470:fe36:face::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 1024 pref medium
fe80::/64 dev eth1 proto kernel metric 1024 pref medium
fe80::/64 dev eth2 proto kernel metric 1024 pref medium
fe80::/64 dev eth3 proto kernel metric 1024 pref medium
default via 2001:470:fe36:face::1 dev eth0 metric 1 pref medium

$ ip -6 route show table 10
anycast 2001:470:fe36:1:: dev eth3 proto kernel metric 0 pref medium
local 2001:470:fe36:1::218:1 dev eth3 proto kernel metric 0 pref medium
anycast fe80:: dev eth3 proto kernel metric 0 pref medium
local fe80::8785:99b6:f03b:cf5e dev eth3 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth3 proto kernel metric 256 pref medium
default via 2001:470:fe36:1::1 dev eth3 metric 1024 pref medium

$ ip -d link show type vrf
7: mgmt0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 56:64:d2:f2:ee:55 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 10 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
8: lb0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2e:68:9e:22:5f:0e brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 4 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

 
VRF しているインターフェースのルーティング情報が乗っていると削除して、正しいルーティング情報に直すので roure del したり route add しています。上記になっているのが、僕は一番美しいルーティングテーブルだと思っているのであります。
この辺り、nmcli だとちゃんとやってくれるのかなぁ?

 
VRF は eth0,eth1,eth2 の default テーブルと、eth3 の mgmt0 なテーブル、そして、eth4 のロードバランサ用テーブルと、合計三つのデーブルを作成しました。外部からアクセスすると、おのおののインターフェースから入って、入ってきたところから出ていきます。

 
さてと。 VRF で複数のルーティングテーブルがあると、例えば自分のサーバから外部のサーバに ssh したい場合、default のルーティングテーブルから出ていってしまいます。

本来、メンテナンス用の eth3 のインターフェースがあるのですが、VRF しているのでフツーに ssh するとへんなことになります。そんなときはインターフェース指定でコマンドを実行するのが良いですね。 そんなときに利用するのが if vrf exec コマンドです。

$ traceroute -n 192.168.1.217
traceroute to 192.168.1.217 (192.168.1.217), 30 hops max, 60 byte packets
 1  192.168.22.1  0.416 ms  0.460 ms  0.456 ms
 2  192.168.1.217  0.659 ms  0.654 ms *
$ ip vrf exec mgmt0 traceroute -n 192.168.1.217
traceroute to 192.168.1.217 (192.168.1.217), 30 hops max, 60 byte packets
 1  192.168.1.1  0.405 ms  0.323 ms  0.324 ms
 2  192.168.1.217  0.665 ms  0.668 ms  0.687 ms
$ ip vrf exec mgmt0 ssh 192.168.1.217
>

 
上のは default のルーティングテーブルの gateway である 192.168.22.1 経由で出ていきますが、 ip vrf exec “VRF インターフェース名” を付加してコマンドを打つと eth3 の VRF mgmt0 の gateway を経由して通信できます。 FreeBSD 的には setfib コマンドがありますが、それと同等機能ですね。

VRF の設定はこれにて完了。これは以前書いたものとほぼ一緒かな。

 
2. bridge の設定
次に Docker ホストと Docker コンテナの間で同一のセグメントを利用できるようにする bridge の設定をします。一番上に書きましたが「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」のエントリの改訂版になります。

bridge-utils はもう捨てて ip link set dev コマンドを利用して設定します。

まず、bridge インターフェースを生成するための docker network create コマンドの実行から。

# docker network create Service-Segment \
     -o "com.docker.network.bridge.name"="br0" \
     --driver=bridge \
     --subnet 192.168.22.0/24 \
     --gateway 192.168.22.218 \
     --ipv6 \
     --subnet 2001:470:fe36:face::/64 \
     --gateway 2001:470:fe36:face::218:1

# ifconfig br0 inet6 del fe80::1/64

 
もう bridge-utils を捨てたので docker network create で生成するネットワークは IPv4/IPv6 のデアルスタクに対応にします。コンテナも IPv4/IPv6 のデアルスタク対応です;-)。

docker network create で –ipv6 を指定するとリンクローカルアドレスに fe80::1 が自動的に付加されます。fe80::1 はコンテナが IPv6 を利用したときの gateway になるんだそうな。強引に付加されます。

bridge なネットワークなので複数の Docker ホストがあった場合、全ての Docker ホストがリンクローカルアドレスに fe80::1 を利用すると IPv6 duplicate address fe80::1 てな感じになり、同一セグメント上のサーバ間の通信ができなくなります。なので、ifconfig br0 inet6 del して削除します。そもそも既に由緒正しいリンクローカルアドレスが付加されているので fe80::1 はまるっきり不要です。

次に br0 と物理インターフェース eth0 を bridge します。

# ip link set dev br0 up
# ip link set dev eth0 promisc on
# ip link set dev eth0 up
# ip link set dev eth0 master br0
# ifconfig eth0 0.0.0.0 up
# ifconfig eth0 inet6 del 2001:470:fe36:face::218:1/64 up

# route add default gw 192.168.22.1 dev br0
# ip route del ::/0 via 2001:470:fe36:face::1
# route -6 add default gw 2001:470:fe36:face::1 dev br0

 
上から順に説明すると、

  • docker network create で生成した br0 を UP します
  • eth0 のプロミスキャス・モードを有効化します
  • eth0 を UP します
  • eth0 と br0 をブリッジ化します
  • br0 に IPv4/IPv6 アドレスが付加されるので eth0 側から削除します
  • 最後にルーティング情報を設定します

こんな感じでしょうか。

ロードバランサセグメント用の設定も書いておきます。

# docker network create LB-Segment \
    -o "com.docker.network.bridge.name"="br4" \
    --driver=bridge \
    --subnet 192.168.202.0/24 \
    --gateway 192.168.202.218

# ip link set dev br4 up
# ip link set dev eth4 promisc on
# ip link set dev eth4 up
# ip link set dev eth4 master br4
# ifconfig eth4 0.0.0.0 up

# ip link set dev lb0 up
# ip link set dev br4 master lb0
# ip link set dev br4 up
# ip route add default via 192.168.202.1 table 4

 
こちらは閉域ネットワークです。でもって IPv6 がないのでシンプルです。外部からロードバランサ経由でアクセスがあったものは default gateway に戻っていきます。
ちなみに eth4, br4 の brige インターフェースは lb0 という VRF でもあるわけですが、bridge 生成時に VRF を意識する必要は全くありません。すげ;-)。

ちなみに eth1, br1 の組み合わせも bridge して docker network で Access-Segment として create しますが、今回は割愛します。

 
bridge を終了するコマンドも記載しておきます。

# ip link set eth0 promisc off
# ip link set eth0 down
# ip link set dev eth0 nomaster
# ip link delete br0 type bridge

# docker network rm Service-Segment

# ifconfig eth0 192.168.22.218/24
# ifconfig eth0 inet6 add 2001:470:fe36:face::218:1/64

# route add default gw 192.168.22.1 dev eth0
# ip route del ::/0 via 2001:470:fe36:face::1
# route -6 add default gw 2001:470:fe36:face::1 dev eth0

# ping -q -c 3 192.168.22.1 > /dev/null 2>&1

 
こちらも一応、説明しておきます。

  • eth0 のプロミスキャス・モードをオフにします
  • eth0 を DOWN してから eth0 と br0 の bridge を削除します
  • br0 を削除するので docker network rm を実行します
  • eth0 に IPv4/IPv6 アドレスを付加します
  • ルーティング情報を更新します
  • 最後に ping を打つのは上位のルータが保持している古い MAC アドレスを書き換えるため

こんな感じでしょうか。

これで VRF でルーティングテーブルが個別なネットワークを bridge して Docker コンテナが利用できる環境が整いました。

 
3. IPv4/IPv6 デアルスタク対応コンテナの起動
最後に Docker コンテナの使い方について書いておきます。何回も書いている通り bridge-utils を捨てて ip link set dev コマンドに移行したので Docker コンテナは IPv4/IPv6 のデアルスタクで動作させられます。

起動はこんな感じで。もっと複雑な起動方法については「Dockerを利用してWordPressを動作させます。それもブリッジを用いて。」を参照してください。

$ docker run -d \
 --net=Service-Segment --ip=192.168.22.246 --ip6=2001:470:fe36:face::218:246 \
 -v /opt/docker/contents/web-service01/html:/var/www/html \
 -v /opt/docker/contents/web-service01/conf.d:/etc/httpd/conf.d \
 -v /opt/docker/contents/web-service01/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name web-service01 \
 web-service01:1 /usr/sbin/httpd -DFOREGROUND
$
$ docker exec -it web-service01 /bin/bash
[root@3383ac655b6b /]# ifconfig eth0
eth0: flags=4163  mtu 1500
        inet 192.168.22.246  netmask 255.255.255.0  broadcast 192.168.22.255
        inet6 2001:470:fe36:face::217:246  prefixlen 64  scopeid 0x0
        inet6 fe80::42:c0ff:fea8:16f6  prefixlen 64  scopeid 0x20
        ether 02:42:c0:a8:16:f6  txqueuelen 0  (Ethernet)
        RX packets 43  bytes 4322 (4.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 806 (806.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[root@3383ac655b6b /]# exit
$

 
Docker ホストと Docker コンテナの間に NAT が入ってない (それはつまりは docker0 インターフェースを利用していない) 純粋な IPv4/IPv6 アドレスを利用したコンテナへのアクセスができるようになりました。 docker0 インターフェースを利用してないので /etc/docker/daemon.json への ipv6 true や fixed-cidr-v6 の設定も不要です。

思う存分 IPv4/IPv6 デアルスタクな Docker コンテナを楽しめる環境が整いました;-)。

IPv4 は NAT だけど IPv6 は腐るほど持っているので、Docker コンテナでも IPv6 が利用できるほうが良いですよねぇ;-)。

ちなみにですが、拾ってきた Docker イメージのうち portainer, registry, docker-registry-frontend などは、根こそぎ IPv6 でのアクセスが可能です;-)。

 
さてと。今回のお題目。

ポリシールーティングではなく VRF してルーティングテーブルをわけてから bridge して Docker ホストと Docker コンテナで同一ネットワークを利用し、更に IPv4/IPv6 のデアルスタクで Docker コンテナを運用する。

と、いうのができました。僕としてはもう、ほぼほぼこれで満足です。最終目的かもしれないです。ふぅ。

まぁ、実装するのは簡単で、これを実運用に持っていくには対障害対応とか色々必要となってくるのですが、色々と設定が必要そうです。

あと、Swarm を利用を利用して、当該 の Docker ホストがダウンしたときはコンテナは移動し、ダウンした Docker ホストのネットワーク環境などを整え終わったら再度サービスに復活させるとかの対応も必要かも。

 
ひとまずこれでヨシとしよう。

ふぅ。楽しかった;-)。

3月 282023
 

三ヶ月に一回 Let’s Encrypt の証明書の更新があるわけだけど、今回はハマった・・。なのでちょっと書いておきます。

Let’s Encrypt の SSL 証明書更新後はちゃんと openssl コマンドを利用して確認するんだけど・・。

 
・https の確認

$ openssl s_client -connect running-dog.net:443 | openssl x509 -enddate | grep notAfter

 
・sendmail の確認

$ openssl s_client -connect mail.running-dog.net:587 -starttls smtp | openssl x509 -noout -dates

 
・imaps の確認

$ openssl s_client -connect mail.running-dog.net:993 | openssl x509 -noout -dates

 
まぁ、これらのコマンドを打って確認できるのは証明書の日付くらいか・・。サービスが実際に正常動作しているかは、やはり、ログを見ないと解らないか・・。

 
今回の Let’s Encryp の SSL 証明書更新後のハマりポイント。

 
1. Apple のメールアプリが imaps サーバに接続できなくなった
macOS や iOS などのメールアプリが根こそぎ imaps サーバに接続できなくなった。 macOS に Thunderbird をインストールしてそこから imaps サーバにアクセスすると特に問題なくアクセスできる・・。

macOS のメールアプリからアクセスすると、ログには以下のように残っていました。
あぁ・・。 moacOS 側のアプリのキャプチャ無くてすみません・・。

imapd-ssl[39496]: ip=[<略>], couriertls: connect: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

 
なんか、おかしい・・。macOS 上の SSL 証明書を「キーチェーンアクセス」から削除してもダメ・・。

まぁ、ログを見ると cipher が足りない風な感じはしているのよねぇ・・。

と、いうことで Apple 製品の SSL 系 cipher についての記載を調べてみると以下の URL が見つかりました。

https://support.apple.com/ja-jp/guide/security/sec100a75d12/web

上記を読むと『 ECDHE_ECDSA_AES および ECDHE_RSA_AES』が必要なようです。僕は imap サーバに courier-imap を利用している(この記事の執筆時点にインストールされているバージョンは courier-imap-5.2.2 です)のだけど、この二つの cipher を /usr/local/etc/courier-imap/imapd-ssl の設定に追加しました。

こんな感じになりました。

TLS_CIPHER_LIST="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA:ECDHE_ECDSA_AES:ECDHE_RSA_AES"

 
随分と長くなりました。で Apple 製品のメールクライアントからアクセスすると無事に接続できるようになったのでありました。ふぅ・・。

 
2. sendmail が他のメールサーバから Relay を受け付けなくなった
imapd に接続できないのはまぁ、良いんだけど、こっちはダメージでかいですね。届くはずのメールが届かないのでおかしいなぁ・・。と、思っていたら sakura インターネットからのメールがエラーになっていて・・。

ログを確認すると、こんな感じ。

sm-mta[76876]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=<略>.sakura.ne.jp [<略>]

 
なんか、こちらも cipher が足りない感じ。orz

しょうがないので /etc/mail/sendmail.cf の O CipherList をちょっと変更。

#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:
O CipherList=ALL
#O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:

 
当初設定したていたのはコメントアウトしてある一番上の行。どの cipher が足りないのか解らないので真ん中の O CipherList=ALL 行を有効にして全ての cipher で対応できるようにして、ログを確認。そーすると、ちらほらメールを受信し始めました。ふぅ。
で、更にログを眺めいてたら以下のログを発見。

sm-mta[33084]: STARTTLS=server, relay=<略>.sakura.ne.jp [<略>], version=TLSv1.2, verify=NO, cipher=ECDHE-ECDSA-AES256-GCM-SHA384, bits=256/256

 
なるほど。新たに ECDHE-ECDSA-AES256-GCM-SHA384 を追加する必要があるのね。と、いうことで O CipherList の設定は一番下の行にして、sendmail を再起動したら無事に復活したのでありました。

 
ふぅ。それにしても Let’s Encrypt の SSL 証明書を更新しただけで、メールの送受信ができなくなるとは恐ろしいことだぁ・・。

https は全然問題なかったのだが・・。

それにしも証明書の更新後の確認は日付だけでなく、ログの確認であるとか、実際にポートに接続して確認する必要があるかなぁ・・。今後の課題ですな。

 
と、いいつつ Let’s Encrypt だけでなく google や Apple は SSL 証明書の期限をさんが月にしよう。キャンペーンをしているけど・・。大変になる頻度が増えるかな。

3月 062023
 

最近、スマートフォンは以下を利用しております。

画面が一番大きいのは moto g52j 5G ですが、やはりもっと大画面が欲しい。と、なったのであります。
僕は Y!mobile ユーザで PayPay も利用しているので「ヤフープレミアム会員」です。そうすると、雑誌読み放題な特典が付いてきて、スマートフォンで色々な雑誌を見ることが可能です。
例えば競馬新聞である『馬サブロー』なんかも閲覧可能なので、競馬の予想もできます。と、いうことは・・。やはっぱりタブレットが欲しい。大画面が魅力的に感じるのであります。

と、いうことで今回は ALLDOCUBE iPlay50 という Android タブレットを購入してみました。これを購入した決め手は画面サイズですね。解像度が 2000×1200 の 2K ディスプレー、俗に WUXGA とでも言うのでしょうか。
価格的には 17,000yen 弱でした。こいつにケースを追加で購入。これで僕もすっかりとタブレット人生を歩むことになりそうです。

写真はこんな感じです。
壁紙はあんまり気にしないでくださいf(^^;;。

で、購入後 10 日ほど利用してみたので ALLDOCUBE iPlay50 の気がついた点をダラダラと書いてみます。

 
1.Android12
Android のバージョンは 12 でした。今僕が利用している moto g52j 5G や Xperia 10 II XQ-AU52 (こいつは SIM ナシで Wi-Fi で一応、利用中) なんかも Android12 です。 Android12 の機能は多分一通り利用できると思われます。画面分割とか一応利用可能です。

 
OS が一緒なのでスマートホンと機能的には本当に変わらないですね。ただ単に画面が大きくなった感じでしょうか。 iOS と iPadOS は大きな違いがあるのかな?

 
ロック画面の解除は指紋・顔認証どちらも非搭載です。なので、数値を入力することでロックを解除する必要があります。まぁ、これは値段相応なのかな・・。
顔認証は OS の標準機能ではないのかな?他にオプション的な機能が何か必要なのかな?

 
2.ステルス Wi-Fi に接続できない。
おかしいのよねぇ・・。 Android12 ならステルスな Wi-Fi に接続できると思うんだけど、このタブレットはステルス機能を有効にした Wi-Fi AP をみつけることができません。かぁなり驚きっ!!

 
3.LTE 接続できます
一つのスロットに SIM カードと MicroSD を乗せることができます。もしくは SIM カード二枚乗せることができます。

なので、LTE 通信が可能です。対応バンドは以下のようです。

LTE: 1 / 2 / 3 / 5 / 7 / 8 / 20 / 28 / 34 / 38 / 39 / 40 / 41

SoftBank のバンドにしっかりとマッチしているので、利用するなら SoftBank SIM を入れることですね。

 
と、いうことで実際に入れてみました。

Y!mobile には「シェアプラン」というのがあります。「シンプルプラン M」の場合は 15GB の “ギガ” がありますが、全部使い切れない場合、繰り越されます。そして、更に余って消えてしまうのももったいないですね。と、いうことで SIM カードを何枚か調達できて、スマートホンとかタブレットで “ギガ” を分け合えることができます。

例えば、僕が「シンプルプラン S」を契約した親回線。奥さんが「シンプルプラン M」を契約した子回線。奥さんの契約に家族割が適用され、奥さんの「シンプルプラン M」は通常価格 3,278yen から 2,090yen になります。
奥さんの「シンプルプラン M」で「シェアプラン」を契約すると月々 539yen ほどの料金が発生しますが、既に家族割が効いているので、それでも基本料金より安くなります。

そして「シェアプラン」は 539yen で最大 3 枚の SIM カードがもらえます。でもって SIM カード発行手数料は 0yen っ!! 「シンプルプラン M」で “ギガ” が余っている人は「シェアプラン」を利用するのも一つの手かもしれません。

ちなみに「シェアプラン」の SIM カード、通話はできません。MMS は Softbank から届くだけ。という SIM カードです。

 
前置きが長くなりました。「シェアプラン」の SIM カードを ALLDOCUBE iPlay50 に入れてみます。が、素直に LTE の電波を拾ってくれません。最初の段階では LTE での通信できません。
それはそーですね。 ALLDOCUBE iPlay50 には Y!mobile の APN が入っていません。手動で設定する必要があります。


https://www.ymobile.jp/yservice/howto/simfree_android/apn/

こちらに記載されていますね。

名前:       Y!mobile APN (任意の文字列)
APN:        plus.acs.jp
ユーザー名: ym
パスワード: ym
認証タイプ: CHAP

 
まぁ、あとのは省略可です。とりあえず上記を指定します。

そして、しばらく待っていると 4G で接続できるようになります。

 
4.Androidマルチユーザ環境で利用
タブレットを購入したのは僕ですが、奥さんは LTE 回線を提供してくれました。と、いうことで、Android で初めてマルチユーザ環境を整えてみました。

「設定」->「システム」->「複数ユーザ」で有効化できます。

サブのアカウントを作成して、ロック画面からアクセスするときにユーザをチョイスしてパスワードを利用。

 
ユーザ単位で google アカウントが必要です。二つのアカウントは「Google ファミリー リンク」しても良いかと思います。

二つのアカウントで同じアプリを利用する場合、個別にダウンロードしてインストールする必用があります。ストレージが圧迫されるかな?と、いう気がします。
あと、パックグラウンドで色々動作していると CPU が食われるような気がします。なので、両方のアカウントでこまめにバックグラウンドアプリを停止するとか、メモリ開放するとかしないと、突如として遅くなる場合があったりします。

ALLDOCUBE iPlay50 の CPU は UNISOC T618 なので MediaTek のよりは処理速度が高いので、まぁ、なんとかマルチユーザ環境にも耐えられるかもです。

 
5.画面が大きいことは良いことだ
画面が大きいので色々できます。
ConnectBot をインストールして ssh 接続してメンテナンスとか行える。
Remote Desktop もあっても良いかもですねぇ。

 
Bluetooth キーボードを接続して上記アプリを利用すれば もうフツーの PC 感覚。あ。キーボード配列が日本語配列だとちと大変。そんなときは 物理キーボード配列変更 (+親指Ctrl) [日本語配列] をインストールすると日本語刻印の通りに文字入力できます。 Ctrl と CAPS キーのスワップ設定も入っているのでチョーご機嫌。 ssh で入った先で emacs とかフツーに利用できます。

 
そして、タブレット購入とタイミングがバッチリの非常に良い記事を発見。

https://pc.watch.impress.co.jp/docs/column/yajiuma-mini-review/1481098.html
https://www.spacedesk.net/

spacedesk というのを利用すると PC のサブディスプレイとしてタブレットを利用できます。 Windows PC にディスプレードライバインストールしてタブレット側に探査・転送アプリをインストールすると、確かにディスプレーとして機能します。すげー。

けど、今は無料で利用できるみたいですが、そのうちに有料化されるかな?と、いう雰囲気か。

 
とまぁ、今回はダラダラと書いてみました。やっぱり画面は大きいほうが良いっ!! と思うのは、もうスッカリとローガンになってきているから。なのでしょうかねぇ。

今回、初めて『タブレット』というモノを購入してみましたが、僕の人生の中でタブレット端末は効果的に機能してくれるのか、今後の動向を検証してみたいと思います;-)。