bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する。

9月 282023
 

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

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

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

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

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

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

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

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

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

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

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

 
o./boot/loader.conf

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

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

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

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

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

次に bhyve の起動設定です。

 
o. /etc/rc.conf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#!/bin/sh

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

esac

exit 1;

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

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

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

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

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

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

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

$ vncviewer localhost:5900
<以下略>

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

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

そして、次に行きます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
・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

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 になります。

 以前のエントリー