フレッツの IPv6 を Ubuntu + Open vSwitch でパススルーさせて使う

自宅では長らくフレッツ + YBB を用い、 YBB 支給の光BBユニットによる v4 over v6 でインターネットに接続してきたが、色々面倒なので長らく IPv6 はルーターで遮断し、 IPv4 のみで使っていた。今回、サーバがいるネットワークは一旦除くとして、 PC や携帯電話といったクライアントがいるネットワークについては IPv6 も使えるようにすることにした。

ひかり電話は契約していないので、 IPv6 は /64 のネットワークが一つだけ利用できる。そのため、これ以上ネットワークを分割することはできないので、インターネット接続が可能な IPv6 ネットワークは、全てブリッジ(嘘)で接続する必要がある。しかし、現在 IPv6 でサーバーは立てていないはずではあるものの、一応 LAN の中にあるようなサーバーには、明示的に開けたもの以外は NGN から直接接続できないようにしておきたい。

現在ルーターとしては、YANLING IBOX-501 N13 の Celeron 3855U モデル に Ubuntu 20.04 を入れて利用している。なお、購入履歴を見ると2020年7月に $151.38 で買っているが、今見るとこれ自体はもう購入できないようだ。既にここに繋がっているネットワークに対し、 ONU から IPv6 ネットワークを引くことにする。

なお、光BBユニットではなく ONU 側から Ubuntu ルーターにケーブルを引いたので、光BBユニット特有の事情はここでは登場しない。ただし、 YBB 特有の事情が完全に絡んでいないかどうかはわからない。

Open vSwitch でブリッジ(嘘)を構成する

L2 ブリッジ(嘘)を Open vSwitch で構成する。

まずは

apt install openvswitch-switch

しておく。

(書き忘れていたので追記)今回の構成で、 openvswitch を restart したときに、 bridge と port が残って flow だけ消えて L2 ブリッジ(本当)として動作する状態に戻ってしまい、そのままではセキュリティ上問題がありそうだった。とりあえず、 restart 時に bridge を削除する設定はあったので、これを入れた。

$ grep OVS_CTL_OPTS /etc/default/openvswitch-switch
# OVS_CTL_OPTS: Extra options to pass to ovs-ctl.  This is, for example,
OVS_CTL_OPTS=--delete_bridges=yes

netplan の yaml でブリッジを追加する。br_flets には ONU にブリッジ(本当)で繋がるように設定し、 br_homelan はもとから自宅のネットワークとして使っていたものを想定している。(br_homelan はもとからあったもので、 IPv4 とデュアルスタックのため、 IPv4 の設定が書かれている。)

network:
  bridge:
    ...
    br_homelan:
      interfaces:
      - enpXXXXX
      addresses:
      - 192.168.XXX.XXX/24
      dhcp6: false
      accept-ra: false
      link-local: []
      nameservers: {}
    br_flets:
      interfaces:
      - enpXXX
      accept-ra: false

Open vSwitch で br_flets から br_homelan に IPv6 を、基本的には中から外への通信を許可して最低限の ICMPv6 通信を許可する想定で書いてみる。ただし、これは最終的なスクリプトからこの時点で必要なものを抜粋したもの。なお、このスクリプトを書くには ovs-actions(7) – Linux manual page を参照したが、 table は 0 のままにしてある。

#!/bin/bash -eux

ovs-vsctl --may-exist add-br flets_v6
ovs-ofctl add-flow flets_v6 cookie=0x100000001,priority=10,action=drop

ip link add veth_flets_br type veth peer name veth_flets_ovs || true
ip link set veth_flets_br master br_flets
ovs-vsctl --may-exist add-port flets_v6 veth_flets_ovs

ip link add veth_homel_br type veth peer name veth_homel_ovs || true
ip link set veth_homel_br master br_homelan
ovs-vsctl --may-exist add-port flets_v6 veth_homel_ovs

ovs-ofctl del-flows flets_v6 cookie=0x100000002/-1

ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=320,ipv6,ct_state=+trk+est,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=310,ipv6,ct_state=-trk,action="ct(table=0)"
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=310,ipv6,ct_state=+trk+new,in_port=veth_flets_ovs,action=drop
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=300,ipv6,ct_state=+trk+new,in_port=veth_homel_ovs,action="ct(commit),normal"
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=1,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=2,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=3,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=4,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=133,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=134,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=135,action=normal
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=100,ipv6,icmp6,icmp_type=136,action=normal

ip link set veth_flets_br up
ip link set veth_flets_ovs up
ip link set veth_homel_br up
ip link set veth_homel_ovs up

Open vSwitch と ConnTrack を連携させることにより、基本的に中から外の通信でのみ established 扱いとして通信できるようにしているが、 RA 含め、いくつか通信やアドレス設定に必須と考えられる項目を追加している。この辺りは精査が必要かもしれない、

なお、この後も含め、 priority の指定を昔の BASIC の行番号みたいな感じにしているが、削除して整理できるので一応連番でつけても支障がないはずではある。

LAN 内 DNS サーバー(Unbound)を IPv6 で待ち受ける

基本的には LISTEN はさせるだけではあるが、今回だと IPv6 アドレスは可変で、自分で決定できないという問題がある。そのため、

  • unbound の設定ファイルには、 LISTEN するインターフェイス名の指定はIPアドレス指定はあったが、インターフェイス名指定が見当たらなかった
  • 仮に DNS 自体の LISTEN がうまくいったとしても、それを LAN 内に広報する必要がある

という問題がある。設定ファイルの動的生成はできればやりたくないので、 unique local address (Unique local address – Wikipedia)で LISTEN させて、 LAN 内からのみ到達できるようにする。

なお unique local address はインターネットに流すことができないIPアドレスで、 fd00::/8 のレンジのものだが、どうやら RFC4193 ではなぜか、 fd に続く40ビット(Global ID)を RANDOM な値にするようになっており、 sequentially に割り当てたり well-known な数字を使うことはなぜか MUST NOT になっているようだ。ローカルに閉じている以上 Global ID は自分で管理できていれば支障はない想定だが、真面目にやるなら40ビットの乱数を生成して fd の後に結合することでIPアドレスの先頭48ビットを決定することが望ましいかもしれない。

というわけで netplan の yaml を編集してこのアドレスを持つブリッジを作る。Open vSwitch 経由でしか受け付けないので子は netplan の時点ではいない。また、戻りのパケットを通すため、普通の方法で RA しているブリッジも用意する。

network:
  bridge:
    ...
    br_my_v6:
      interfaces: []
      accept-ra: true
    br_v6dns_l:
      interfaces: []
      accept-ra: false
      addresses:
      - fdXX:XXXX:XXXX:1::1/64

Unbound はこの方法なら普通に LISTEN を追加できる。

    interface: fdXX:XXXX:XXXX:1::1
    access-control: 2400::/8 allow

Open vSwitch でいい感じにリクエストのパケットを誘導する。レスポンスは br_my_v6 の方から出ていくので action:normal にしておけば勝手に帰る。

#!/bin/bash -eux

ip link add veth_my_v6_br type veth peer name veth_my_v6_ovs || true
ip link set veth_my_v6_br master br_my_v6
ovs-vsctl --may-exist add-port flets_v6 veth_my_v6_ovs

