Linux » かけまわる子犬。

AlmaLinux8 で VRF と bridge と Docker の IPv4/IPv6 デアルスタクごちゃまぜ・・。

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 ホストのネットワーク環境などを整え終わったら再度サービスに復活させるとかの対応も必要かも。

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

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

Dockerを利用してWordPressを動作させます。それもブリッジを用いて。

1月 292023

タイトルが大げさですなぁ;-)。

前回のエントリで構築した VRF が動作する AlmaLinux 8.7 ですが、その AlmaLinux8 は実は Docker ホストとしても動作しています。

これも、以前のエントリで「Docker Registry を作る。」というのを書いていますが、このホストと同一となります。

今回はこの Docker ホストに Docker コンテナを複数起動して、外部からアクセスできる環境を構築します。
Docker コンテナに対して外部からアクセスするためのポート番号は 80 番 (別に 443 でも良いのだけど、証明書関係が面倒だったので、Port:80 で許してちょんまげ;-) とします。しかし、複数の Docker コンテナが全て Port:80 番で待ち受けるためには NAT 環境では無理です。

今回は Docker ホストとコンテナ間をブリッジで接続して、Docker ホストで利用している外部接続ネットワークをコンテナでもそのまま利用するようにします。

図はこんな感じ。

VMware ESXi に二つの仮想マシンが動作しています。一個は Docker ホストで、もう一個は FreeBSD が動作して MySQL のサービスを他の仮想マシンに提供しています。

で、せっかくなので Docker コンテナがただ HTML なコンテンツを垂れ流す環境を構築してもつまらいないので WordPress が動作する環境を構築したいと思います。
ネタが二つ分の量だけど、大丈夫かなぁ・・。

と、いうことで、まずは Docker ホストの準備から。

とはいいつつ、以前、Docker Registry を作った環境をそのまま利用しています。ただ、 dnf update しているので多少バージョンが上がっているかも;-)。

$ cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.7 (Stone Smilodon)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.7 (Stone Smilodon)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"

$ rpm -qa | grep docker
docker-ce-20.10.22-3.el8.x86_64
docker-ce-rootless-extras-20.10.22-3.el8.x86_64
docker-scan-plugin-0.23.0-3.el8.x86_64
docker-ce-cli-20.10.22-3.el8.x86_64

いろいろ端折って、既に dockerd が起動しているものとして話を進めていきます。Docker のインストールと起動については他のサイトを参考にしてください。

1. Docker イメージの作成

$ docker search almaLinux
NAME                       DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
almalinux                  The official build of AlmaLinux OS.             102       [OK]       
<以下略>

$ docker pull almaLinux
Using default tag: latest
latest: Pulling from library/almalinux
<略>

$ docker image ls
REPOSITORY	TAG       IMAGE ID       CREATED        SIZE
almalinux       latest    acaca326f3b3   6 weeks ago    190MB

$ docker tag almalinux:latest almalinux8:1
$ docker image rm almalinux:latest

$ docker image ls
REPOSITORY	TAG       IMAGE ID       CREATED        SIZE
almalinux8      1         acaca326f3b3   6 weeks ago    190MB

$ docker run -it --name almalinux8 almalinux:1 /bin/bash
[root@b2db6f534790 /]#

docker search で AlmaLinux を探して、オフィシャルサイトから pull して、 almalinux8:1 としてタグ付けしました。
このあと、docker run してコンテナの中に入って dnf update して、必要な rpm をインストールして httpd や php もインストールして、もとの Docker イメージを大幅に更新して tag 付けして Docker イメージを完成させます。

この辺り割愛しますが、各自で頑張って Docker イメージを作成してください;-)。

$ docker stop almalinux8
$ docker container commit almalinux8 almalinux8_wordpress:1
$ docker rm almalinux8

apache や php をインストールした新しい almalinux8_wordpress:1 という Docker イメージができました。このイメージをベースに色々やっていきましょう。

2. Docker コンテナで利用するネットワークの準備
次にネットワークの設定を行います。今回は複数の Docker コンテナに Dokcer ホストと同じセグメントを割り当てます。
僕の環境の AlmaLinux 8.7 は VMware ESXi 上で動作しています。そして、ネットワーク構成は前回の「AlmaLinux8 の VRF。」に記載してある以下の構成をそのまま利用します。

つまり、Service-segment 側はウェブアクセスのために利用し Access-Segment は MySQL アクセスで利用します。あ。MySQL サーバは 192.168.52.204 の FreeBSD 上で動作しています。

箇条書きにするとこんな感じ。

WordPress が動作する予定の Docker コンテナは外部からのアクセスは Port:80 で eth0 側に到達するように構築します。
その Docker コンテナは外部の MySQL サーバにアクセスするために eth1 のインターフェースを利用します。
Docker コンテナは二つのインターフェースを持ち、それぞれが Docker ホストからのブリッジで動作します。
上記の図では、Server1 が Docker ホストで、Server3 が FreeBSD で MySQL サーバが動作しています。

と、いうような状況ですな。

その VMware ESXi が Docker ホストに接続するポートグループは「セキュリティ」において「無差別モード」「MACアドレレス変換」「偽装転送」の全てを『承諾』に設定します。eth0 と eth1 の二つのポートグループはブリッジインターフェースを利用するので無差別モード(俗に『プロミスキャスモード』と、言いますな)を有効にする必要があります。
VMware ESXi のネットワークの設定もちゃんとしましょう。

3. Docker network でネットワークの作成
と、いうことで Docker コンテナが利用する二つのネットワークを docker network コマンドで作成します。

$ docker network create Service-Segment \
     -o "com.docker.network.bridge.name"="br0" \
     --driver=bridge \
     --subnet 192.168.22.0/24 \
     --gateway 192.168.22.217

# brctl addif br0 eth0
# ifconfig eth0 0.0.0.0 up
# ip link set up dev br0
# route add default gw 192.168.22.1

$ docker network create Access-Segment \
     -o "com.docker.network.bridge.name"="br1" \
     --driver=bridge \
     --subnet 192.168.52.0/24 \
     --gateway 192.168.52.217

# brctl addif br1 eth1
# ifconfig eth1 0.0.0.0 up
# ip link set up dev br1

Docker ホストの eth0 の IP アドレスは 192.168.22.217 で、eth1 側は 192.168.52.217 です。

こちらも説明は箇条書きで。

eth0 の Service-Segment と eth1 の Access-Segment の Docker ネットワークを作成します。
このとき Docker ホストには docker0 というインターフェースが存在していますが、利用しないのでそのまま存在しつつ、無視して問題はありません。
NetworkManager でブリッジインターフェースの設定はしません。 /etc/sysconfig/network-scripts/ 配下に ifcfg-br0 などのファイルを置いてもなんの意味もありません。 docker network create コマンドを実行したときに付加するオプションである -o “com.docker.network.bridge.name”=”br0” があるので、既に br0 が存在しているとエラーになります。
–gateway オプションに指定する IP アドレスは Docker ホストの IP アドレスになります。
AlmaLinux 8.7 に bridge-utils の rpm はないようなのでソースからコンパイルしてインストールします。
brctl addif コマンドの実行や eth0 からアドレスを消して br0 にアドレスを付加するなどは全てコマンドで行います。

$ docker network ls
NETWORK ID     NAME              DRIVER    SCOPE
039e8158c77b   Access-Segment    bridge    local
622593f73c12   Service-Segment   bridge    local
9eb6f5610d75   bridge            bridge    local
d30c681a9f92   host              host      local
afbbadaba67f   none              null      local

無事に作成できるとこんな感じでしょうか。
ifconfig -a したときには br0 と br1 に IP アドレスが付いていて、eth0 と eth1 には IP アドレスはついていない状態が正解です。

これで Docker ホストとコンテナで同一セグメントを利用する環境が整いました。次にコンテナを run してみましょうかねぇ;-)。

4. Docker コンテナの起動
まず、いきなり WordPress を動かすコンテナを起動するのではなく Docker ネットワークに接続するために docker run してみましょう。

$ docker run -d --restart always \
 --net Service-Segment --ip 192.168.22.222 \
 -v /var/www/html/wordpress:/var/www/html \
 -v /etc/httpd/wordpress/conf.d:/etc/httpd/conf.d \
 -v /var/logs/httpd/wordpress/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name almalinux8_wordpress \
 -d almalinux8:2 /usr/sbin/httpd -DFOREGROUND

