meta's blog - The Power To Serve

■ AlmaLinux developerになりました

いろいろありまして、AlmaLinux developerになりました。2023年4月から活動しています。

FreeBSD developer (ports)もやっているわけですが、こちらも別に引退するわけではなく、引き続き活動していきます。最近のFreeBSD方面の活動はSoftEtherVPNのクライアント機能の改善などを行っています。SoftEtherVPN 5系であれば、FreeBSDをSoftEtherVPNクライアントとして動作させることが可能です。

• https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1859
• https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1860
• https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1863
• https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1865

他には、私自身がコードを書いて修正したわけではないのですが、Ethernet over IPv6 が上手く動いていなかったバグの修正をテストして13-STABLEと12-STABLEに昨年マージするなどしていました。既にリリースされた12.4-RELEASE及び13.4-RELEASEに取り込まれていますので、フレッツ網でNGN折返し通信をする場合などにご活用ください。

• https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256820

AlmaLinuxの方ではどんなことをやっているかというと、ジョインして最初に手掛けたのはRaspberry Pi用イメージの改善です。これについては、別途解説したいと思います。

今後はFreeBSDとAlmaLinuxの両輪(そしてxrdp)で活動していきますので、引き続きよろしくお願いします。GitHub Sponsorsも募集していますので、ご支援いただける方はよろしくお願いします。

■ AlmaLinux 9 (20221116)で Raspberry Pi 400のWi-Fiを使えるようにする

突然ですが Raspberry Pi 400を買いました。Raspberry Pi 4ではなく400にした理由は、 たまたま買おうとしたときにスイッチサイエンスに在庫があるのが400だったのと、キーボード付きなのと、端子が後ろに集中していて使いやすそうだと思ったからです。

アップするの忘れてたけど Raspberry Pi 400 ゲット。 pic.twitter.com/fpnUgNDpsL

— めた110 (@metalefty) April 13, 2023

FreeBSDとAlmaLinuxを入れて遊ぶつもりですが、まずはAlmaLinuxの方から。

まずは、国内のミラーからRasPi用のイメージをダウンロードしてきます。今回使用したのは AlmaLinux-9-RaspberryPi-9.1-20221116.aarch64.raw.xz です。

イメージの書き込みかたは省略します。イメージを書きんだSDカードを挿して電源を入れると普通に起動しました。Raspberry Pi 400はUSBからのブートにも対応しているため、SDカード以外にもUSBメモリやSSDを挿しても使えるようです。

以下の初期パスワードでログインします。

ユーザー名: root
パスワード: almalinux

Wi-Fiが使えない

AlmaLinux 9の配布されたイメージそのままの状態では、Wi-Fiが使えませんでした。

nmcliコマンドで確認してみると、Wi-Fiは有効になっているものの WIFI-HWがmissingとなっており、Wi-Fiのハードウェアが見つからない状態になっているようです。

$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
missing  enabled  missing  enabled

これはPi 400 のハードウェアが Pi 4 と微妙に異なるためで、Pi 4がBCM43455というチップを採用しているのに対し、Pi 400はBCM43456を採用しているようです。

dmesgをgrepしてみると、ファームウェアの読み込みに失敗していることがわかります。ドライバとしてはbrcmfmacで対応しているのですが、ファームウェアがないためハードウェアを使用できていないようです。

$ dmesg | grep brcmfmac
[   19.848452] brcmfmac: F1 signature read @0x18000000=0x15294345
[   19.859149] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   19.886424] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2
[   19.902527] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.bin failed with error -2
[   19.968835] usbcore: registered new interface driver brcmfmac
[   20.926139] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

ファームウェアは linux-firmware というパッケージに含まれていて、/lib/firmware 以下にインストールされているのですがこの中に 43456 用のものがないことがわかります。ファイル名にRaspberry Piのモデル名らしきものがありますが、ここにもPi 400はないですね。

$ find /lib/firmware/brcm | grep -i raspberry
/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt.xz
/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt.xz
/lib/firmware/brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt.xz
/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt.xz
/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi Compute Module 4.txt.xz
/lib/firmware/brcm/brcmfmac43430-sdio.raspberrypi,model-zero-w.txt.xz
/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt.xz