ip link add veth_v6dns_br type veth peer name veth_v6dns_ovs || true
ip link set dev veth_v6dns_br address 0e:00:01:00:00:01
ip link set veth_v6dns_br master br_v6dns_l
ovs-vsctl --may-exist add-port flets_v6 veth_v6dns_ovs

ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=410,ipv6,ct_state=+trk,in_port=veth_homel_ovs,ipv6_dst=fdXX:XXXX:XXXX:1::1,action=mod_dl_dst:0e:00:01:00:00:01,output:veth_v6dns_ovs
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=410,ipv6,ct_state=+trk,in_port=veth_my_v6_ovs,ipv6_dst=fdXX:XXXX:XXXX:1::1,action=mod_dl_dst:0e:00:01:00:00:01,output:veth_v6dns_ovs
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=400,ipv6,ct_state=+trk,ipv6_dst=fdXX:XXXX:XXXX:1::/64,action=drop

ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=300,ipv6,ct_state=+trk+new,in_port=veth_my_v6_ovs,action="ct(commit),normal"
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=300,ipv6,ct_state=+trk+new,in_port=veth_v6dns_ovs,action="ct(commit),normal"

DHCPv6 をいい感じにして DNS サーバーを広報する

ここまでの時点で、 RA と別に DHCPv6 が降ってきてはいたのだが、クライアントに到達していなかった(Android ではそもそも DHCPv6 リクエストが行われなかった)。おそらく、行きがマルチキャストで帰りが src もユニキャストだった影響で、 ConnTrack で行きと帰りが別々の接続とみなされたからだと思う。幸いにして少なくとも現時点では RA には DNS サーバーの情報は含まれず、 IPv4 で使っていた DNS サーバーがそのまま使われているようだ。LAN 内の DNS サーバーでないと LAN 内のサーバーの IP アドレスがわからないのでそれ自体は望ましくはあるが、整理しておくのと、一応 IPv6 シングルスタックでも DNS が通るようにしておく。

なお、次のような DHCPv6 の情報が降ってきていた。軽くウェブ検索した限りだと、フレッツではまあまあ使われているサーバーのようには見える。

(DNS-server 2404:1a8:7f01:b::3 2404:1a8:7f01:a::3) (DNS-search-list flets-east.jp. iptvf.jp.)

現時点で、 RA は正しく到達し、 DHCPv6 を使用するようなフラグがセットされているようだ(次の出力は tcpdump を br_flets 側で取得し、 tcpdump で -tnlvv に相当するオプションもつけたもの)。

        hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 300000ms, retrans timer 10000ms

そして、 DHCPv6 の問い合わせも(行うよう実装・構成されている OS では)行われるが、結果パケットが弾かれて到達しないので使用できない。DHCPv6 は RA の送出元に送るわけではないようで、再度マルチキャストで行われるようだ。

なので、自前で DHCPv6 を受け付けて DNS サーバーだけを正しく返すことにする。

Linux の Network Namespace と radvd / dnsmasq で IPv6 SLAAC (+RDNSS) を試す – CUBE SUGAR CONTAINERの「dnsmasq (RA + Stateless DHCPv6)」では、 dnsmasq で RA と stateless DHCPv6 の両方を行っている。ただし、今回は dnsmasq はこの /64 ネットワークの実際のゲートウェイとは別のマシンで動かすので、 RA を行ってしまうと疎通しなくなる。dhcp-range=:: についての説明を man dnsmasq で読んでみても、 DHCPv6 を活かしながら RA を無効にする方法は見つけられなかった(見落としただけであるかもしれないが)。なので、この方法をベースに、 dnsmasq からの RA は Open vSwitch で叩き落すことにする。

#!/bin/bash -eux

ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=420,ipv6,ct_state=+trk,in_port=veth_my_v6_ovs,icmp6,icmp_type=134,action=drop
ovs-ofctl add-flow flets_v6 cookie=0x100000002,priority=420,ipv6,ct_state=+trk,in_port=veth_flets_ovs,icmp6,tp_src=547,action=drop

ついでに、 flets 側からの DHCPv6 は叩き落しておくことにした。

dnsmasq 設定ファイル

interface=br_my_v6  # 既に listen-address がいても追記可能だった

dhcp-range=::,constructor:br_my_v6,ra-stateless
dhcp-option=option6:dns-server,[fdXX:XXXX:XXXX:1::1]

ただし、この方法では、将来フレッツが RA に RDNSS を付すようにしたときには、宅内の DNS サーバーでないと参照できない接続先へのアクセスでは困りそうだ。

IPv6 テストサイトの結果

The KAME project のウェブページでは、無事に踊っている亀を見ることができた。

https://ipv6-test.com/ では、次のようになった。

簡易速度測定

Ubuntu 21.04 のラップトップで、 IPv4 を無効にして IPv6 のみで今回で構成したネットワークに接続したところ、正しく DNS も解決され、 https://www.google.co.jp/ や https://nhiroki.net/ などの IPv6 接続が可能なウェブページには接続できた。また、その環境で、 Google 検索で “speedtest” と検索して出てきた Google 組み込み(Measurement Lab と提携とのこと)のスピードテストでは、次のような結果になった。

なので、ギガビットのインターネットの想定であれば、 Celeron 3855U + Ubuntu + Open vSwitch で IPv6 のブリッジ(嘘)を実現するのは、性能上は妥当だと言えそうだ。

sshrc の内容に関するメモ: Xforward で必要

ssh で X 転送しようとすると次のようなエラーが出て困っていた。ぐぐってもよくわからなかった。

PuTTY X11 proxy: Unsupported authorisation protocol

原因は色々あるようだがググって出てきたものがなかなか当てはまらなかった。別サーバと比べたりしていたところ、 .ssh/rc を置いている場合、 /etc/ssh/sshrc が呼び出されないため、この内容がないと困ることがわかった。man sshd すると SSHRC の項に説明とサンプルファイルがあり、これが .ssh/rc を置いていることに阻害されていただけだった。.ssh/rc に man の内容に従って xauth 関連の記述を追記すると繋がった。

USB – 5Gbps Ethernet アダプタを買ってきた

業務外での技術力向上支援の会社の補助金で、 USB – 5Gbps Ethernet アダプタをいくつか購入し、まずはざっくり普通に繋ぐとどうなるのか試してみたのでメモ。

買ったもの

10G/5G アダプタ

以上の4つ。Solo10G のみ Thunderbolt 接続で 10Gbps だが、他が USB 接続で 5Gbps。なので今のところ、 10Gbps で繋がる相手がいないので、今回はすべて 5Gbps として使用。

ドライバ

Solo10G については 、 Windows 版のドライバをインストールして使用した。Solo10G ドライバとしてダウンロードしたものが、実際に起動したものは Aquantia のドライバインストーラだった。QNAP QNA-UC5G1 と、 StarTech.com のものは、いずれも Windows 10 では OS 標準か Windows Update かでドライバが入った。