今回は箇条書きではなく、ベタガキで・・f(^^;;。
-p 0.0.0.0:80:80 というオプションは指定しません。これ付けると一個の Docker コンテナが Docker ホストの Port:80 を掴んでしまいます。
–net で接続する Docker ネットワークと –ip でDocker コンテナが使用する IP アドレスを指定します。今回は固定 IP アドレスで 192.168.22.222 を利用します。docker network のオプションではレンジとか CIDR を指定することができて DHCP みたいな利用形態もできますが、ここでは割愛します。自分で調べてください。
-v で Docker ホスト側のディレクトリをコンテナ側にマウントしています。 Docker イメージを色々なサービスで使い回すならこれらは外出しした方が良いかなぁ。と、僕は思ったので Docker イメージには組み込んでいません。自分・環境のお好みで設定してみてください;-)。
–log-driver=syslog は syslog 出力するための設定です。 /etc/rsyslog.conf には以下を記載してください。

local3.*      /var/log/docker/container.log

書いたあと rsyslogd を再起動して、ついでに mkdir /var/log/docker してください。

と、いうことで、ここまでは Docker コンテナをブリッジインターフェース経由で外部公開するための起動方法になります。
ただ、これだと MySQL サーバにアクセスできないので、起動した almalinux8_wordpress コンテナに eth1 を生やしてあげるコマンドを投入します。

$ docker network connect Access-Segment --ip 192.168.52.222 almalinux8_wordpress