本来であれば、linux-firmware パッケージが更新されて dnf update するだけで Pi 400 対応になってくれると良いのですが、今回は別のところからファームウェアを持ってくることにします。

こちらのbrcm-supprementalリポジトリにあるファイルの中から、以下の3つのファイルを持ってきて /lib/firmware/brcm の下にコピーしてやります。他のファイルはxzで圧縮されていますが、圧縮しなくてもOKです。

• brcmfmac43456-sdio.raspberrypi,400.bin
• brcmfmac43456-sdio.raspberrypi,400.clm_blob
• brcmfmac43456-sdio.raspberrypi,400.txt

コピーしたら再起動します。

Wi-Fiが使えるようになった

再起動すると、Wi-Fiが使えるようになっています。nmcliのWIFI-HWがmissingではなくなっていますし、dmesgをgrepした結果にもファームウェアの読み込みエラーが出なくなっています。

$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  missing  enabled 

$ dmesg | grep brcmfmac
[    8.911175] brcmfmac: F1 signature read @0x18000000=0x15294345
[    8.963376] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[    9.065806] usbcore: registered new interface driver brcmfmac
[    9.226089] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[    9.256216] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: May 14 2020 17:26:08 version 7.84.17.1 (r871554) FWID 01-3d9e1d87
[   13.425989] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   13.986762] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   17.410402] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

この状態で、nmcli device wifi list とコマンドを実行すると、周囲のWi-Fi SSIDが表示されます。

接続するには nmcli device wifi connect [SSID] password [パスワード] というコマンドを実行します。

まとめ

AlmaLinux 9でRaspberry Pi 400のWi-Fiが使用できないのは、Pi 4と使用しているハードウェアが微妙に異なり、標準パッケージにファームウェアが含まれていないためです。ファームウェアを特定のディレクトリに置くと、Wi-Fiが使えるようになります。

いずれはlinux-firmwareパッケージが更新されて標準で使えるようになるといいのですが、これを書いている時点では上記の方法でファームウェアを追加してやる必要があります。

■ リトルカブ 強化クラッチ導入＆オイルポンプ交換＆オイル交換 @31275km

リトルカブを75ccにボアアップ後、2000kmほど走行しました。

パワーが増えた分懸念のクラッチは、高回転まで回したときに滑ることはないのですが、50cc用のウェイト16枚の遠心クラッチのため低回転の遠心力が小さい領域で圧着力が足りず、若干滑り気味でした。

田舎で走っている限りは高回転まで回すのでほぼ問題はなく、信号待ちで止まりそうで止まらなかったときの3速25km/hからの再加速や、市街地の渋滞で発進停止を繰り返しているときの1速発進などで滑る感覚があります。出だしで一瞬回転が上がって、回転が上がったのでクラッチがしっかり繋がり回転が落ちるというのを繰り返す感覚です。

というわけで、キタコの強化クラッチキットに交換しました。ついでにオイルも交換です。

ウェイト枚数はスーパーカブ70/90の純正相当の28枚ですが、75ccなのでスーパーカブ70/90純正相当のクラッチであれば十分です。武川の32枚だと、なんとなく繋がりが早すぎて乗りにくそうな気がします。

せっかくクランクケースカバーを開けるので、工賃もまとまるし、ついでにオイルポンプも交換することにしました。

交換後は出だしの滑りが解消され、低回転からしっかりクラッチが繋がるようになりました。回転の低いところから完全に繋がるようになった分、発進加速は少し遅くなりました。また、期待していた低回転域だけではなく、高回転域の最高速度も少し上がった気がします。低回転での滑りが顕著だっただけで、高回転でもわずかに滑っていたのかも。

オイルポンプについては乗っていて違いがわかるようなものではないので変化は感じられませんでした。オイル供給量が増えて安心して乗れます。

今回使ったパーツは以下の4点です。