Linux には USB の二機種(QNAP、StarTech.com)を接続したが、いずれも Aquantia 製のコントローラが入っているようで、 aqc111 というドライバが提供されている。ただし、 Linux 5.x には標準に同梱されているが、 Linux 4.x だと入っていないのでそのままでは他のドライバが適用される。また、 Linux 5.x 標準のものと、 AQ_USBDongle_LinuxDriver_1.3.3.0.zip (QNAP のウェブページよりリンクされていた、Marvell のサポートページよりダウンロード)で提供されているものは両方 aqc111 という名称で、かつ後者を解凍して出てくる README にも aqc111 Linux 5.x に同梱されているとの表記があるが、 ethtool で見ることができる項目が若干後者の方が多い(Low Power 5G と Thermal throttling が設定可能になる)など、若干の差があるようだ。

Linux 4.x の搭載ドライバ(試した環境は Ubuntu 18.04)でも、 1Gbps を超える転送が可能であり、接続相手からも 5000Mbps リンクとして認識されていた。ただし、ジャンボフレームを有効にした際に、大きなパケットを受信すると以後通信ができなくなるという問題があった。Linux 5.x (Ubuntu 20.04)にすると問題なかった。

クライアント-サーバー直結での性能測定

転送速度については、まずは Solo10G (ThinkPad X1 Extreme (Core i7-8750H 2.20GHz、 Windows 10 1909) に接続) と QNAP QNA-UC5G1T (DS77U5 (Core i5-7200U 2.50GHz、 Ubuntu 18.04/20.04) に接続)をケーブルで直結して測定した。

iperf で接続したところ、まず初期設定の MTU=1500 で、 iperf の並列度も上げずに試したところ、 2.1-2.3Gbps 程度だった(この時は Ubuntu 18.04)。この状態で、 QNAP 側を USB パススルーで Ubuntu 20.04 に見せるようにすると 1.1Gbps 程度まで下がった(これについては qemu のバージョンアップなどでも改善するようで、 Ubuntu 20.04 だと 2.0-2.5Gbps 程度出た)。

この後、 MTU=9000 に変更すると、その時のベンチマークでは iperf の並列度が 1 のままでも 3.63Gbps という転送速度が出た。ただし、前述の 4 系カーネルバンドルのドライバではジャンボフレーム受信が正常に行えない問題により、片方向しか通信できなかった。

さらにここまでの試行錯誤(主にジャンボフレームでトラブっていた時)で、 Solo10G のデバイスマネージャーの設定値で、 Large Send Offload V1, V2 の IPv4 の値をいじっている。結局、これは Disable のほうが当座の iperf でのスループットが出そうなので、今回の調査切ることにした。ただし、 iperf 側で並列化させない直列の転送速度でアプリケーション側込みだと Large Send Offload 有効のほうが速そうに見えたため、この辺りはよく確認したほうがよさそう(まだ詳細は調べていない)。そもそも、普通にしていて遅くなるようなものなら通常は offload しないだろうし。

ここからは、クライアント-サーバー直結での測定は次のような環境で試している。

  • Sonnet Solo10G, ThinkPad X1 Extreme, Core i7-8750H 2.20GHz, Windows 10 1909
  • QNAP QNA-UC5G1T, DS77U5, Core i5-7200U 2.50GHz, Ubuntu 20.04, Ubuntu 同梱 aqc111 ドライバ
  • MTU=9000 (Windows のプロパティの Jumbo Packet では 9014 Bytes)
  • Windows 環境では Large Send Offload V1, V2 (IPv4) を Disable
  • この前の段階でも iperf の並列度(-P) 1 で 3Gbps を超える速度が出たりしていたが、同じ条件でも再度試すと出なかったり、疑問だったので、この条件を決めてからは iperf の並列度は合計の速度が上がらなくなるまで上げる

この状態で、とりあえず 3.4Gbps 程度までは出せることがわかった。USB 側との接続も 5Gbps となるため、そちらで詰まれば製品としての上限がこのあたりに来る可能性はあるが、そこまでは確認していない。

nhirokinet@ds77u5:~$ iperf -c 192.168.150.2
------------------------------------------------------------
Client connecting to 192.168.150.2, TCP port 5001
TCP window size:  715 KByte (default)
------------------------------------------------------------
[  3] local 192.168.150.3 port 34642 connected with 192.168.150.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  4.00 GBytes  3.44 Gbits/sec
nhirokinet@ds77u5:~$ iperf -c 192.168.150.2
------------------------------------------------------------
Client connecting to 192.168.150.2, TCP port 5001
TCP window size:  812 KByte (default)
------------------------------------------------------------
[  3] local 192.168.150.3 port 34646 connected with 192.168.150.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  3.84 GBytes  3.30 Gbits/sec
nhirokinet@ds77u5:~$

また、全二重でも速度が出せるようだった。

ちなみに、 USB パススルーでの転送速度は、 Ubuntu 18.04 -> 20.04 で qemu のバージョンが上がっていることもあり、改善されたが、片方向で 2.0-2.5Gbps、双方向同時ならそれぞれ 1.5-1.7Gbps (あわせて 3Gbps 強)というところだった。

Ubuntu でのパケットの中継

Ubuntu をスイッチとして使ったような場合に、性能上限が変わってくるのか、といったあたりを見たかったため、簡単に試した。