$ docker exec -it almalinux8_wordpress /bin/bash
[root@64583900cb33 /]# ifconfig -a
eth0: flags=4163  mtu 1500
        inet 192.168.22.222  netmask 255.255.255.0  broadcast 192.168.22.255
        ether 02:42:c0:a8:16:de  txqueuelen 0  (Ethernet)
        RX packets 27884  bytes 2705253 (2.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 257  bytes 754283 (736.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163  mtu 1500
        inet 192.168.52.222  netmask 255.255.255.0  broadcast 192.168.52.255
        ether 02:42:c0:a8:34:de  txqueuelen 0  (Ethernet)
        RX packets 36681  bytes 4887852 (4.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 586  bytes 113982 (111.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
<以下略>
[root@64583900cb33 /]# exit

と、いう感じで docker network connect コマンドを実行したので Docker コンテナには二つのインターフェースができました。

eth0 側は Dockerホスト外部から httpd に対してアクセスができていると思います。コンテナ起動時に指定した -v /var/www/html/wordpress:/var/www/html のオプションがありますが、 Docker ホスト側の /var/www/html/wordpress/ ディレクトリ配下に WordPress のコンテンツ一式が既にインストールされていると想定しています。

裏を返すと /var/www/html/wordpress/ 配下のコンテンツを何個かの Docker コンテナに -v でマウントさせると Docker コンテナのみで冗長構成を組むことができるのですな。 eth0 側のインターフェースは docker run 時に –ip で指定する IP アドレスを変えつつ起動したあと DNS ラウンドロビンでも良いし、ロードバランサ配下のネットワークに置いても良い。今まで複数の物理や仮想マシンが担当していた部分を Docker コンテナでマカナエル。と、いうことですな。

あ。ちなみに、僕の場合は WordPress の初期環境一式は FreeBSD の ports からインストールして、 FreeBSD 上の /usr/local/www/wordpress/ ディレクトリごと tar でかためて持ってきました;-)。簡単に初期の環境が整うです。で、 IP アドレスにアクセスすると「さぁ。わーどぷれすをいんすとーるしましょうっ!!」みたいな画面がいきなりでます;-)。
あ。実はエラーになってそう簡単には出ないか・・f(^^;;。

そーそー。注意点が一個。 NetworkManager を利用しないでブリッジインターフェースの設定をしているので、サーバに再起動が入ると設定が全て飛んでしまいます。 Docker ネットワークの設定は Docker が覚えていてくれるんだけど、ブリッジを設定するためのコマンド brctl addif の設定は再起動で消えてしまうので /etc/rc.local などでリカバリーする必要があるです。

5. Docker コンテナの WordPress 対応
僕は普段 FreeBSD 上で WordPress を動作させているので Linux 上で動作させるには随分難儀なことでして・・。

まずは Docker イメージを作成するとこでイメージに対して httpd とか php をインストールします。そのあと、AlmaLinux8 の rpm の httpd は mod_mpm_event.so で動作しているようで、これをひとまず mod_mpm_prefork.so に変更します。
Docker イメージ内の /etc/httpd/conf.modules.d/00-mpm.conf の設定ファイルの中で LoadModule mpm_event_module modules/mod_mpm_event.so の行をコメントアウトし LoadModule mpm_prefork_module modules/mod_mpm_prefork.so の行を有効化します。
これの変更で一回 docker container commit する必要がありますな。

次に Linux で WordPress を動作させるためには php-fpm というのを起動する必要があるのだそうな。と、いうことで、これも Docker イメージ内でちょっと細工をします。

mkdir /run/php-fpm と chown 48:48 /run/php-fpm ですね。一応、この二つのコマンドを Docker コンテナ内で実行し、docker container commit して環境を整えます。

ふぅ。これで準備整ったかな？と、いうことで、 WordPress が動作する Docker コンテナを起動するスクリプトのまとめとしましょう。

#!/bin/sh

docker run -d --restart always \
 --net Service-Segment --ip 192.168.22.222 \
 -v /var/www/html/wordpress:/var/www/html \
 -v /etc/httpd/conf.d/wordpress:/etc/httpd/conf.d \
 -v /var/logs/httpd/wordpress/logs:/var/log/httpd \
 --log-driver=syslog --log-opt syslog-facility=local3 --log-opt tag=docker/{{.Name}}/{{.ID}} \
 --name almalinux8_wordpress \
 -d almalinux8:2 /usr/sbin/httpd -DFOREGROUND

docker network connect Access-Segment --ip 192.168.52.222 almalinux8_wordpress

export CONTAINER_ID=`docker ps -a | grep " almalinux8_wordpress" | awk '{print $1}'`
export DOCKER_PID=`docker inspect --format '{{.State.Pid}}' $CONTAINER_ID`

sudo nsenter -t $DOCKER_PID -n route delete default
sudo nsenter -t $DOCKER_PID -n route add default gw 192.168.22.217 eth0
sudo nsenter -t $DOCKER_PID -n ping -c 3 192.168.22.217

sudo nsenter -t $DOCKER_PID -m -u -i -n -p -- /usr/sbin/php-fpm --nodaemonize &

こんな感じでしょうか。

ちょっと説明を。

docker run で Service-Segment の Docker ネットワークに接続し、固定 IP アドレスを利用します。
-v で Docker ホスト側に用意したコンテンツや設定ファイルを参照するようにします。
コンテナの syslog を Docker ホスト側に出力します。 docker run の説明はここまで。
次に、起動した almalinux8_wordpress に対して、もう一個の Docker ネットワークを接続します。
その次は nsenter コマンド連発です;-)。 nsenter コマンドは docker exec しなくとも Docker ホスト側から Docker コンテナに対してコマンドを投入できるコマンドです。そのためには当該の Docker コンテナのプロセス番号が必要になるのでそれを取得します。
コンテナ内に eth0 と eth1 が存在するので default gateway を設定してあげます。一旦削除してから再度設定。みたいな感じです。
コンテナ内から Docker ホストに対して ping を打つのは、コンテナ起動ごとに MAC アドレスが書き換わるので、上位のルータに対して MAC アドレスの更新をする必要があるためです。ルータ側の MAC アドレス書き換えタイムアウトまで待っても良いですねぇ。根が短気な性分なものでして・・f(^^;;。
そして、最後の nsenter コマンドは Linux で WordPress を動かすための php のおまじない。 /usr/sbin/php-fpm を nsenter コマンドで起動してあげます。Docker コンテナ内に入って ps -ax すると httpd と php-fpm の二種類のプロセスが一個のコンテナ内で起動する状態となります。つまり、 php-fpm 専用コンテナは不要である。と、いうことです。
例えば、(本来、動かす必要はないのだけど) zabbix_agent なども nsenter で動かすことができます。コンテナ自体が固定 IP を利用しているので Zabbix Agent のポートにもアクセスできるようになります。

これで Service-Segment 側に指定した IP アドレスにウェブブラウザからアクセスすると、WordPress の初期設定画面が表示できると思います。

データベースは MySQL ですが 192.168.52.204 で動作している MySQL サーバへのアクセスは eth1 側を抜けていくので WordPress の初期設定画面で IP アドレス・ユーザ名・パスワードを設定するとアクセスできると思います。
あ。当然、 MySQL 側ではデータベースとアクセス用のアカウントを作成しておいてください。ここでは割愛しています。

さてと。ここまで来てファイアーウォールの設定が一回も登場していません。Docker にはファイアーウォールは必須なので、Docker ホスト側で systemctl start firewalld は必須です。僕の場合は /etc/firewalld/direct.xml で設定していますが、 -i で指定するインターフェース名は eth0 と br0 、 eth1 と br1 の両方を記述する必要があるので、その点は注意してください。

あとは・・。

これで多分大丈夫だと思います。

起動する Docker コンテナは、コンテンツと設定ファイル、そして、ログ出力を -v で Docker ホスト側の情報をマウントしているので docker run 時に違うディレクトリを指定し、他にネットワーク、IP アドレスの設定を変えるだけで一個の Docker イメージで複数の、用途の違う Docker コンテナを起動して同じ仕事をしてくれるようにすることも可能です。んー。 Docker らしい使い方ぁ;-)。

Docker って、基本 NAT が当たり前で、ブリッジインターフェースを利用した環境で『コンテナに対して直接アクセス』。っての、google で検索してもネタ的に今のところはあまり多くないかな。
しかし、実際にコンテナ使い込むとコンテナごとにポート番号変えるのって、なんか納得いかなくて、その先に『こんなんじゃ実際のサービスに提供できないじゃん。』と、いうところからブリッジインターフェースでコンテナに直接アクセス、ロードバランサから見ると仮想マシンもコンテナも同一の扱いのほうが楽じゃん。と、いう発想があります。そのためにはやっぱりブリッジだよねぇ。みたいな。

それにしても、実際に調べてみると Linux の bridge-utils ツール群はヘボいですな。今回、実は IPv6 のことについて全く書いてないんですよ。 bridge-utils は IPv6 側の作りが甘いっ!!
Docker ホストの br0 から出ていく TCP パケットには eth0 の MAC アドレスとか Link Local アドレスが記載されていて、受け取った PC のほうは戻りパケットを送信側 (Docker ホストのこと) の eth0 の MAC アドレスとか Link Local アドレスに投げようとするので、Dockerホスト側の br0 の情報がないために宛先がなくて、実質的に通信できない。と、いう非常にお粗末な状態です。
Docker 自体は IPv6 が使えるかもしれないけど、Linux でブリッジを利用する場合には IPv6 は利用しないほうが良いですな。パケットキャプチャしないと原因が特定できない。ハマる前に IPv6 の利用は諦めたほうが良いかと。

と、いうことで、今回、 Docker コンテナをブリッジインターフェースで、Docker ホストと同一のネットワークで動作させる。と、いうことにチャレンジしてました。 VMware ESXi 上で複数の仮想マシンを起動するがごとく、Docker ホスト上で Docker コンテナをドドドと立ち上げることが可能になったので、サーバ資源がますますギューギュー使える状態になったでしょうかねぇ;-)。

このあと、docker swarm がまだ待っております。が、オーバーレイネットワークがちゃんと動いてくれてないのよ。とほほ・・。orz

AlmaLinux8 の VRF。

1月 142023

このブログでは何回か VRF について書きました。 FreeBSD の VRF、ubuntu の VRF など。 FreeBSD のポリシールーティングのネタも書いたこともありました。

そのとき CentOS7 はカーネルがまだ VRF に対応していなくて、CentOS8 まで VRF は実質利用できない状態だったのだけど、今の時代、AlmaLinux8 を利用すればカーネル的に VRF が利用できるので、試してみました。

ubuntu のネットワーク設定より Red Hat Linux 系のネットワーク設定のほうが楽と、いうか、個人的にも直感的に設定できるような状態ですしね(^^;;。今回は由緒正しく /etc/sysconfig/network-scripts/ 配下のファイルを用意して VRF の設定をしてみたいと思います。

と、いうことでまずは構成図などを。

基本的に FreeBSD の VRF も同じ構成で組んでいます。セグメントは全部で 3 個。

Service-Segment: 外部からのアクセス用
Access-Segment: MySQL とか SNMP とかバックヤード系
mgmt: ssh でサーバにログインする用

今回のルーティングテーブルは合計二つ。Service-Segment と Access-Segment で一個のルーティングテーブル。 mgmt が VRF で設定するもう一個のルーティングテーブルになります。

FreeBSD で VRF するときに痛感したのですが、自分から出すパケットは default のルーティングテーブルからしか出ていきません。VRF で追加したルーティングテーブルの mgmt セグメントの 192.168.1.0/24 に ssh しようとしても default のルーティングテーブルから出ていきます。

例えば 192.168.52.201 で動作している MySQL にアクセスしようとした場合、default のルーティングテーブルから出ていくのですが Access-Segment で利用しているセグメントがローカルネットワークになっているのでそこから出ていきます。
MySQL サーバが 172.16.52.201 にあった場合、 default gateway の設定のある Service-Segment から出ていきますが、 MySQL のアクセスは Access-Segment から出ていきたいので route add -net 172.17.52.0/24 gw 192.168.52.1 とか Access-Segment にルーティング設定をしてあげる必要があります。

と、いうことで VRF を設定して本当に幸せになるのかよくわかりませんが、とりあえず設定して行ってみましょう。

上記の構成図に合わせて /etc/sysconfig/network-scripts/ にファイルを用意していきます。

ifcfg-eth0
ifcfg-eth1
ifcfg-eth2
ifcfg-vrf.eth2
route-vrf.eth2
route6-vrf.eth2

実際に中を見てみましょう。

Service-Segment: ifcfg-eth0

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2001:470:fe36:face::217:1
IPV6_DEFAULTGW=2001:470:fe36:face::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.22.217
PREFIX=24
GATEWAY=192.168.22.1

Service-Segmet に接続する eth0 には default gateway を設定しています。

Access-Segment: ifcfg-eth1

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2001:470:fe36:cafe::217:1
#IPV6_DEFAULTGW=2001:470:fe36:cafe::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth1
DEVICE=eth1
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.52.217
PREFIX=24
#GATEWAY=192.168.52.1

こちらは内部のアクセス用ネットワークなので、default gateway は設定していません。実際には route add -net でネットワークごとにルーティング情報を追加するんだろうなぁ。と、いう気配です。

mgmt: ifcfg-eth2

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2405:6580:aa40::217:1
IPV6_DEFAULTGW=2405:6580:aa40::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth2
DEVICE=eth2
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.1.217
PREFIX=24
GATEWAY=192.168.1.1

マネージメント用ネットワークで外部から ssh でログインするときに利用します。これが VRF を利用するインターフェースなので default gateway が設定してあります。でもって次のファイルも必要です。

mgmt-VRF: ifcfg-vrf.eth2

TYPE=Ethernet
DEFROUTE=yes
BOOTPROTO=none
IPADDR=192.168.1.217
PREFIX=24
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=2405:6580:aa40::217:1
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=vrf.eth2
DEVICE=eth2
ONBOOT=yes
VRF=mgmt0

NAME= と VRF= で VRF で動作の設定です。ifconfig -a したときに mgmt0 というインターフェースが生えてきます。

mgmt-route-IPv4: route-vrf.eth2

ADDRESS=0.0.0.0
NETMASK=0.0.0.0
GATEWAY0=192.168.1.1

VRF 側の IPv4 のルーティングテーブルの設定です。

mgmt-route-IPv6: route6-vrf.eth2

::/0 via 2405:6580:aa40::1

こちらが VRF 側の IPv6 のルーティングの設定。

で、これで準備ができたので一応再起動してみます。がっ!!

これがまた正しく動作しないのですよなぁ・・。 orz。

と、いうことで、追加で /etc/rc.local に設定を記載して、ちゃんど動作するようにコマンドを羅列します。 orz

ip link add dev mgmt0 type vrf table 10
ip link set dev mgmt0 up
ip link set dev eth2 master mgmt0
ip addr add dev eth2 192.168.1.217/24
ip link set dev eth2 up
ip route add default via 192.168.1.1 table 10
ip route add ::/0 via 2405:6580:aa40::1 table 10

route delete default
route delete default
route add default gw 192.168.22.1

ip route del ::/0 via 2405:6580:aa40::1
ip route del ::/0 via 2001:470:fe36:face::1
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

最後の sysctl コマンドは /etc/sysctl.conf に記載しても良いですね。
問題はその上です。

上から順に、

インターフェース mgmt0 を vrf として作成し table 10 とします
インターフェース eth2 と mgmt0 をくっつけます
table 10 (VRF 側) に default route を設定します
default のルーティングテーブルが壊れているようなので default gateway を二回削除してからつけ直します (ほんとうにこれしないとダメだった・・orz)

ルーティングの情報は IPv4 と IPv6 両方で実施します。これで大丈夫みたい。

確認方法は以下です。

# ip route show
default via 192.168.22.1 dev eth0 
192.168.1.1 dev eth2 proto static scope link metric 102 
192.168.22.0/24 dev eth0 proto kernel scope link src 192.168.22.217 
192.168.52.0/24 dev eth1 proto kernel scope link src 192.168.52.217 

# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2405:6580:aa40::/64 dev eth2 proto kernel metric 102 pref medium
2001:470:fe36:face::/64 dev eth0 proto kernel metric 100 pref medium
2001:470:fe36:cafe::/64 dev eth1 proto kernel metric 101 pref medium

# ip route show table 10
default via 192.168.1.1 dev eth2 
broadcast 192.168.1.0 dev eth2 proto kernel scope link src 192.168.1.217 
local 192.168.1.217 dev eth2 proto kernel scope host src 192.168.1.217 
broadcast 192.168.1.255 dev eth2 proto kernel scope link src 192.168.1.217 

# ip -6 route show table 10
local 2405:6580:aa40::217:1 dev eth2 proto kernel metric 0 pref medium
local fe80::751c:3cc8:a2c0:2fcb dev eth2 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth2 proto kernel metric 256 pref medium
default via 2405:6580:aa40::1 dev eth2 metric 1024 pref medium

# ip -d link show type vrf
6: mgmt0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 12:c4:f9:dc:1f:bf brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 10 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

なんか良さげな感じがしています。

192.168.22.1 から eth2 のアドレスに対してアクセスした場合、戻りパケットはちゃんと eth2 から出ていきます。 19.268.1.50 から eth0 のアドレスに対してアクセスした場合、ちゃんと eth0 から戻っていきます。ある意味 VRF が機能している。と、いう感じです。やりたかったことはこれですね。

ただ、自分から出ていくパケットについてが問題です。default のルーティングテーブルから出ていくのが基本で、別のルーティングテーブルを利用したい場合は ping -I eth2 192.168.1.40 みたいにインターフェースを指定する必要があります。明示的にコマンドを打つなら良いですが、例えば php から MySQL にアクセスするために VRF 側のルーティングテーブルを利用して外に出ていきたい。などというのはほぼ不可能です。

使い方が非常に限られる VRF ですが、機能的には一応、動作する。と、いうことですなぁ。

さてと。今回構築したこの AlmaLinux release 8.7 の環境ですが、もうしばらく利用したいと思います。次のエントリは今回作成した環境を利用します。が、直接的・動作的には全く関係ないですが、好ご期待;-)。

Docker Registry を作る。

1月 082022

ウェブで色々調べてみると、みんな中途半端なネタしかなくて、ウェブ UI まで含めた Docker Registry を作るのにずいぶんと苦労しました。

今回はそれをきれいさっぱりとまとめてみたいと思います。

僕はそれほど Docker に詳しくはないけど、今回のターゲットの読者 (って、いるのかな？;-) は、普段から Docker コンテナを利用していて、 Docker image を自分が作成した Docker Registry で管理したい人向けです。

では始めます。今回のプラットホームは AlmaLinux 8.5 です。 docker は以下です。

$ cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.5 (Arctic Sphynx)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.5 (Arctic Sphynx)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.5"

$ rpm -qa | grep dock
docker-scan-plugin-0.12.0-3.el8.x86_64
docker-ce-rootless-extras-20.10.12-3.el8.x86_64
docker-ce-cli-20.10.12-3.el8.x86_64
docker-ce-20.10.12-3.el8.x86_64
$

まず、Docker image を取ってきます。まぁ、ほぼほぼ標準のイメージです。
あ、 /etc/group の docker グループに自分のアカウントを追加して上げましょう。一般ユーザ権限で docker コマンドが利用可能になります。

$ docker pull registry:2
<略>
$ docker pull konradkleine/docker-registry-frontend:v2
<略>
$ docker pull ekazakov/docker-registry-frontend
<略>

一番最初の docker pull は Registry サーバ本体です。
二番目の docker pull はウェブで検索すると良く出てくる Registry のウェブ UI です。
三番目の docker pull は registry:2 のウェブ UI ですが、なんと、削除ボタンが付いていて不要な Docker image を削除することができます(が、僕はまだ削除したことないですf(^^;;)。

これで Docker image が揃ったので docker run してみます。と、言いつつまだまだ準備ができていません。

と、いうか、最近の docker pull/push は SSL に対応しているので、プライベートで立てる Registry サーパ (『リポジトリサーバ』とも言う) も SSL でアクセスできるようにして上げる必要があります。
つまり、 Docker image の registry:2 を起動するためには SSL 証明書が必要なんですな。 Let’s Encrypt などでまずは証明書を準備してください。

ここ、大切な部分です。この工程をはしょって『プライベートレジストリを構築するーっ!!』って、サイトが多くてイヤになる・・。非常にノイジー。古いコンテンツは消して欲しい。と、思う部分ですな。
とはいいつつ、僕のサイトにも古い記事が今でも残っているけど・・f(^^;;。

と、いうことで registry:2 を run するための証明書の準備です。

# mkdir /opt/docker/repository/certs/
# cd /usr/local/etc/letsencrypt/live/running-dog.net/
# cat cert.pem > /opt/docker/repository/certs/domain.crt
# cat chain.pem > /opt/docker/repository/certs/ca.crt
# cat privkey.pem > /opt/docker/repository/certs/domain.key

Let’s Encrypt で取得した証明書を /opt/docker/repository/certs/ と、いうディレクトリにそれぞれの名前で格納しました。自分のドメイン名に照らし合わせてください。
あーぅー。Linux の場合、 Let’s Encrypt のベースディレクトリはどこになるのだろう? 上記の例では FreeBSD 的に /usr/local/etc/letsencrypt/ になっていますな。自分の環境に合わせてくださいf(^^;;。

そして、追加でもう少し。

# cd /usr/local/etc/letsencrypt/live/running-dog.net/
# cat cert.pem > /etc/pki/tls/certs/running-dog.net.crt
# update-ca-trust
# systemctl restart docker

証明書を準備したら上記コマンドを実行してください。証明書を更新したときも実行してください。
SSL 証明書を /etc/pki/tls/certs/ に設置したあと update-ca-trust コマンドを叩いて dockerd を再起動しなます。
これをやらないと docker pull や push がエラーになるかもしれません。

さてと。これで SSL 証明書関連の準備が完了です。起動するときは以下のような感じ。

# mkdir /opt/docker/repository/data/
$ docker run -d -p 0.0.0.0:5000:5000 --restart=always \
 -v /opt/docker/repository/data:/var/lib/registry \
 -v /opt/docker/repository/certs:/certs \
 -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
 -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
 --name registry-server \
 registry:2

-v でレジストリのデータを管理するディレクトリと、証明書が格納されているディレクトリをコンテナから参照できるようにしてあげます。

IP アドレスは 0.0.0.0 を指定してあげまていますが、Docker ホスト側の IP アドレスの Port:5000 に (telnet で) アクセスすると開いているかと思います。
Registry サーバは SSL でアクセスするので、 Docker ホストの IP アドレスに FQDN を指定してあけます。今回は registry.running-dog.net にしました。view internal な DNS ゾーンファイルに設定するか /etc/hosts に指定してください。

curl を利用して以下の要領でアクセスすれば良いです。

$ curl -k https://registry.running-dog.net:5000/v2/_catalog
$ curl -k https://registry.running-dog.net:5000/v2/centos/tags/list

上の curl は docker push されている、つまり、プライベートレジストリに登録されている Docker image の一覧が表示されます。
下の curl は、仮にプライベートレジストリに centos という Docker image が push されていたとすると登録してあるタグ番号一覧を返してくれます。

ここまでは Port:5000 でアクセスする Registry サーバ側の設定と起動方法になります。ウェブ UI がなくても上記 curl でイメージとタグ番号の確認はできます。

では、ここからはいよいよウェブ UI 側のコンテナの起動です。

インターネット上で検索してみると、docker run してサクっと Registry サーバに接続してその情報を表示してくれる。みたいなサイトがゴマンとありますが、あれ、みんなウソです。全然表示してくれない。なんでやねんっ!?

僕もずいぶんと悩みました。どんなにやってもウェブ UI のコンテナから Registry サーバにアクセスできないっ!! ずっと悩んでいたのですが、ようやっと、問題解決です。

先にタネ明かししますが Registry サーバへは SSL で Port:5000 にアクセスします。 URL 的には https://registry.running-dog.net:5000/ になりますね。
ウェブ UI 側も registry.running-dog.net の Port:5000 にアクセスするように docker run 時に指定するのですが、これは http で registry.running-dog.net の Port:5000 にアクセスしているんですね。プロトコルが https で Port:5000 にアクセスできていないので、ウェブ UI 上に Registry サーバの情報を表示できなかったんですね。

ここの情報について書いているサイト、ほぼ皆無です。

ウェブ UI 側のコンテナは以下のように docker run してみましょう。

$ docker run -d -p 0.0.0.0:8080:80 \
 --net reg-Segment \
 -e ENV_DOCKER_REGISTRY_HOST=registry.running-dog.net \
 -e ENV_DOCKER_REGISTRY_PORT=5000 \
 -e ENV_DOCKER_REGISTRY_USE_SSL=1 \
 -e DOCKER_REGISTRY_SCHEME \
 --name registry-web \
 ekazakov/docker-registry-frontend:latest

今回は削除ボタンのある ekazakov/docker-registry-frontend:latest の Docker image を利用してみました。
-e で環境変数を指定します。よくあるのは ENV_DOCKER_REGISTRY_HOST と ENV_DOCKER_REGISTRY_PORT です。この二つだけの指定ではウェブ UI は http で ENV_DOCKER_REGISTRY_HOST に指定したホストの ENV_DOCKER_REGISTRY_PORT に指定したポート番号にアクセスします。

この瞬間、まさに『ダメだ。こりゃ。』な状態です。

https でアクセスするためには更に追加で DOCKER_REGISTRY_SCHEME と ENV_DOCKER_REGISTRY_USE_SSL=1 を指定してあげます。これで Registry サーバに https でアクセスしに行って、ウェブ UI 上に登録されている情報を表示してくれるようになります。

いやぁ・・。疲れた。あとはひたすらウェブ UI を使い込んでいくことなるかと思います。ふぅ・・。

と、いうことで、 https でアクセスする Registry サーバと Registry サーバから https で情報を取りに行ってウェブ UI に表示してくれる Registry サーバのウェブ UI がセットで起動できました。
あ、ウェブ UI 側は http://registry.running-dog.net:8080/ でアクセスできます。こちらのプロトコルは http です;-)。

では、どうして今回、ウェブ UI は『どうして表示できないのだ?!』と、悩んでいたのが解決できたか？についてですが『そもそも https でアクセス行ってないからじゃね？』と、思ったから。が、ベースとなっていますが Docker image である registry:2 も ekazakov/docker-registry-frontend:latest も docker exec で中に入ることができないんですねぇ・・。コンテナに与える環境変数は他にはないのか？確認する手段が無かった。と、いうのが大きな点ではありますが、ところがそうではないっ!!

$ docker ps -a
CONTAINER ID   IMAGE                                      COMMAND                  CREATED        STATUS        PORTS                                            NAMES
2f3a138f1b8e   ekazakov/docker-registry-frontend:latest   "/bin/sh -c $START_S…"   23 hours ago   Up 23 hours   443/tcp, 0.0.0.0:8080->80/tcp, :::8080->80/tcp   registry-web
d1e9dbf6e9a5   registry:2                                 "/entrypoint.sh /etc…"   24 hours ago   Up 24 hours   0.0.0.0:5000->5000/tcp                           registry-server
$ docker exec -it d1e9dbf6e9a5 /bin/bash
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown
$ docker exec -it d1e9dbf6e9a5 /bin/sh
/ # ls -l /bin/busybox 
-rwxr-xr-x    1 root     root        841288 Nov 12 11:37 /bin/busybox
/ # exit
$

docker ps してから docker exec -it で registry:2 に /bin/bash で入ろうしたけど、/bin/bash がないので、試しに /bin/sh にしてみたらあらは入れた。ついでに registry:2 は busybox で動作しているのねぇ。 i386 i686 系の busybox って、初めて見た。みたいな。

konradkleine/docker-registry-frontend:v2 も /bin/bash はないけど /bin/sh で中に入れます。
ekazakov/docker-registry-frontend:latest は /bin/bash で中に入れました。

$ docker exec -it 2f3a138f1b8e /bin/bash
root@2f3a138f1b8e:/# env
HOSTNAME=2f3a138f1b8e
APACHE_RUN_USER=www-data
TERM=xterm
ENV_DOCKER_REGISTRY_PORT=5000
APACHE_LOG_DIR=/var/log/apache2
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
APACHE_RUN_GROUP=www-data
ENV_DOCKER_REGISTRY_USE_SSL=1
SOURCE_DIR=/tmp/source
WWW_DIR=/var/www/html
SHLVL=1
HOME=/root
START_SCRIPT=/root/start-apache.sh
ENV_DOCKER_REGISTRY_HOST=registry.running-dog.net
_=/usr/bin/env
root@2f3a138f1b8e:/# cat /root/start-apache.sh
<略>
root@2f3a138f1b8e:/# exit
$

こんな感じです。 ekazakov/docker-registry-frontend:latest のウェブ UI は apache で起動しているみたいです。 /root/start-apache.sh の中に docker run 時に指定した環境変数を取り込んでホスト名・ポート番号・プロトコルが設定されます。
この /root/start-apache.sh のファイルの中をじっくりと確認することによって、そこから想像する分には『https://でアクセスするようにしないとアカンのねえ・・。』と、思いつくのでありました。
あとは環境変数を見つけてそれをコンテナに渡してあげれば・・。ふぅ。なんとか動き出した。と、いう状態なのでありました。それが、 DOCKER_REGISTRY_SCHEME と ENV_DOCKER_REGISTRY_USE_SSL なのでありますね。

それにしても、有名どころの git で拾ってきた Docker image も docker exec で /bin/bash で中に入れないとき /bin/sh とかだと入れるとか、他にもっと実は色々な入り方 (裏技) があるのかもー。と、関心させられた事象だったのであります。

そして、Port:5000 番でアクセスする Registry サーバと、Port:8080 でアクセスするウェブ UI 。ふぅ。なんとか構築することができたのであります。

今の docker pull/push は SSL が基本です。http でアクセスできていた古いインターネット上の記事には惑わされないようにしてください;-P。

ubuntu で VRF 使ってみました。

7月 272017

ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほうには setfib コマンドでルーティングテーブルを操作して正しいルーティングができるのか試しているのですが、結局はダメだったのであります。

Linux 方面では ip route+ip rule でのポリシールーティングの運用となりますが、カーネルのバージョン 4.4 から VRF が利用できる。というので setfib と比較してどれくらい効果的に機能するのか試してみました。
Linux カーネルが 4.4 以上なディストリビューションには何があるのか調べてみると ubuntu-17.04 が対応しているようなので ISO イメージをダウンロードしてインストールし、実際に設定までしてみます。

僕自身 ubuntu はあまり使ったことが無いディストリビューションで Raspberry Pi の Volumio に続き二個目のインストール環境です。仕事でもデスクトップでも使ったことがありません;-)。

それにしても ubuntu のネットワーク設定である /etc/network/interfaces の記述方法が相変わらず解らないので、いつものように /etc/rc.local でやってしまえ。などと思っても ubuntu にはこのファイルが無いし、起動時に利用できないのですねぇ。

以下の URL を参照させて頂き /etc/rc.local を動くようにしました;-)。

http://qiita.com/msrks/items/5201ae15d0e1f8de5946

簡単に書いておくと

o. /etc/systemd/system/rc-local.service を作成

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
# disable timeout logic
TimeoutSec=0
#StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

o. enable する

systemctl enable rc-local.service

これで /etc/network/interfaces と /etc/rc.local にコマンドを書いて、起動時に実行されるようになりました。

と、いうことで、以降は VRF を利用するネットワークの設定を行います。

まず、ネットワーク構成ですが、この前のエントリ「FreeBSD でポリシールーティング。」で書いた CentOS 6.9 を ubuntu-17.04 にリプレイスして ip route+ip rule をやめて VRF を利用してみます。

Server1 が Linux (CentOS 6.9) だったので、これを設定します。以下はネットワークの情報です。

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

これを VRF を利用するように設定します。が、その前に注意点を。

NIC が二個あるのでそれぞれの NIC を VRF にしてルーティングテーブルを二つ別々に持たせよう。などと思ってはいけません。
NIC が二個の場合、一個は default のルーティングテーブル(ip [-6] route list で表示されるルーティングテーブル)を参照するようにして、もう一個の NIC は別のルーティングテーブルを持ち、かつ参照する構成が良いです。ここ、ハマリ道というか思い違いの点ですね。
この点については下のほうに詳しく書きます。

では、設定を上から順に見ていきます。

0). /etc/network/interfaces にネットワークの設定のみ書く
lo の他にインターフェース二つ分を書き gateway の設定は書かない

auto ens160
iface ens160 inet static
address 192.168.22.10
netmask 255.255.255.0
iface ens160 inet6 static
address 2001:470:fe36:beef::2:1
netmask 64

auto ens32
iface ens32 inet static
address 192.168.1.10
netmask 255.255.255.0
iface ens32 inet6 static
address 3ffe:6580:aa40::2:1
netmask 64

多分、/etc/resolv.conf が作られないので、以下のコマンドを /etc/rc.local に書いておくと良いかもしれんです。

cp -pr /etc/resolv.conf.SV /etc/resolv.conf

/etc/resolv.conf.SV は好きに書いてください;-)。
しかし、ディストリビューションの正しい設定方法を無視しているなぁ;-P。