• KITACO クラッチキット 遠心クラッチ用
• Rクランクケースカバーガスケット
• 100EX用純正オイルポンプ 品番:15100-KWB-600
• ホンダ純正ガスケット オイルポンプ 品番:15119-178-000

■ FreeBSDでMACアドレスごとにネットワークインターフェイス名を固定する

背景

FreeBSDでUSB接続のネットワークインターフェイスを使用すると接続した順に ue0, ue1, ue2…というようなインターフェイス名が割り当てられますが、インターフェイスの挿抜や再起動によってインターフェイス名が変わってしまい不便なことがあります。

実現方法

devdを使用します。詳しくは説明しませんが、大雑把にいうと「デバイスが接続されたり切断されたときになんかするやつ」です。

devdでue0やue1というデバイスが接続されたのを検出して、MACアドレスに対応するインターフェイス名に変更することで決まったインターフェイス名を割り当てるというからくりです。

まず、MACアドレスとインターフェイス名のマッピングを書いたファイルを /etc/netifmap に作成します。ファイル名とパスは任意で構いません。MACアドレスとインターフェイス名を空白文字区切りで書いておきます。

インターフェイス名は foo[0-9]+ というフォーマットである必要はありません。aliceやbobでもOKですが、元のインターフェイス名と同じue[0-9]+と重複するものは避けておきます。例えばue0をue1に変更し、ue1をue0に変更するというようなスワップはうまくいきません。

ここでは、eth[0-9]+にしてみました。

00:11:22:33:44:55 eth0
00:11:22:33:44:66 eth1

次に、/etc/rename-netif.sh というスクリプトを作成します。スクリプトは末尾にGistで貼っておきます。 第一引数にインターフェイス名を与えると、マッピングファイルを参照しマッチしたインターフェイス名に変更するというスクリプトです。

最後に、このスクリプトがインターフェイス接続時に実行されるようにdevdの設定ファイルを書いておきます。 /etc/devd/netif.confという名前で作成しますが、これも任意の名前で構いません。ue[0-9]+という名前にマッチするネットワークインターフェイスが接続されたら、actionに指定したスクリプトが実行されます。

書き終わったら、service devd restartでdevdを再起動しておきます。再起動したら、USBネットワークインターフェイスを順番を変えて挿抜してみると固定のインターフェイス名が割り当てられていることが確認できます。OSごと再起動しても同じMACアドレスに対して同じインターフェイス名が割り当てられます。

今回作成した各ファイル

■ SoftEtherVPNがWireGuardプロトコルに対応したので試してみた

SoftEtherVPNにWireGuardプロトコルのサポートが実装されたので、試してみました。

• https://github.com/SoftEtherVPN/SoftEtherVPN/issues/604
• https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1200

WireGuard サポートが実装されたのは、GitHub上でコミュニティベースで開発されている開発者版 (Developer Edition)で、softether.orgで配布されている安定版のバージョン4系ではありません。まだ実装されたばかりで各言語への翻訳もなく、とりあえず動くようになったという状態ですが、実際に繋がるのか検証して基本的な設定方法についてまとめました。

今回は 3761876 というコミットで実験しました。

前提知識

SoftEtherVPNの基本的な使い方に習熟している前提で、SoftEtherVPN自体のビルド方法や基本的な設定は大幅に省略しています。一部参考までに記載はしていますが、基本的にはWireGuard以外のプロトコルでSoftEtherVPNサーバーへ接続でき、通信ができる状態にするまでのセットアップは済んでいる前提で記述しています。 また、オリジナルのWireGuard同士でのVPNの構築方法もわかっている前提で書いています。

新たにSoftEtherVPNにWireGuardプロトコルが実装されたので、SoftEtherVPNをサーバーとしてWireGuardプロトコルで接続するための差分として捉えてください。

また、WireGuard自体はピアツーピア型のVPNプロトコルであるため、サーバーとクライアントという概念は存在しませんがここでは便宜上SoftEtherVPN側をサーバー、他方をクライアントと呼んで区別します。

準備

今回の実験で使用したのは Ubuntu 20.04 です。GitHubからソースコードを落としてきて、3761876 というコミットを取り出してきてビルドします。