環境は

  • Sonnet Solo10G, ThinkPad X1 Extreme, Core i7-8750H 2.20GHz, Windows 10 1909
  • StarTech.com アダプタ x 2、 DS77U5, Core i5-7200U 2.50GHz, Ubuntu 20.04, Ubuntu 同梱 aqc111 ドライバ
    • Linux 標準のブリッジにより libvirtd 上の仮想マシン(qemu+kvm, 3vCPU, Ubuntu 20.04)に NIC を見せる
    • 二つの StarTech.com は DS77U5 親機側では別物として扱ってブリッジも別々に作り、パケットの転送は VM 側で行う
  • QNAP QNA-UC5G1T, ThinkPad W550s, Core i7-5600U 2.60GHz, Windows 10 1909
  • MTU=9000 (Windows のプロパティの Jumbo Packet では 9014 Bytes)
  • Windows 環境では Large Send Offload V1, V2 (IPv4) を Disable
  • この前の段階でも iperf の並列度(-P) 1 で 3Gbps を超える速度が出たりしていたが、同じ条件でも再度試すと出なかったり、疑問だったので、この条件を決めてからは iperf の並列度は合計の速度が上がらなくなるまで上げる
  • この条件で、 ThinkPad X1 Extreme – Sonnet Solo10G – StarTech.com アダプタ1 – DS77U5 – StarTech.com アダプタ2 – QNAP QNA-UC5G1T – ThinkPad W550s と接続し、 DS77U5 上の VM で 3Gbps 程度でのパケット転送が可能か、試した。

    まず、/etc/sysctl.conf に

    net.ipv4.ip_forward = 1
    

    を追記し、 sysctl -p /etc/sysctl.conf を実施して反映して、別々のサブネット間をそのまま転送したところ、並列度を挙げれば 3.5Gbps 程度まで達した。

    次に、

    iptables -t nat -A POSTROUTING -o ens9 -j MASQUERADE
    

    (ens9 はここでは iperf -s をしているマシンと繋がっている NIC)を実施して、最低限の NAT を行うようにしたところでも、やはり並列度を上げると 3.5Gbps 程度まで達した。3vCPU を付しているものの、 VM の top で見たところでは、(3vCPU 全体を 100% とみなした割合で)3Gbps 以上で NAT 中でも idle が 95% 以上となっていた。

    もちろんこれではファイヤーウォールとしての機能は弱く、ここから iptables の設定を増やせば速度の低下は予想されるものの、この結果からは、ここで購入した機器を利用して、i5-7200U と同等かそれ以下のマシンを利用し、 3Gbps 以上のパケットを転送することができる可能性がありそうに思える。

    libvirtd を Ubuntu 18.04 にインストールし、部屋の LAN とブリッジする

    自宅では長らく VMware ESXi を使用してきて、大変良かったのだが、ホストが Linux だと何かと楽だろうと考えたりしていたり、DS77U5 への移行のタイミングでホスト側に直接 Docker で入れられるものは直接入れたくなったりしたのもあり、新たに libvirtd を検証開始。意外とすんなり入って中の状態も分かりやすい感じにはなったが、(主に libvirtd に直接関係ない)よくわからないところに罠があったのでメモ。

    なおこの前に OpenStack を試そうとしたが、 conjure-up が半端に色々ラップしたまま失敗してどうなっているのかさっぱりわからない状態になったのを見て OpenStack は諦めた。

    まずは、 Ubuntu 18.04: 仮想化のKVMをインストールする – Narrow Escape にしたがってパッケージを入れた。ただし、 libguestfs-tools は要らなそうだったので、今のところ入れていない。なお、 /var/lib/libvirt に色々保存するようだったので、通常必要ない操作だがインストール前にこのディレクトリを実際に保存したいパーティションにシンボリックリンクとして指定した。

    $ sudo apt install -y qemu-kvm libvirt0 libvirt-bin virt-manager
    

    また、

    $ sudo gpasswd libvirt -a `whoami`
    

    続いて、ブリッジネットワークを構成する。いつの間にか(多分 LTS だと 18.04 から?) /etc/network/interfaces がもぬけの殻になっていて、 netplan に移行したから /etc/netplan/ を見ろと言っているので、 /etc/netplan/01-netcfg.yaml を編集した。なおこのファイルの名前は、環境によっては 50-cloud-init.yaml などになるようだ。

    なお、ブリッジ側の MAC アドレスは起動するたびにランダムに変わるようで、 DHCP で固定の IP アドレスを配るのに問題があるので、固定した。IP アドレスを static でホスト側で指定するなら不要と思われる。また、 VM で検証しているときはホスト側の仮想スイッチでプロミスキャスモードを禁止しているために通信がうまく行えない罠にはまっていた。

    あと、 macvcap でホストの LAN に直接刺せそうな選択肢があるが、これはブリッジではなく NIC をその VM で占有する時に使うもののようなので、 VM とホスト両方、あるいは複数 VM で使うときはブリッジ構成は必要なようだ。

    # This file describes the network interfaces available on your system
    # For more information, see netplan(5).
    network:
      version: 2
      renderer: networkd
      ethernets:
        enp1s0:
          dhcp4: no
      bridges:
        br0:
          macaddress: XX:XX:XX:XX:XX:XX
          dhcp4: yes
          interfaces: [enp1s0]
    

    これで

    $ sudo netplan generate
    $ sudo netplan apply
    

    などとするとブリッジが構成できたが、古いものが消えなかったりして微妙にこのファイルの定義とずれていくようなので、素直に

    $ sudo reboot
    

    するのがよさそう。

    これでブリッジが構成されるので、

    $ sudo brctl show
    bridge name     bridge id               STP enabled     interfaces
    br0             XXXX.XXXXXXXXXXXX       no              enp1s0
                                                            vnet0
    docker0         XXXX.XXXXXXXXXXXX       no              vethXXXXXXX
                                                            vethXXXXXXX
    virbr0          XXXX.XXXXXXXXXXXX       yes             virbr0-nic
    

    みたいな感じで brctl でブリッジが見え、 ifconfig でも DHCP から降ってきた IP アドレスが見れるようになった。

    なお、 vnet0 というのが、 libvirtd でブリッジに接続したときに VM と紐づけて作る tap インターフェイスのようだ。なので、この状態で enp1s0, br0, vnet0 は同じ L2 として自由に疎通できそうだが、実際には br0 をまたいだパケットがやりとりされない現象に悩んだ。tcpdump を見ても、 enp1s0 から流れてきたパケットは br0 には流れているが vnet0 には流れず、 vnet0 から流しているはずの DHCP discover も br0 には流れているが enp1s0 には流れなかった。

    結局、 networking – why linux bridge doesn’t work – Super User を見て、 iptables が L2 に干渉してくるのか疑問に思いながらも試してみたところ、echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables によって実際に解決した。よくわかっていないが、どうやら自分のホストに来てしまった時点で L2 な転送でも iptables を通ってしまうようだ。

    なのであとは /etc/sysctl.conf 相当のファイルに

    net.bridge.bridge-nf-call-iptables = 0
    

    という内容を書くことになるが、ここにも罠があった。

    まず、 Ubuntu 18.04 だと /etc/sysctl.d といういかにもディレクトリがあり、 /etc/sysctl.d/README にはご丁寧に

    After making any changes, please run “service procps start” (or, from
    a Debian package maintainer script “invoke-rc.d procps start”).

    とまで書いてあったのだが、なぜか動かなかったので、結局昔ながらのやり方で /etc/sysctl.conf に書き込むことにした。

    しかし、これでは sysctl -p /etc/sysctl.conf や invoke-rc.d procps start では反映されるものの、再起動するとなぜか 1 に戻ってしまう。該当範囲は不明だが、少なくとも Ubuntu 18.04 では procps のサービス起動(sysctl.conf 読み込みを実施する)をネットワークが有効になる前に実施してしまうので、ネットワーク関係の設定はここに書いても無視されてしまうようだ: Ubuntu 18.04 で ipv6 を無効にする | 雑廉堂の雑記帳

    少なくとも net.bridge.bridge-nf-call-iptables は /etc/rc.local でもうまくいかなかった。そのためネットワーク関係のあれこれが起動しているであろう net if の post-up にねじこみたかったが、FAQ | netplan.io によるとそのようなものはまだないようで、代わりに networkd-dispatcher で設定するよう勧められている。幸い、手元の Ubuntu 18.04 では OS インストール時に networkd-dispatcher がインストールされていたようだったので、次のようなファイルを作成することで、再起動しても sysctl.conf が読み込まれて、ブリッジなら iptables を無視してパケットが行き来できるようになった。

    $ cat /usr/lib/networkd-dispatcher/routable.d/99sysctlworkaround
    #!/bin/sh
    /etc/init.d/procps restart
    exit 0
    $ ls -al /usr/lib/networkd-dispatcher/routable.d/99sysctlworkaround
    -rwxr-xr-x 1 root root 46 Jul  6 20:57 /usr/lib/networkd-dispatcher/routable.d/99sysctlworkaround
    

    これでようやく、 libvirtd に br0 を認識させて、直接 enp1s0 に出ていけるようになった。

    MAC アドレスは中からも外からもホストの vnet0 としても、ここに表示されたものになるようだ。ESXi ではマシンを一回立ち上げるまで MAC アドレスがわからないが、 libvirtd + virt-mangaer では最初に起動する前から表示されるので、インストール前に DHCP/DNS に登録できるのは便利。

    (2019/7/23 追記)UEFI ベースの VM を移植するに、 UEFI/OVMF – Ubuntu Wiki にあるように apt install ovmf して UEFI 用のファームウェアをダウンロードする必要があった。また、他のところで使っていた UEFI ベースの VM イメージを取り込む際、 BIOS メニューに入る前(Tiano core ロゴ)に F2 を連打してメニューから efi ファイルを直接選択して起動し起動後に grub-install して起動すべきファイルを認識させる必要があった。

    OPNsense を Protectli Vault FW1 にインストール、 VyOS と簡単に比較

    前回までで、 Protectli Vault FW1 に VyOS インストール簡単な速度測定をしたので、 OPNsense に乗せ換えて比べてみた。

    OPNsense のウェブページから USB メモリ用の img.bz2 をダウンロードして、bz2 を解凍してディスク(パーティションではない)に丸ごと dd で書き込み、そこから boot した。vga なイメージをダウンロードしたにも関わらず画面は Booting で止まり、シリアルポートからしか見えなかった。シリアルポートでも起動時・終了時以外は特に何かが出るわけではないが、起動時にはそれぞれの端子の IP アドレスなどが出るので便利ではある。ちなみに、 115,200 bps なので Vault の BIOS の初期設定と同じでちょうどよい。

    Live イメージになっていてそのままでも利用は可能で、”WAN” で DHCP が利用可能だと “LAN” のポート(ただし初期設定では em0 なので、 Vault FW1 では “WAN” と印刷されている)からそのままインターネットに出ることができた(DHCP も動いている)。LAN 側に繋いで 192.168.1.1 宛に ssh (ユーザ名 installer、パスワード opnsense)でインストールできた。その時立ち上がっている WebUI からは installer ログインできないようだ。

    起動後も初期設定は WAN と LAN が逆になっているが、管理画面から割り当てを変えることで管理画面の表示と印刷を合わせることができる。割り当て変更直後は DHCP がうまくうごかないのか、一度電源ボタンを単押ししてシャットダウンしたあと起動した。もっといい方法はあるかもしれない。

    なお、大抵のサービスは初期設定で全インターフェイスで LISTEN するようになっているので、探して LAN に変更する方がよさそう。

    OPNsense は初期設定でも最低限のファイヤーウォールが設置されているようで、色々設定画面に出てきた。Linux (iptables) と FreeBSD の違いか、かなり設定項目が違ったので、ひとまず初期設定で前回と同じ構成で iperf を通したところ、次のようになった。

    Vault の top

    39 processes:  1 running, 38 sleeping
    CPU:  0.0% user,  0.0% nice, 30.7% system,  0.1% interrupt, 69.2% idle
    Mem: 115M Active, 103M Inact, 182M Wired, 31M Buf, 7418M Free
    Swap: 8192M Total, 8192M Free
    

    iperf

    TCP window size: 85.0 KByte (default)
    ------------------------------------------------------------
    [  3] local 192.168.1.101 port 57712 connected with 192.168.100.37 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-20.0 sec  2.18 GBytes   935 Mbits/sec
    

    PC Junkie rev2.4 – 【NW】pfsense VS Vyatta でも Vyatta は pfSense と比べて同じスループットでも CPU 使用率がはるかに低かったと報告されているが、今回の比較(VyOS と OPNsense)でも概ね同じ傾向のようだ(前回は VyOS は初期設定で 1% 未満、ファイヤーウォールを構成していくつか設定すると7%くらいだった)。

    また、電源ボタンを押すと OPNsense が正常にシャットダウンした。

    とりあえず、最初にインストールして気付いた差は次の通り。単純な設定でのスループット性能としては VyOS の方が優れていそうではあるが、どちらも Gigabit な環境でルータにするのに不足ということはなさそう。OPNsense は WebUI で色々いじれたりする点などもあり、ひとまずは OPNsense を使ってみることにした。

    項目 VyOS OPNsense
    NAT 930Mbps での CPU 使用率 初期設定1%未満
    いくつか FW を設定すると 7% (条件は前回)
    初期設定約30%
    初期インストールでの SSD 消費量 約 500MB
    (約 1GB を squashfs 圧縮)
    約 1GB
    WebUI なし あり

    VyOS 負荷測定 on Protectli Vault FW1

    Protectli Vault FW1 に VyOS を入れて、一応はファイヤーウォールも形だけ設定した状態での速度を計った。1Gbps リンク程度なら Celeron J1900 でも余裕な模様。

    なお、自宅配線の都合上別のルータが挟まっていたりしてこれも正確な測定ではない。あくまで Vault FW1 + VyOS の負荷状況を確認するもの。

    ルール

    (show config の結果のうち NAT に関係ないものは省略、よくわからないけど公開するほどでもない LAN 内のパラメタは **** にした)

    firewall {
        all-ping enable
        broadcast-ping disable
        config-trap disable
        ipv6-receive-redirects disable
        ipv6-src-route disable
        ip-src-route disable
        log-martians enable
        name WAN_TO_LAN {
            default-action drop
            rule 100 {
                action accept
                state {
                    established enable
                    related enable
                }
            }
            rule 110 {
                action accept
                destination {
                    port 22
                }
                protocol tcp
            }
            rule 120 {
                action accept
                destination {
                    port 5001
                }
                protocol tcp
            }
        }
        receive-redirects disable
        send-redirects enable
        source-validation disable
        syn-cookies enable
        twa-hazards-protection disable
    }
    interfaces {
        ethernet eth0 {
            address dhcp
            duplex auto
            firewall {
                in {
                    name WAN_TO_LAN
                }
            }
            hw-id ****
            smp-affinity auto
            speed auto
        }
        ethernet eth1 {
            address ****
            duplex auto
            hw-id ****
            smp-affinity auto
            speed auto
        }
        ethernet eth2 {
            duplex auto
            hw-id ****
            smp-affinity auto
            speed auto
        }
        ethernet eth3 {
            duplex auto
            hw-id ****
            smp-affinity auto
            speed auto
        }
        loopback lo {
        }
    }
    nat {
        destination {
            rule 1 {
                destination {
                    port 23
                }
                inbound-interface eth0
                protocol tcp
                translation {
                    address ****
                    port 22
                }
            }
            rule 2 {
                destination {
                    port 5001
                }
                inbound-interface eth0
                protocol tcp
                translation {
                    address ****
                    port 5001
                }
            }
        }
        source {
            rule 99 {
                outbound-interface eth0
                source {
                    address ****
                }
                translation {
                    address masquerade
                }
            }
        }
    }
    

    WAN -> LAN (LAN 側が iperf における -c)
    転送速度

    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec
    

    LAN -> WAN (LAN 側が iperf における -s)

    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
    

    WAN -> LAN の際の Vault

    %Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 93.3 id,  0.0 wa,  0.0 hi,  6.5 si,  0.0 st
    

    このページで出せる考察

    ジャンボフレームなどは無効なまま iperf でこの速度が出ているので、ギガビット(TCP/IP ならペイロードは理論値で 950Mbps 未満なはず?)は使い切って CPU が余っているといえそう。

    ルータの自由度を上げるために Protectli Vault FW1 を買ってきた

    現在家のルータは RouterBoard RB3011-UiAS-RM を使っているが、Protectli Vault FW1 の存在を知り、より自由度が高い遊べる環境を用意しようと思って購入した。

    買い物

    今回は Amazon.com で買ってきた。Amazon.com でのページは Firewall Micro Appliance With 4x Gigabit Intel LAN Ports, Barebone だが、今は全く同じものは売り切れているようだ(同じシリーズの他のものはある)。買ったときは $199.00 で、それに送料 1,272 円と Import Fees Deposit 1,915 円(多分ドル建てで決まっていたはずだが、 Invoice では JPY になっている)がかかった(勤務先にはこういう時に使える会社の費用補助があるので自己負担はもっと少ない)。

    今回購入したのはベアボーンなので、 RAM と SSD を買う必要があった。 RAM は DDR3L で最大 8GB、 SSD は mSATA で、それぞれ次のものを買った。

    なお、どちらも滅びかかっている規格のようで、 DDR3L RAM はいくつかの店にあったが、 mSATA SSD は秋葉原ではそもそもほとんどの店に存在せず、あっても 8000 円以上するモデルしか見当たらなかったため Amazon で購入した。ちなみに、 RAM は刺さないと画面にも何も映らないので、動作確認には最低でも RAM が必要。

    届いた商品

    マザーボードはこのような感じになっている。マザーボードに YANLING のロゴがあるので委託先かもしれない。YANLING のページを見ると、YANLING の N10Plus がほぼ同じ製品であるように見える。筐体裏面には Made in China と書いてあり、時計も中国の標準時に設定されて出荷されてきた。

    ファンレスなので音もせずとても静かで、大きさもさすがにポート数の同じスイッチングハブよりは大きいものの、それと比べたくなる程度には小さい(普通の L3 扱えるルータと比べるとむしろ小さい気がする)。

    また、 BIOS には「電源オン状態で電力供給が途絶えた場合、電力が復活したら自動でオンに戻る」設定があり、標準で有効になっているようだ。BIOS 画面で AC アダプタを引っこ抜いて落ちた後アダプタを戻したら、自動で OS が起動した。ルータは常時起動していることを想定するので、この機能はありがたい(hp ML115 でも見た気がするので、デスクトップパソコンをあまり使わないから知らないだけでよくある機能なんだろうか)。

    なお、 AC アダプタは Protectli 40W Power Supply – Protectli の商品画像と同じ、 CHANNEL WELL TECHNOLOGY なる会社のものがきた。商品紹介ページでは 110-240V と書いてあったり FAQ では 100-240V となっていたりするが、商品画像と同じく 100-240V と書かれたものがきた。アダプタ本体とケーブルの間は PC やモニタの電源でよく見る端子なのでその辺で買えそうなケーブルだった。日本でそのまま使える type-A だがアース付きなので、タップにアースがない場合は3ピン→2ピンをかますか、ケーブルを買い替えることになると思われる。

    Ubuntu MATE で動作確認

    まず最初に、 RAM だけ買って SSD なしの状態で Ubuntu MATE のインストーラの USB メモリを刺したところすんなり GUI が立ち上がった。

    電源ボタンも Ubuntu MATE 側できちんと認識して、押されたらダイアログを出すなりなんなり OS で設定した動作をするようだ。

    VyOS 入れてのテスト

    SSD が到着したら、とりあえず VyOS を入れてみた。FW1 FW2 FW4A Series Hardware Overview – Protectli の説明通り、 WAN が eth0、LAN が eth1 に割り当たっていた。

    また、添付のケーブルを使うことでシリアルポートも利用できた。BIOS 画面をシリアルポートに転送する機能がついていて、 OS が起動した後は OS から見えるようになっているので VyOS もシリアルポート越しに利用できた。VyOS では GRUB で Serial console を選ぶと起動画面もシリアルで流れてくる( GRUB は VGA とシリアルポート両方に表示された)

    ただし、 BIOS 画面が出ている状態でのシリアルポートは How to use the Vault’s COM port – Protectli の説明通り 115,200 bps なのに対し、 VyOS の初期設定は 9,600 bps なので、切り替えないと途中で画面が表示されなくなる。BIOS も VyOS も設定項目はあるようなので、使うならどちらかに統一しておいた方がよさそう。

    VGA あるから家ならそちらを使えばいい感はあるが、 GPD microPC とか持っていたらシリアルポートが利用できるのが便利なのかもしれない。

    インストールしたら、次の二つを参考に VyOS で NAT 構成してみた。まだファイヤーウォールなどは設定していない。インストールも含め、特に問題らしい問題は少なくともデバイス由来のものは起こらなかった。

    簡単な速度測定

    この状態で、ざっくり NAT 越しに速度を測定してみた。

    Protectli で NAT を構成し、 ThinkPad を LAN 側に、部屋の LAN WAN 側にして、部屋の LAN においた ML115 (の上に増設された何かの NIC)と、 ThinkPad の間で NAT 越しの iperf を試してみた。

    iperf

    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-20.0 sec  1.65 GBytes   709 Mbits/sec
    

    通信中の Protectli Vault の top

    %Cpu(s):  0.0 us,  0.1 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.6 si,  0.0 st
    KiB Mem:   8051500 total,   286864 used,  7764636 free,    31692 buffers
    KiB Swap:        0 total,        0 used,        0 free.   138536 cached Mem
    

    (追記:この後 ThinkPad を測定用とせずデスクトップ/サーバ構成のマシン同士で測定したところ、簡易測定でもスループットが 930 Mbps を超えたので、Protectli Vault FW1 + VyOS のせいで 800Mbps を下回っていたわけではなさそう:VyOS スループット測定 on Protectli Vault FW1 | にろきのメモ帳
    (追記:↑しかし ThinkPad も状況により 900Mbps を超えたので原因はよくわからない)

    RouterBoard RB3011UiAS-RM 導入

    自宅のルータは長らく iptables, dnsmasq あたりで構成した Ubuntu VM で実施してきたが、障害時の対応が面倒なのに加えて、サーバメンテナンス中という何かと急いでぐぐりたい場面で自宅インターネットが使えないという致命的な問題があったので、以前名前を聞いておもしろそうだった MikroTek 社の RouterBoard に移行した。Linux ベースの RouterOS なるものを搭載していて、 RB3011UiAS-RM は ARM ベースとのこと。ネットワーク機能も含めてなにかと仮想化がもてはやされるこのご時世、 VM からアプライアンスに移行するのは時代に逆行しているような気もするけど、自宅だとスケールメリットはおろか冗長構成ですらデータ保全ぐらいしかしないので、シンプルなアプライアンスがよいと判断。ちなみに、 1U Rackmount と書かれているが、この機種は奥行きが狭いのと、 1U ラックの横幅として言われる 19 インチ(482.6mm)はサーバルームで見るとでかそうに見えるが意外と家における大きさなのもあって、ラックサーバを置く気にならない自宅でも意外と現実的な大きさだった。ラックマウント用の金具の他に、普通にその辺に置く用のゴム足も付属した。

    今回は、 RN3011UiAS-RMBaltic Networks から購入した。購入したときは取り寄せが必要で一か月くらいかかるとのことだったが、今見ると In Stock なので時期によるかもしれない。購入時、発送方法は料金だけを見て無料だった “Pick up at Lisle warehouse” を選んだが、「請求先も発送先も両方日本なので、この選択肢はおかしい。これらの選択肢の中から適切なものを指示してほしい」というメールがきて、返信すると対応していただけた。あとで気付いたのだけど Lisle は Baltic Networks の拠点の地域なので、これは Lisle warehouse という名前の業者に関する何かではなく、「Lisle の倉庫まで取りに行く」という意味だったのかもしれない。ちなみに AC アダプタのプラグは US 用で、日本と同じ形で 100V にも対応していたのでそのまま使用できた。品物 $145.00, 送料(FedEx International Economy) $49.59 で計 $194.59。

    左 5 ポート、右 5 ポート、 SPF 1 ポートで、基本的にはポートごとに設定をすることができるようだ。ただ、左右それぞれ最大一つ master port を選ぶことができ、左右それぞれ master port を含むポートを 5 ポートの中から任意で選んで master port にぶら下げるとそれらは同一の L2 セグメントとして wire speed で通信できるようだ(この場合 slave port についてはちゃんと設定がいじれないようになっているっぽい)。左右をまたぐ場合は bridge を構成して実現するようになっている。初期設定では ether1 が DHCP で外、それ以外は中というよくある自宅ネットワークを想定したものになっており、 bridge の下に ether1 以外を治める左 master port、 右全部の master と SPF がぶら下がっていた。

    まだあまりいじれていないが、メニューを見て色々できるな、と思ったのと同時に、例えばファイヤーウォールの設定画面で言えば iptables の設定で登場する用語がそのまま登場していた。DNS, DHCP に関しては GUI でいじれるが、 dnsmasq みたいに DNS が DHCP と連携するみたいな機能はないのでそこは手動でどうにかするしかなさそう。だいたいの設定は Web 画面でいじれそうで、試していないものの(VPN 等に使うと思われる)証明書発行用 GUI も Web にあった。ターミナルもブラウザから開くことができたほか、 ssh などでも使えるので、通常はルータへの接続のためにシリアルケーブルを用意する必要はなさそうだった(内蔵の液晶で IP アドレスもわかるし)。

    とりあえず、最低限のファイヤーウォールだけ設定して、普通にルーティング(IPv4 で、ネットワークは異なって RouterBoard のポートも別だがマスカレードではないルーティング)経由で iperf してみたところ、

    ------------------------------------------------------------
    Client connecting to ***, TCP port 5001
    TCP window size: 85.0 KByte (default)
    ------------------------------------------------------------
    [  3] local *** port 54934 connected with *** port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  1.05 GBytes   901 Mbits/sec
    

    さすがにただのルーティングは充分速度が出るようだった。

    また、実際に RB3011UiAS-RM 自身で IPv4 マスカレードするように構成して、インターネット(上流に IPv4 を IPv6 にトンネルする ISP 支給のルータがいるので PPPoE ではない)に繋いで www.speedtest.net で試してみたところ、

    500Mbps 以上のスループットが出せることが確認できた。ファイヤーウォールの項目数を増やすとどうなるかはわからないのと、そもそも普通の ISP 経由のインターネット経由なのでこれが上限でもない(事実導入前と比べて遅くはなっていない)ので資料としては不充分なものの、自宅のインターネット用としては充分な速度が出ると言えそうだった。

    内蔵液晶パネルに何を表示するかは選択可能だが、 Informative Slideshow だと全ポートの合計スループットから電圧、ファームウェアバージョン、時刻まで色々と出してくれる。一方、 Slideshow だとポートごとのグラフを出してくれるようだ。実用的というよりかは眺めていて飽きないという内容といえる。ちなみに、液晶自体は自動パワーオフの時間が設定可能だが、どちらかというと電源ランプの青色 LED が眩しいので(我が家のように)寝床と隔てがない空間に置く場合は、人によって(例えば僕のような場合)は直接光と壁への反射について対策をしたほうがよい。

    ちなみに設定は困ってぐぐったら割と MikroTik Wiki が出る。ちなみに設定だいたいをエクスポートする /export というコマンドもあるようだ。

    一方、最初に困ったのは AC アダプタで、運よく米国のサイトから仕入れたため AC アダプタもそのまま使用できたが、 DC 側が接触が微妙なようで、少し抜ける側に力が加わっただけで DC 入力が途絶えるようだ。力を加えようと思わないのに途絶えるほどではないのと、アダプタと本体どちらの不具合か、または仕様かもわからないのにどれほどかかるかわからない海外への依頼をするのも面倒なので運用でカバーすることにした(後半に追記あり;やっぱり解決することにした)。本体裏には謎の溝がありアダプタの DC ジャック付近のケーブルはそこにかませて仮固定できる。また、電圧は 10-28V (付属アダプタの出力は 24V)と幅広く受け付けているので直径さえあえば適当な AC アダプタを使うことはできそう。

    また、この機種は感圧式タッチパネル付き液晶画面を備えているが、購入当初は(初期設定で 1234 の)暗証番号の入力すらも困難な状態だった。これに関しては Web UI 経由で Recalibrate を押し、その後タッチパネル側で指示に従ってキャリブレーションすることで完全に解消された。

    まだ設定は完了していないが、一通り安定導入後も遊び用のポートを空けておいていじってみたいと思えた。

    (2017/8/16 追記)証明書の署名操作(実際には秘密鍵の生成から実施している可能性がある)で分単位から十分単位の時間がかかるようだ。WebUI だとすぐ、ターミナルだと一定時間経った後にレスポンスがあるが(後者はタイムアウトとの表示)、実際には証明書の生成作業を行っており、先ほどレスポンスが返ってきた操作は終わっていない、かといってテンプレートの削除は Template being used! というエラーメッセージになる、そして数分待つと削除できる、という状態になった。WebUI の Tools > Profile で様子を見ることができる。見る限り、 CPU を 100% (コア単位)使っているようなのだが、この機械はデュアルコアなので 200% まで使えるので複数同時に走らせたりしなければ大丈夫そうだ。ARM CPU にしても秘密鍵生成、電子署名ってそんな時間かかる……?とは思うが、かかるものは仕方がないのでそういうものと思って使うのがよさそう。

    (2017/8/28 追記)AC アダプタがゆるい問題は、秋月電子通商で外径 5.5mm 、内径 2.1mm で中央がプラスの、24V/1.5A の AC アダプタ(1,500 円)を買ってきたところ解決した。少なくとも今のところ、店舗の張り紙によると取り扱っているのはこの大きさ/極性しかないらしいので、大きさがあうものが取り扱われていたのは運がよかったということか。
    なお、オンラインにあった説明書で 5.5mm/2mm と書かれていた。また、 [solved] Power connector problem in RB2011-RM and RB3011-RM – MikroTik RouterOS に同様の現象で悩んでいる状況の書き込みがあり、色々と分析がなされていたが、新機種にバンドルされた電源ユニットはゆるすぎて、旧機種のものが新機種にもちょうどよいというコメントや、内径が 2.5mm のアダプタだとゆるくなって、 2.1mm のものが正しいというコメントが書かれていた。秋月電商のアダプタは店の張り紙で内径 2.1mm と明記されていて確かにそのくらいに見えて、付属品は自信はないが 2.1mm より大きいような気はする(下の写真は付属品の方)。

    HP MicroServer Gen8 導入

    従来使用してきた hp ML115 Gen 5 もそろそろ寿命が近そうだったところで、 hp MicroServer Gen8 が安くで売られているのを見つけたので購入し、移行した。Amazon の HP ProLiant MicroServer Gen8 販売ページでは、在庫が安定しないようだが Celeron モデルが株式会社ゼット(zmart.jp)の販売で 38,458 円で入手できた。

    Microserver Gen8

    在庫及び配送は Amazon が担当し、販売元は並行輸入品を廉価販売する株式会社ゼットが担当するようだった。機械はチェコ製(本体裏面では「MADE IN CZECH REPUBLIC」「捷克制造/捷克製造」)らしい。(欧州製にも関わらず一部記載は英語/中文簡体/中文繁体で、また一部記載は欧米の言語色々だった。謎。)

    こちらの販売元で購入したものは、並行輸入品につき、電源コードが日本用ではなかった(付属品一覧を見る限り英国用と欧州用の二本?)ため、電源コードは別途自前で購入する必要があった。ディスプレイ付属のケーブルを流用できる端子だったので、とりあえず家にあった別の機器の流用で動作確認しつつ電気屋で買った。

    メインメモリ

    標準では 4GB のメモリが付属したが、2スロットで16GB(8GB×2)にまで増設できる。32GBは検索したところだと成功例がヒットせず、失敗例が多くあるようだ。ということで、HP Microserver Gen8を購入 | 三日坊主の軌跡を参考に、このページで動作実績のあるKTH-PL316E/8Gを二つ購入し、計16GBのメモリを認識させることができた。iLO と組み合わせた場合 HP 純正でないためアラートがくるとリンクした動作実績に書いてあったが、それはスルーした。

    どこを分解すればメモリを交換できるかよくわからなかったので検索したところ、MicroServer Gen8 のメモリを交換している YouTube 動画がヒットした。

    HDD

    簡単と見せかけて、最初に購入した HGST の 6TB のディスクは騒音の問題に悩まされた。x64 な Ubuntu に搭載する HDD に相性問題なんかないだろうと思いながらも一応勧められるままにツクモの交換保証に加入していたが、この保証は「思ったよりうるさい、家に置くにはうるさすぎる」みたいな理由でも期間内なら別の機種への交換が可能(価格が上がる場合は差額、下がる場合はそのまま)で、しかも回数に制限がないため、思わぬ形で救われた。結局、 Western Digital Red 6TB (WD60EFRX 、Pro ではない方)に落ち着いた(まあこれでもシーク音はまあまあ鳴るが、僕の中では許容範囲)。

    音の問題はそもそも感じ方や使い方に個人差がある上、静かな方のディスクでもうるさいと言っている人がいる一方でシーク音が大変うるさいディスクでもアイドル時に静かなためか静かと評価する人がいるのでレビューの見方が難しい。とはいえ傾向はあるので、最終的にはレビューを複数サイトでちゃんとみてればもう少しスムーズにいけたな、とは思った。

    後で気付いたことだが、Linux mdadm で高速に RAID1 array を構築する – Qiita 等で記述されているように、特にオプションを指定しないまま mdadm で RAID 1 を構築するとどういうわけか「多分二つのディスクの内容は一致すると思う」みたいな状態から開始するらしく、同期が完了するまでは両ディスクから読み込んだうえで片方のディスクで書き込みなおすためにシークが大量発生するようだ。このせいで騒音が増大していたともいえるし、このお陰で本格的にデプロイする前から騒音に気付けたともいえる。

    あと、交換後の HDD の片方が初期不良だったようで、なんだかインストーラが変な動きをするのでエラーログなどから片方のディスクがおかしいと判断、基本的に書き込みエラーだったので USB-SATA 経由で Western Digital の Data Lifeguard Diagnostic for Windows の全クラスタデータ削除に突っ込んでみたところ、数分で FAIL となった。仕方がないので秋葉原にあるツクモのサポートセンターに持ち込んで症状を伝えたらその場で交換していただけて、そちらを入れたら問題なかった。ちなみにツクモはサポートセンターと販売店が別ということを知らなかったので、ツクモの販売店に20:10ぐらいに持ち込んだら、20:00までにサポートセンターに持ち込めば対応していただける旨を教えていただけた。何をするにも下調べが大事。

    HDD が初期不良であった場合のエラーログについては、 Ubuntu のインストーラのメニュー画面の中に「syslog を HTTP で公開する」みたなオプションがあることを初めて知った。LAN 内の他の端末でブラウザで見たりダウンロードしたりできて便利だった。

    (今回やたらお世話になったので色々ツクモを称賛してるけど別にツクモの中の人とかじゃないよ)

    インストール

    Ubuntu インストールにあたってはハードウェア固有の罠はなかったはず。通常通りソフトウェア RAID を構築して OS をインストールすればよい。

    Ethernet

    まず、LAN端子は、二つとされていながらiLOなるネットワークベースの技術も搭載されていると書かれていた。公式ウェブページから想像つきにくいまま購入したが、結局は「通常のLAN端子2つ」「OSから見えず、iLOが使う端子一つ」の計3つが搭載されていた。(いずれも Broadcom チップらしい)

    Ubuntu 16.04 では eno1/eno2 として見えたが、その順序について少し厄介だった。最初1と書かれた端子にのみケーブルをつないでいたところ、ケーブルが刺さっている方が eno1 となった。ところがその後で 2 と書かれた方にもケーブルを刺して再起動したところ、これまで eno1 と書かれていたものが eno2 になり、新しく刺したほうが eno1 として認識された。謎。

    謎のランプ

    先ほどの写真にも写っているしそもそも公式の画像でもだいたい写っている通り、このサーバの下部には謎の青いランプがある。飾りかと思っていたら、添付文書では正常稼働の確認の文脈でこのランプが青く光っていることの確認が電源ランプの確認と別に書かれていた。「Health LED bar」とか名前がついており、電源ボタンについているランプとは別物らしい。

    その他

    • hp ML115 Gen5 と比べても通常時のファンの音が大変静か(ただし、比較対象の hp ML115 Gen5 はリアケースファンが 2000-5200 rpm で、僕は気にしなかったがアイドル時でもうるさいという人は多いはず)
    • 起動してから OS に制御が渡されるまではファンの回転数が制御されず普通にそこそこファン音がするのは hp ML115 Gen5 と同様(とはいえ、さすがに同じ状態の hp ML115 Gen5 よりは静か)
    • BIOS が色々検査している画面が妙にグラフィカル
    • カタログの時点でわかるが念のため追記:HDDはホットプラグ非対応。HDDを交換しようとすればまあ気付くであろう位置に注意書きがある。
    • カタログの時点でわかるが念のため追記:光学ドライブは別売りオプション。先ほどの写真の通り、なくとも見栄えが悪いというほどではない。
    • 今回は Ubuntu で使用したため実体験と全く関係のない話だが、 hp が公式にカスタムした ESXi イメージを配布している(添付文書にリンクあり)ため、どうやら ESXi からオンボード RAID が使えるらしい。ただし、HP ProLiant MicroServer Gen8を買って地雷を順番に踏んでった話 – なおたこブログにはパフォーマンスに難がある旨が記されている。
    • 日本用電源コードすら付属しない並行輸入品でも、 BIOS 画面は English/日本語 の二択だった。謎。
    • iLO は便利そうなのに試しすらしないで稼働開始してしまった。すみません。