1). IP アドレスの付加
僕の場合、/etc/network/interfaces に書いた IPv6 アドレスが自動的に付加されなかったので /etc/rc.local に書きました。
以降の設定は全て /etc/rc.local に書くと楽ちんです;-)。

ip addr add dev ens160 2001:470:fe36:beef::2:1/64
ip addr add dev ens32 3ffe:6580:aa40::2:1/64

2).ルーティング情報の付加
今回は Server-Zone 側を default のルーティングテーブルとして利用します。

route add default gw 192.168.22.1
route add -A inet6 default gw 2001:470:fe36:beef::1

3). VRF の設定
いよいよ、VRF の設定です。VRF は LAN-Zone 側に設定します。
ip [-6] route list コマンドで表示される default gateway は上でコマンドを打っています。グローバル側の設定ですね。
VRF はマネージメントポート側で利用する。と、いう意味合いを込めて Cisco 風に mgmt という名にします;-)。

ip link add dev mgmt type vrf table 10
ip link set dev mgmt up

type は vrf で table 番号は 10 を利用しました。複数個の VRF を生成する場合はこの番号を増やしていけば良いです。

4). VRF と NIC の結びつけ
作成した VRF インターフェースと NIC を結びつけます。つまりは、マネージメントポート用の VRF は mgmt として LAN-Zone の NIC と結びつける。と、いうことですね。