$ git clone --recursive https://github.com/SoftEtherVPN/SoftEtherVPN.git
$ cd SoftEtherVPN
$ git checkout 3761876254ae00e87e261f89910d093671a95109
# apt install cmake build-essential pkg-config libreadline-dev libncurses-dev zlib1g-dev libssl-dev libsodium-dev 
$ make -C build -j 8
$ sudo build/vpnserver start

vpncmd コマンドで見てみると、以下のWireGuard用の3つのコマンドと、ネットワーク設定のコマンドが追加されています。

$ build/vpncmd /server localhost
(snip)
VPN Server>help
下記の 213 個のコマンドが使用できます:
(snip)
 SetStaticNetwork           - Set Virtual Hub static IPv4 network parameters
 WgkAdd                     - Add a WireGuard key
 WgkDelete                  - Delete a WireGuard key
 WgkEnum                    - List the WireGuard keys

それぞれのコマンドの使用方法については、"コマンド名 ?" と入力するとヘルプが表示されます。

StaticNetwork 設定の確認

WireGuardは(現時点では)他のVPNプロトコルとは異なり、動的なIPアドレス割当をサポートしていないためIPアドレスの割当やルーティング対象のサブネットの定義を手動で行う必要があります。

これを行うため、SetStaticNetworkというコマンドが追加されました。

仮想HUBでOptionsGetコマンドを実行することにより確認することができます。コマンドの結果にDefault gateway とDefault subnetが既に定義されていれば何もする必要はありませんが、以前のバージョンを使用していて設定ファイルをそのまま引き継いだ場合はこのあたりを明示的に設定しなければなりません。

VPN Server/SECURENAT>OptionsGet
OptionsGet コマンド - 仮想 HUB のオプション設定の取得
仮想 HUB "SECURENAT" のオプション設定一覧
項目                               |値
-----------------------------------+--------------
匿名ユーザーに対する仮想 HUB の列挙|許可
最大同時接続セッション数           |無制限
状態                               |オンライン
仮想 HUB の種類                    |スタンドアロン
Default gateway                    |192.168.30.1
Default subnet                     |255.255.255.0
コマンドは正常に終了しました。

WireGuard 公開鍵の作成・登録

WgkAdd コマンドでクライアントの公開鍵をSoftEtherVPNに登録します。間違って秘密鍵を登録しないように注意してください。

鍵ペアはクライアント側で生成します。以下のコマンドで、公開鍵・秘密鍵を一度に生成できます。

$ wg genkey | tee privkey | wg pubkey > pubkey
$ cat pubkey
fsn4HQ3wqXg1Nl4j02HKEX91HdKx5kbFOObzdkS7vSI=

pubkeyというファイルの中身が公開鍵なので、これをSoftEtherVPNに登録します。 WgkAddコマンドを使用します。

公開鍵登録の際には、公開鍵に対応する仮想HUBと仮想HUB上のユーザーを紐づけます。これにより、SoftEtherVPNの認証システムとWireGuardの公開鍵が結び付けられます。

VPN Server/SECURENAT>WgkAdd
WgkAdd コマンド - Add a WireGuard key
Key: fsn4HQ3wqXg1Nl4j02HKEX91HdKx5kbFOObzdkS7vSI=

Hub: SECURENAT

User: meta

コマンドは正常に終了しました。

サーバー公開鍵・事前共通鍵の準備

クライアントが接続できるように、サーバーの公開鍵と事前共通鍵(PresharedKey)をクライアントに渡す必要があります。これはSoftEtherVPNの設定ファイルのvpn_server.configの中に記載されています。ただし、設定ファイルの中には秘密鍵しかないのでこれを公開鍵に変換する必要があります。

declare WireGuard
{
        bool Enabled true
        string PresharedKey aKNQj4QI1jD4ZqTFC2gqOYbAz/M60byKTDBkSZ7hYb4=
        string PrivateKey NE+s0i6fi43mvRM90d+fmvDxtNKEpjnLmL4Tbc5oA2s=
}

事前共通鍵は以下のようにして抽出することもできます。

# grep PresharedKey vpn_server.config | awk '{ print $3 }' 
aKNQj4QI1jD4ZqTFC2gqOYbAz/M60byKTDBkSZ7hYb4=

秘密鍵は以下のように抽出して、それを wg pubkey コマンドに渡すことで公開鍵に変換します。

# grep PrivateKey vpn_server.config | awk '{ print $3 }'  | wg pubkey 
H7MobrirpOVEJWiHQ4lB/gefs+qer+DTCkSTbA7EHV0=

クライアント側の設定

クライアント側の設定ファイルは以下のようになります。前述の通りWireGuardプロトコルはIPアドレスの動的割当機能を持たないため、クライアントに割り当てるIPアドレスは事前に重複しないように決めておく必要があります。

[Interface]
PrivateKey = {クライアント秘密鍵}
Address = {クライアントIPアドレス}

[Peer]
PublicKey = {サーバー公開鍵}
PresharedKey = {事前共通鍵}
AllowedIps = {VPNで使用するサブネット}
Endpoint = {サーバーホスト名}:{サーバーポート}
PersistentKeepAlive = 25

サーバー側のポートはSoftEtherVPNが待ち受けているポートなら何でも構いません。WireGuardプロトコルはUDPを使用するため、UDPポートである必要があります。

サーバー側の着信ポートは、PortsUDPGetコマンドで確認することができます。この場合は、443, 992, 1194, 5555 のいずれでも構いません。ファイアウォールなどで遮断されていないことは確認してください。

VPN Server>PortsUDPGet
PortsUDPGet コマンド - サーバーにおける着信 UDP ポートの一覧を表示します。
項目          |値
--------------+--------------------
UDP ポート一覧|443, 992, 1194, 5555
コマンドは正常に終了しました。

先の情報を具体的に当てはめると、以下のような設定ファイルになります。

[Interface]
PrivateKey = IPKW9k/CEZ64iAzzv9xw9cyM1ROtlHJTYiLFD6BymXc=
Address = 192.168.30.233

[Peer]
PublicKey = H7MobrirpOVEJWiHQ4lB/gefs+qer+DTCkSTbA7EHV0=
PresharedKey = aKNQj4QI1jD4ZqTFC2gqOYbAz/M60byKTDBkSZ7hYb4=
AllowedIps = 192.168.30.0/24
Endpoint = softether-server.example.com:443
PersistentKeepAlive = 25

この設定ファイルを /etc/wireguard/wgse0.conf として保存します。wgse0の部分は何でも構いませんが、WireGuardが使用するインターフェイス名になります。設定ファイルを保存したら、wg-quick up wgse0 コマンドでWireGuardを起動します。

# wg-quick up wgse0

wg show コマンドで現在の状態を確認します。

# wg show 
interface: wgse0
  public key: vbXNEl9sJeQbf2kIHDuoafhNJynwvZvwgnwbwYXKrzM=
  private key: (hidden)
  listening port: 17357

peer: H7MobrirpOVEJWiHQ4lB/gefs+qer+DTCkSTbA7EHV0=
  preshared key: (hidden)
  endpoint: softether-server.example.com:443
  allowed ips: 192.168.30.0/24

WireGuardはステートレスなVPNプロトコルであるため、この時点ではまだ接続されていません。本来は接続という概念もありませんが、ここではSoftEtherVPN側のIPアドレステーブルに対向(クライアント)側のIPアドレスが登録されることをもって便宜上接続と呼びます。

接続するためには、ping などでなにか実際の通信を発生させる必要があります。

$ ping 192.168.30.1
PING 192.168.30.1 (192.168.30.1): 56 data bytes
64 bytes from 192.168.30.1: icmp_seq=0 ttl=128 time=28.876 ms

何度かパケットを送っていると、transfer のところに表示される通信量が増えているのが確認できます。

# wg show 
interface: wgse0
  public key: vbXNEl9sJeQbf2kIHDuoafhNJynwvZvwgnwbwYXKrzM=
  private key: (hidden)
  listening port: 64022