ip link set dev ens32  master mgmt up

リモートから ssh で作業していて dev で指定する NIC からアクセスしていた場合、このコマンドを投入した段階でネットワークが切れます。なので反対側の NIC からアクセスして作業するか、コンソールからコマンドを叩く必要があります。
起動時の /etc/rc.local 読み込み時には問題はないんですけどね。

5). VRF に default gateway を設定
Server-Zone は default のルーティングテーブルを参照しますが、 LAN-Zone は個別の VRF のルーティングテーブルを参照します。なので別途 default gateway を設定します。 VRF の table 10 に対して route add します。

ip route add default via 192.168.1.1 table 10
ip route add default via 3ffe:6580:aa40::ffff:1 table 10

6). 外部からのアクセスを可能にする
最後に sysctl で以下の MIB 値を変更し、外部から VRF 側のネットワークアクセスを可能にします。これをしないと ssh などで接続することができません。

sysctl -w net.ipv4.tcp_l3mdev_accept=1

以上で VRF の設定は完了です。

確認方法は以下になります。

ip route list もしくは ip -6 route list
default のルーティングテーブルを確認すときに利用
ip route list vrf mgmt もしくは ip -6 route list vrf mgmt
設定した VRF の mgmt のルーティングテーブルを確認

その他、インターフェースの確認として ip link や ip addr を利用します。