peer: H7MobrirpOVEJWiHQ4lB/gefs+qer+DTCkSTbA7EHV0=
  preshared key: (hidden)
  endpoint: softether-server.example.com:443
  allowed ips: 192.168.30.0/24
  latest handshake: 1 minute, 6 seconds ago
  transfer: 2.67 KiB received, 4.32 KiB sent

サーバー側での確認

実際に通信を発生させてpingが通っていることを確認できたら、SoftEtherVPN側の管理コマンドを使用して接続中のクライアントなどの情報を見てみます。

VPN Server/SECURENAT>SessionList
SessionList コマンド - 接続中のセッション一覧の取得
項目            |値
----------------+------------------------------------
セッション名    |SID-SECURENAT-1
VLAN ID         |－
場所            |SecureNAT セッション
ユーザー名      |SecureNAT
接続元ホスト名  |仮想ホスト
TCP コネクション|なし
転送バイト数    |34,902
転送パケット数  |549
----------------+------------------------------------
セッション名    |SID-META-[WIREGUARD]-4
VLAN ID         |－
場所            |ローカルセッション
ユーザー名      |meta
接続元ホスト名 |wireguard-client.example.com
TCP コネクション|1 / 1
転送バイト数    |2,420
転送パケット数  |37
コマンドは正常に終了しました。

セッションリストで、WireGuardプロトコルで接続しているクライアントがいることが確認できます。セッションの詳細を見てみると、以下のように暗号化アルゴリズムに ChaCha20-Poly1305 が使用されていることが確認できます。

VPN Server/SECURENAT>sessionget SID-META-[WIREGUARD]-4
SessionGet コマンド - セッション情報の取得
項目                                |値
------------------------------------+-------------------------------------------------------------
クライアント IP アドレス            |172.16.83.3
クライアントホスト名                |wireguard-client.example.com
ユーザー名 (認証)                   |meta
ユーザー名 (データベース)           |meta
VLAN ID                             |－
サーバー製品名                      |SoftEther VPN Server Developer Edition (64 bit) (Open Source)
サーバーバージョン                  |5.01
サーバービルド番号                  |Build 9675
接続開始時刻                        |2021年 3月27日(土) 17時 0分44秒
初回セッションの確立時刻            |2021年 3月27日(土) 17時 0分44秒
現在のセッションの確立時刻          |2021年 3月27日(土) 17時 0分44秒
半二重 TCP コネクションモード       |いいえ (全二重モード)
VoIP / QoS 対応機能                 |無効
TCP コネクション数                  |1
TCP コネクション数最大値            |1
暗号化の使用                        |はい (暗号化アルゴリズム: ChaCha20-Poly1305)
圧縮の使用                          |いいえ (圧縮無し)
物理通信に使用中のプロトコル        |Legacy VPN - WIREGUARD
UDP 高速化機能をサポート            |いいえ
UDP 高速化機能を使用中              |いいえ
セッション名                        |SID-META-[WIREGUARD]-4
コネクション名                      |CID-5
セッションキー (160bit)             |34CA1A2C12074BE53A2479F7B097261DA98E7F0C
ブリッジ / ルータモード             |いいえ
モニタリングモード                  |いいえ
送信データサイズ                    |7,254 バイト
受信データサイズ                    |7,806 バイト
送信ユニキャストパケット数          |94 パケット
送信ユニキャスト合計サイズ          |7,212 バイト
送信ブロードキャストパケット数      |1 パケット
送信ブロードキャスト合計サイズ      |42 バイト
受信ユニキャストパケット数          |48 パケット
受信ユニキャスト合計サイズ          |2,072 バイト
受信ブロードキャストパケット数      |94 パケット
受信ブロードキャスト合計サイズ      |5,734 バイト
クライアント製品名 (申告)           |WireGuard
クライアントバージョン (申告)       |5.01
クライアントビルド番号 (申告)       |Build 9675
クライアント OS 名 (申告)           |WireGuard
クライアント OS バージョン (申告)   |-
クライアント OS プロダクト ID (申告)|-
クライアントホスト名 (申告)         |
クライアント IP アドレス (申告)     |172.16.83.3
クライアントポート番号 (申告)       |62395
サーバーホスト名 (申告)             |0.0.0.0
サーバー IP アドレス (申告)         |0.0.0.0
サーバーポート番号 (申告)           |443
コマンドは正常に終了しました。

同様に、IPアドレステーブルにもクライアントのIPアドレスが登録されています。

VPN Server/SECURENAT>iptable
IpTable コマンド - IP アドレステーブルデータベースの取得
項目        |値
------------+-----------------------
ID          |3038997077
セッション名|SID-SECURENAT-1
IP アドレス |192.168.30.1
作成時刻    |2021-03-27 16:51:57
更新時刻    |2021-03-27 16:58:12
場所        |SoftEtherVPN-develop 上
------------+-----------------------
ID          |3431872817
セッション名|SID-META-[WIREGUARD]-4
IP アドレス |192.168.30.238
作成時刻    |2021-03-27 17:00:44
更新時刻    |2021-03-27 17:02:04
場所        |SoftEtherVPN-develop 上

コマンドは正常に終了しました。

まとめ

SoftEtherVPNは独自プロトコル(ネイティブプロトコル)、SSTP、L2TP/IPsec、EtherIP/IPsec、OpenVPNなど様々なプロトコルに対応したオールインワンVPNですが、対応するプロトコルに新たに新時代のプロトコルであるWireGuardが追加されたのはとても喜ばしいことです。

ただし、SoftEtherVPNとWireGuardの両方に精通していないと設定は少々難しいですし、WireGuardが動的なIPアドレスの割当をサポートしていないことから、WireGuardプロトコルだけ運用・管理スキームが他のプロトコルと異なる部分が生まれてしまい、使いにくい部分はあります。

設定方法・手順をまとめ、通信できることを確認したので一旦はここまでにします。後日、オリジナルのWireGuardとの速度の比較などを行う予定です。

■ リトルカブボアアップ後の燃費

ボアアップ後にすでに 300km ほど走行し、2回の給油を行ったので燃費を比較しました。

2005年式リトルカブ3速に、変更点はキタコの75ccボアアップキット、ハイカム、Fスプロケ15Tです。キャブセッティングは50ccのときのまま何も変更していません。

燃料はボアアップ前からハイオクに変更していて、下の表に掲載の給油分はすべてハイオクです。

回数	走行距離	給油量	燃費	備考
ボアアップ前	168.7km	3.01 L	56.05 km/L
ボアアップ前	184.4km	3.25 L	56.74 km/L
ボアアップ前	138.7km	2.51 L	55.26 km/L
1回目	165.9km	3.10 L	53.52 km/L	25km ほどがボアアップ前の走行
2回目	171.7km	3.08 L	55.75 km/L

というわけで、結果は燃費はほとんど変わらずでした。キャブセッティングを何も変更していないというのもあるかもしれませんが、予想外の嬉しい結果となりました。

夏場にどうなるかはわかりませんが、当面はこのまま走ってみようと思います。

■ リトルカブボアアップ後の初オイル交換 @29450km

リトルカブを75ccにボアアップした後、初のオイル交換を行いました。ボアアップ時の走行距離は 29185km だったので、差し引き 265km です。

最初のオイル交換までをピストン＆シリンダーとハイカムの慣らしと決めていたので、これで全開解禁です。最初のオイル交換は100kmくらいで行ったり、もっと長く慣らしを行う人もいるみたいですが自分の場合はこんなもんで。

慣らしといっても、75ccという低排気量なだとそんなに回転数を抑えて走れるわけではないので、ぎりぎり流れに乗れる速度の 50km/h を上限に設定して走ることにしていました。

タコメーターはつけていないので、50km/h 時の回転数は計算で求めることになります。計算で求めたグラフを置いときます。フロントのスプロケを15Tに変更しているので、50km/h 時の回転数は6800rpm～7000rpmといったところでしょう。

※ リトルカブ 3速のフロントスプロケを 14T(純正), 15T, 16T と変更したパターンを想定