さて。最初のほうで『二個の NIC に VRF を二個用意してはいけません。』と書いていますが、例えば二個の NIC それぞれで VRF を利用した場合 /etc/resolv.conf を参照しないなど、問題点も多いです。
そりゃそうでしょうなぁ。どっちの NIC から出ていくかわからないですし、リゾルバは正しく動作してくれないんでしょうな。

例えば NIC が ens160 と ens32 の二つがあった場合以下のコマンドを打ったとします。

ip link set dev ens160 master vrf0
ip link set dev ens32  master vrf1

この場合、二つの NIC でそれぞれ個別のルーティングテーブルを持つことになるんですが、

ping -I vrf0 IP アドレスもしくは ping -I vrf1 IP アドレス

では到達性があります。しかし、以下のように pingすると到達性がありません。

ping -I vrf1 FQDN

ルーティングテーブルが VRF のみになると DNS を引きに行ってくれないんですね。なので、 NIC が二個の場合は一個の VRF を設定するのみで、もう一個の NIC は default な ip [-6] route list で表示してくれる経路が必要になります。

二個の NIC で二個の VRF を設定すると netstat -nr や ip route list では何も表示してくれなくなります。

ループバックに IP アドレスとか記載できるのかな？ lo:1 とか書けるのかな？そこまで試していませんが。

さてと。ここまで来て VPF の環境設定が終わりましたが、実際に利用してみるとやはり中々楽しいですね。
Cisco ルータの場合、 VRF は interface mgmt で動作することが多々あるんですが、今回は L3 ルータを作る。と、いう目的ではなく、サーバのポリシールーティングのかわりに VRF を利用してみた。と、いう感じですね。

ip [-6] route list で表示されるルーティングテーブルは、サービス側で利用し、マネジメントポート (今回はそれを LAN-Zone と呼んでます) で VRF を利用し、サービスセグメントのルーティング情報とは混在させないで通信を行う。こんな時に必要な機能だと思われます。

僕はこのあと VRF を利用しつつ、ウェブサーバを起動して CentOS 6.9 を引退させようと考えています;-)。

FreeBSD の setfib もここまで動いてくれると嬉しいのですが、そこまで到達していないのと、そもそも setfib は IPv6 が動かないので、今の所、僕の環境ではまるで使い道が無い・・。orz

FreeBSD でポリシールーティング。

7月 182017

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの？って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら？その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな？

設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう？ fib はインターフェースとリンクしなくて良いのかな？不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら？

ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

tcsh で systemctl や service をタブキーで補完。

7月 132017

systemctl ってのは Linux の新しいシステムの systemd 由来のコマンドですね(この辺りの言い回し、正しくないかも;-)。
つい最近になって CentOS7 を利用し始めたので /etc/init.d/hoge restart とかできなくなって驚いていたんですけども。

じゃぁ、/etc/init.d/ の下にあったのはどこに行ったのだ？と思い調べてみると /usr/lib/systemd/system/*.service というのがそのようですね。このファイルを利用して systemctl が start/stop をやってくれる。と、いうことのようです。

Linux のシェルは基本的に bash なので以下のファイルをダウンロードしてきて /etc/bash_completion.d/ の中に入れてあげると TAB キーで補完してくれるので幸せになれるようです。 bash 用の systemctl 補完用スクリプトですね。

https://raw.githubusercontent.com/terralinux/systemd/master/src/systemctl-bash-completion.sh

では、普段から tcsh を利用している人 (それはつまりは Linux が流行る前から UNIX をいじっていた人。と、いうことになるのかや？;-) や Linux でも tcsh をメインで利用している人はどうしたらえーねん？て、ことになるのですが、せっかくなので ~/.tcshrc に以下の設定を書いてみましょう。 (ウェブ上では多分切れているね・・orz。フル HD の全画面で表示してぇ・・。)

complete systemctl 'p/1/(start stop restart status reload enable disable kill ..etc..)/' 'n@*@`/bin/ls /usr/lib/systemd/system | grep service | sed -e "/:/d"`@'

tcsh には complete というコマンド(？)があるので、それで TAB の補完の設定ができます。

上記を ~/.tcshrc に書いて systemctl と打ったあと TAB を打つとまず start/stop などの文字列が表示され、その後 *.service をドドドと表示してくれることでしょう。途中の sshd.s で TAB キーを押しても補完してくれます。

これで tcsh をメインのシェルとして利用している人は幸せになれるのではないかと思われます;-)。

ところで、 FreeBSD の service も似たように TAB で表示したい。と、いう場合はどうするのか？以下の設定をやはり ~/.tcshrc もしくは /root/.cshrc に書くと幸せになれます。

complete service 'n@*@`/bin/ls /etc/rc.d /usr/local/etc/rc.d | sed -e "/:/d"`@' 'p/2/(start stop restart onestart onestop onerestart)/'

FreeBSD の起動スクリプトは /etc/rc.d/ や /usr/local/etc/rc.d/ の中に入っているのでその中をごっそりと ls している。と、いうことになります。

bash の場合は専用のスクリプトを用意したりしますが tcsh の場合は強引に /bin/ls で実装している。と、いうことですなぁ。

tcsh が好きで好きで手放せない。もしくは bash なんて使ってらんねーぜ。けっ。はたまた zsh なんて遅くて使い物にならん。と、いう方は今後も多分ずっと tcsh を使い続けるかと思いますが、その場合 systemctl や service で TAB キーを使いたい方は是非お試しください;-)。
また、他のコマンドでも TAB を利用して補完したい場合には complete コマンド(？)で定義することができます。

2017/07/27 加筆
もう 20 年くらい tcsh 使っているけど、 tcsh を利用するときに complete な一覧が書かれているファイルがあるのね。知らなんだぁ。

o. FreeBSD の場合
/usr/share/examples/tcsh/complete.tcsh
/usr/src/contrib/tcsh/complete.tcsh

o. ubuntu の場合
/etc/complete.tcsh

これを ~/.tcshrc の中で source /usr/share/examples/tcsh/complete.tcsh とかすると色々なコマンドで TAB で補完してくれるので幸せになれます。
僕のは場合は mv cp ln など、二個目のパラメータを TAB キーで抽出できなかったので、一部変更して $HOME に置きました。

ubuntu の人が作ってくれたファイルのようです。感謝。 m(_ _)m。
加筆ここまで

Raspberry Pi 二つ購入。

5月 022017

ゴールデンウィークのお楽しみ用に Raspberry Pi を二個購入しました。一個は Raspberry Pi 3 Model B で、もう一個は Raspberry Pi ZERO です。二個合わせて 5,000yenちょっと出た程度。

正規代理店の株式会社ケイエスワイで購入しました。
5,000yen 以上だと送料無料だというので二個買ってしまった。と、いう話なんですけども。

これで Raspberry Pi は 2,3,ZERO と三つになりました。

左から RPi2 -> RPi3 (ハイレゾ音源ボード装着) -> RPi ZERO と並んでいます;-)。

Raspberry Pi 3 Model B は volumio2 で利用予定です。オンボードの Wifi チップは FreeBSD では利用できませんが、Linux では利用できるので。ちなみに volumio2 でも利用可能です。おかげで USB な Wi-Fi が余ったので他の RPi に回せます。

今まで利用していた Raspberry Pi 2 Model B は自宅で FreeBSD マシンとして動作させるべく FreeBSD/arm 11.0-RELEASE をインストールしました。以前このブログでもエントリを書いているのでサクっと動作します;-)。

ports のコンパイル環境も母艦側を FreeBSD/amd64 10.1-R から 11.1-R にバージョンアップして、 qemu 側も新たに FreeBSD/arm 11.0-R 用のを作成したのでコツコツと最新の ports-CURRENT を更新して行きたいと思います。

最近の FreeBSD/arm 11.0-R は pkg install が利用できるのでずいぶんと楽にはなりましたね。ただ、ちょっと古い。そんな場合は以下の URL を覗いてみてください;-)。

http://distfiles.icmpv6.org/freebsd:11:armv6:32/latest/All/

と、いうことで、今回のネタは Raspberry Pi ZERO についてです。

Raspberry Pi ZERO は値段が 600yen で非常に手頃な値段です。外部接続には電源供給用の MicroUSB と、USB 機器接続用の MicroUSB のポートがあります。ディスプレーは MiniHDMI ポート、これはちょっと痛かった・・。 MicroHDMI ポートだと Diginnos DG-D08IWBと互換があるので嬉しかったのですが・・。

今回は HDMI への出力を諦め、シリアルコンソールを利用しました。

そもそも RPi ZERO には GPIO ピンがなくて穴が空いているだけです。なのでシリアルコンソール用のピンをハンダで付けてあげる必要があります。

まず、ピンの手配ですが、昔利用していた PC のサウンドカードから 3 本ほど調達しました。下の写真のような感じ。

うまく固定もしたのでこれを穴の中に通します。ハンダ付けはしません。ちょっとななめにすると接触するのでハンダ付けしなくとも利用できました。

OS は FreeBSD/arm 11.0-RELEASE をチョイス。イメージは以下を利用しました。

FreeBSD-11.0-RELEASE-arm-armv6-RPI-B.img.xz

ちなみに RPi2 では以下のイメージを利用します。

FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz

RPI2 のイメージも RPi ZERO で試しまたがブートしませんでした。

RPI-B なイメージを MicroSD に dd し SD カードを差し込んで電源オンっ!! 無事に起動したのであります。

起動時の情報は以下になります。

dmesg
sysctl -a

僕は MIcroUSB -> USB 変換ケーブルで USB Wi-Fi や USB NIC を付けてネットワークリーチャブルにしたあとリモートからの SSH と NFS で作業を実施。環境構築が完了したのでありました。

そーそー。 RPi ZERO の ports/packages は FreeBSD/arm 11.0-RELEASE RPI2 の環境で作成したものがそのまま動作しました。 RPi2 と ZERO ではブート用イメージファイルが違うので ports/packages も違うのかな？などと思ったのですが、どちらも 32bit なバイナリで、同一のものが動作します。幸せなことです;-)。

と、いうことで特に問題もなく RPi ZERO は FreeBSD/arm が動作しました。

値段が 600yen で、約 5cm ほどの最小の FreeBSD 環境が整った。と、いうことですね。ゴールデンウィークの暇つぶしにピッタリなおもちゃです;-)。

Volumio でシリアルコンソールを使うよ。

4月 192016

Raspberry Pi 2 に Volumio をインストールしてハイレゾ楽曲を再生して楽しんでいる環境が整ったのですが、そのために Raspberry Pi 2 の 40PIN には「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」を挿しました。これでコンソールは使えなくなるんですね。

せっかく Raspberry Pi 2 用に USB シリアルコンソールケーブルを購入しているので、これを Volumio で利用できれば嬉しいです。

IMG_3997_RPI2_Volumio_csl_1

しかし「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」にはピンが出っ張ってないので USB シリアルコンソールケーブルを接続することができない。

それならば。と、いうことでハンダでピンを取り付けてみました。 40PIN スロットの 6,8,10 番にピンを立てて、ここにシリアルコンソールを接続できるように改造です。電子工作だぁ。非常に簡単だけど;-)。

IMG_3990_RPI2_Volumio_csl_2

完了後はこんな感じになりました。これでサウンドカードモジュールと USB シリアルコンソールケーブルの両方が利用可能になりました。ぱちぱちぱち。

と、いうことで、早速 Volumio を起動しましょう。もう HDMI とかディスプレーとか必要ないしぃー。みたいな。まぁ、 Volumio は zeroconf が動作しているのでアクセスに関しては楽なんだけどね。

FreeBSD から以下のコマンドでシリアルコンソールを利用します。

$ cu -l /dev/cuaU0 -s 115200

オプションに指定する速度に注意でしょうかね。そして Raspberry Pi 2 に電源を投入するとコンソールが流れ始めます。おぉ。無事に使えるねぇ。良かった良かった。なんてのはつかの間。表示されるだけで入力できないじゃーん。 orz
Volumio はシリアルコンソールの設定が完結してないのかい？などと思い、ここから先は、起動した Volumio のシリアルコンソールを有効化していきます。

Volumio は OS に Ubuntu を利用しているので /etc/default/grub 辺りか？などと思い眺めますが x86 アーキテクチャではないのでそんなファイルは無いようです。

ふむ。

コンソールを使うなら /etc/inittab に何かしらの設定が必要だべ。とか思い眺めると『あ。多分のこの辺りを有効にすると行けそうだね。』という行が現れます。この辺りは FreeBSD とかやっていると知らない OS (『そこはかとなく、良く解らない OS』と言ったほうが良いか;-) でもなんとかなります。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

上記の上の行をとりあえず 115200 にして設定してみした。

# Example how to put a getty on a serial line (for a terminal)
#
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

変更後は kill -HUP 1 で反映させます。間違っても kill -9 1 とかしないように;-)。その後 ps で確認すると getty のプロセスが起動するので設定は有効になったようです。

しかし、相変わらずキーボードからの入力は受け付けてくれない状態。うむー。
多分 -L ttyS0 の部分が合っていないのだろうというのは容易に想像が付くのですが、では何を設定したら良いの？ってことになります。 Ubuntu で利用できる tty の種類は /etc/securetty の中に色々書いてあります。ただ、色々たくさん書いて有り過ぎますf(^^;;。

一応 dmesg | grep uart や dmesg | grep tty などのコマンドを打って確認。情報を色々仕入れます。あぁ。なるほどー。
dmesg | grep tty すると表示される Kernel command line: の行にどの tty を利用したら良いか書いてありますね。これを指定してみましょう。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
T0:23:respawn:/sbin/getty  -L ttyAMA0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1   9600 vt100

設定完了。今度は kill -HUP 1 してもダメだったので再起動してしてみましょう。

お。コンソールに文字が表示され、おぉ。ログインプロンプトが出てきましたっ!! やった;-)。

これで Volumio でもシリアルコンソールが使えるようになりました。ハンダ当てて改造した甲斐が有りました。
今後はディスプレーも USB キーボードも必要なくなります。一件落着です;-)。

あ。最後にですが、今回利用した Volumio は 1.55 になります。

ラズパイオーディオでハイレゾ。

4月 092016

なんか、いろんな人が書いているようなタイトルだなぁf(^^;;。

本当は前回の「ハイレゾ楽曲を作ってみました。」のエントリでネタは完了する予定でしたが、プレーヤーについて色々調べていたらハイレゾ携帯プレーヤーや USB DAC を購入するより Raspberry Pi 2 でハイレゾ音源を再生するほうがずっと安上がりだ。と、いうことが解り、早速試してみました。

手元には去年購入した Raspberry Pi 2 があり今でも FreeBSD/arm CURRENT が動作していますが、そいつを利用することにしました。
Raspberry Pi 2 に接続するハイレゾ対応のチップを購入し 40PIN にサクっと刺すとハイレゾ再生が可能になる。と、いうので amazon で「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」と、いうのを購入しました。

Raspberry Pi 2 に接続すると、こんな感じになります。

RPI2_I2S_volmio_1

購入したモノが届いたときには本体のみでマニュアルやネジ類は一切ついていません。
僕は PC を自作していた時期があったので、マザーボードと ATX ケースを固定するネジをたくさん持っていて、それを利用し I2S ボードの 40PIN の反対側に取り付けて安定性を確保しました。
そして、40PIN をグイグイと押しこみます。

以上で準備は完了です。

MicroSD に OS を準備しますが、今回は Volumio を利用しました。

あ。Volumio は 1.55 を利用していますが、最新版の Volumio2 が出るようです。最新版が出たらそっちに乗り換えるかもしれません。
Volumio2 RC1 を試してみたところ、僕の環境では見事にカーネルパニックしたので、今回は Volumio1.55 がターゲットです。

実は Raspberry Pi 2 を購入したあとに FreeBSD/arm と一緒に Volumio も試していたんです。このときはハイレゾに染まっていなかったのでフツーの音楽プレーヤーとして利用していたのですが、 USB の無線 LAN と Bluetooth ドングルが利用できなかったのでお蔵入りしていんですけどもね。

さてと。 Raspberry Pi 2 に I2S ボードを接続し MicroSD にも Volumio が入ったので早速起動します。

他のサイトを眺めていると System メニューの「I2S driver」と、いうメニューを “Hifiderry+” にすると音が出るよ。と、書かれていますが、それだけでは情報がかなり足りないですね。

RPI2_I2S_volmio_4

他にもう 1,2 ヶ所設定を変更する必要がありました。と、いうことで、まずは PlayBack メニューの「Audio Output」を指定します。

RPI2_I2S_volmio_3

default では “ALSA” になっていると思いますが I2S を利用する場合には “sndrpihifiberry” に変更する必要がありました。

その次にその下にある「Volume eontrol mixer」の設定をしますが “Hardware” を指定すると、Main メニューのボリュームサークルからから音量が変更できないので “Software” を選択します。

RPI2_I2S_volmio_2

以上三つを設定すると音が出て、ボリューム調整もできるようになります。

ふぅ。最初音が出なかったので、壊れているのか？と思ってしまったのですが、これで一安心;-)。

しかし、これでも音が出ない場合には UNIX 系な解決方法を試みます(僕は FreeBSD ユーザなので『Linux 的な』とは書かないです;-)。まずは Volumio に ssh でログインして dmesg で確認してみてください。
以下の行が出力されていればデバイス的には OS から認識されていて利用可能な状態なので、じっくりと設定とかメニューを見なおしてみてください。

snd-rpi-hifiberry-dacplus sound: pcm512x-hifi <-> 3f203000.i2s mapping ok

このメッセージが出力されていてもなお音が出ない場合は Ubuntu のコマンドで確認してみる手もあります。
僕は Lunix のマルチメディア系のコマンドはいまいち解らないんですけどねf(^^;;。

 # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ HiFi pcm512x-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
        : (中略)
card 1: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# lsmod | grep pcm
snd_soc_pcm512x_i2c     1689  1 
snd_soc_pcm512x         6340  1 snd_soc_pcm512x_i2c
snd_soc_core          140253  4 snd_soc_pcm512x,snd_soc_hifiberry_dac,snd_soc_hifiberry_dacplus,snd_soc_bcm2708_i2s
snd_pcm_dmaengine       3359  1 snd_soc_core
regmap_i2c              2354  1 snd_soc_pcm512x_i2c
        : (以下略)

Volumio では Network メニューから Wi-Fi の設定もできるのですが、僕の持っている USB Wi-Fi インターフェースでは設定してもまともに動きませんでした。なので、こちらも実機に ssh して wpa_supplicant の設定を直接手でしてしまいました。基本的に wpa_supplicant は Linux も FreeBSD も一緒なので使い回しの設定で OK でした;-)。

ネットワークの設定は結局 Volumio からではなく /etc/network/interfaces を直接 vi で編集してしまいました;-)。

あと、 I2S インターフェースを付けたのでオンボードのサウンドチップは要らないので削除します。 /etc/modules の中に書かれている snd_bcm2835 の行をコメントアウトすれば OK です。とは言っても /etc/modules には snd_bcm2835 しか書かれていないと思いますけども。

音楽系の話だけでなく、こーいう、UNIX 系技術者向けな話も中々良いですね;-)。

さてと。話をもとにもどします;-)。

今回購入した「サインスマート HIFI DAC サウンドカードモジュール I2S インターフェース」と、いう製品は PCM5122 というチップで 384kHz/32bit に対応しているそうで、もうバッチリとハイレゾ対応ですね;-)。

ここにヘッドホンを接続したりスピーカーを接続して mora の楽曲を再生してみました。

最近は通勤の往復の電車の中では ZTE Blade Vec 4G にイヤホンを利用して音を聞いているのですが、その時には 256bit/44.1KHz/16bit な m4a も mora のハイレゾ楽曲も聞きます。なので耳には慣れている音なのですが、このモジュールを利用して音を試聴すると、音質豊かで驚きます。

『人間の耳は 20kHz 以上は聞こえないんだからハイレゾは意味ねんじゃね？』とか言われていますが、聞こえる周波数・聞こえない周波数なんて関係無いですね。耳に入ってくる情報量がうんと多いのには唖然とします。ボーカルのうしろにはこんなに色々な音が隠れていたのかーっ!! って、音が耳に飛び込んでくる感じ。

ハイレゾな楽曲をハイレゾな環境で聞くとすごい音がする。ってことがよぉーく解りました。

それにしても Raspberry Pi 2 ってすげーなー。とか、思うんですが、結局のところ、行き着くところは Linux で PCM5122 のチップのドライバが書かれていて、ちゃんと音が出る。ってのがすごいねぇ。などと思えるんですけどもね。
FreeBSD では PCM5122 のデバイスドライバは無いようだしなぁ・・。

と、いうことで Raspberry Pi 2 + PCM5122 + Volumio でハイレゾ再生が可能になり、楽曲(五曲しかないけど、更に二曲追加されました;-)とプレーヤーとスピーカー・イヤホンの全てが揃いました。

CD から flac にリッピングする環境もできたのでハイレゾ環境はこれで一通り揃った感じになります。ただ、 CD -> wav -> flac 変換の楽曲が “なんちゃってハイレゾ” 以下の楽曲データであるとは多分思うのですけどね・・:-|。

さてと。これからは、楽曲をどうして行くか？と、いう点のみが残るな・・。やはり泥沼からは抜け出せないかな？ orz

ちなみに、今回のハイレゾ環境整えるのにかかった費用ですが、今のところはイヤホン・スピーカー・I2S インターフェースのみなので 23,000yen 弱でしょうかね。 Raspberry Pi 2 は最初から持っていたのでカウントされていません。

これだけの金額でハイレゾ環境が整って一安心。と、いうのが素直な気持ちですが、自分的には

ハイレゾを楽しむならまずはイヤホン・その次にスピーカ、楽曲は色々試して、最後にプレーヤーを揃える

って感じかなぁ。と、思っております。最初にプレーヤーを買っても、ハイレゾで音が聞こえないので。最初にイヤホン買うと Windows10 で試せるし。みたいな感じでしょうか。

と、いうことで、今回のハイレゾに関するエントリは全て終了です;-)。

ふぅ。

以前のエントリー

		running-dog.net。しかし、自分が一番落ち着かない。かけまわっている子犬のような状態。そんな毎日をブログで綴ってみました。 FreeBSD・MacOSX・UNIX・PC・プログラム・iPhone(iOS)・Android ネタなど技術的・趣味的なネタについて色々書いてみたいと思います。
		From 44.211.84.185