ほほほのほ - tweet:2021

sshdでPublickeyをauthorized_keys以外から持ってくる

anonymous@undisclosed.example.com (Anonymous) — Fri, 08 Jan 2021 07:15:01 +0000

sshdでPublickeyをauthorized_keys以外から持ってくる

ちょっと某所で sshd でのPublickey Authentication時のPublickeyを~/.ssh/authorized_keys以外から持ってくる設定について聞かれたので、ちょっと調べてみた。

問題

AuthorizedKeysCommand に公開鍵を引っ張ってくるscriptを指定したんだけど、認証に失敗する
sshd_configに以下の記述
- AuthorizedKeysCommand /tmp/pubkey.sh
- AuthorizedKeysCommandUser hogehoge

pubkey.shは以下の通り

#!/bin/bash -e
echo "ssh-rsa AAAA........."

ssh -v の結果

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

解決

sshdのlogを見ると、error: Unsafe AuthorizedKeysCommand “/tmp/pubkey.sh”: bad ownership or modes for file /tmp/pubkey.sh が/var/log/auth.logに出力されていた
色々調べてみると、以下が判明
- sshdは以下の条件のうち一つでも満たすと、上記エラーを吐く
  1. 他人に書き換えられる可能性のあるDirectoryに設置されている(/tmpとかはやばい)
  2. Ownerがrootではない
  3. Owner以外が書き換えることができる(g+wとかo+wだとまずい)
  4. AuthorizedKeysCommandUser に指定されたUser Accountで実行できない
というわけで、以下のように修正
- Scriptを/usr/local/bin/pubkey.shに設置
- AuthorizedKeysCommand /usr/local/bin/pubkey.sh としてsshd_configに設定
- chmod 750 /usr/local/bin/pubkey.sh を実行
- chown root:nobody /usr/local/bin/pubkey.sh を実行
- sshdを再起動

結論

この手法を使えば、LDAPでsshの公開鍵を引っ張ってくることができそうだ
OpenSSHはSecurity的に相当細かくCheckしているので、ある程度はこの手法を利用しても安全性を確保できそうだ
意外と問題の原因が分かりにくいので、追いかけるのが大変
俺はエスパーじゃないので、何をどうしたいのか説明してくれ

OS-X BigSurにAlacrittyをinstall

anonymous@undisclosed.example.com (Anonymous) — Sun, 07 Feb 2021 02:45:00 +0000

OS-X BigSurにAlacrittyをinstall

Install

HomeBrewからInstallする
- `brew install alacritty`
- man pageやterminfoが欲しい場合、以下を実施
  - 準備
    - % cd some/where % git clone https://github.com/jwilm/alacritty.git % cd alacritty
  - man page
    - % gzip -c ./extra/alacritty.man | sudo tee /usr/local/share/man/man1/alacritty.1.gz > /dev/null
  - Terminfo
    - OS-Xの場合/usr配下は保護されているので、~/.terminfoに記述されることに注意
    - 大量にUnknown Capabilityが出るが、とりあえず無視で良い
    - % tic -e alacritty,alacritty-direct ./extra/alacritty.info

Configuration

設定ファイルは

$HOME/.alacritty.yml
$XDG_CONFIG_HOME/alacritty/alacritty.yml
$XDG_CONFIG_HOME/alacritty.yml
$HOME/.config/alacritty/alacritty.yml

のいずれかに設置する。 XDG Base Directory Specificationに沿った以下の場所に配置する事も可能今回は、すでに~/.configが存在するので、~/.config/alacritty/alacritty.ymlに配置する。 <code> % mkdir -p ~/.config/alacritty % cd ~/.config/alacritty % cp some/where/alacritty.yml .

結論

日本語のInline表示ができないので、今回はpass

yash

anonymous@undisclosed.example.com (Anonymous) — Wed, 19 May 2021 09:55:00 +0000

yash

Shell scriptで色々実行しようとしていると、余計な拡張の入ったshellは使いたくなくなる。拡張に依存してPOSIXを忘れてしまうと、マシンごとに異なるshell環境でどハマりをしてしまうからである。

というわけで、POSIX準拠の比較的Primitiveなshellを探し求めてきたわけだが、結局選択できるshellは3種類に絞られてしまった。 ; ash : NetBSDやFreeBSD に付属するshell で、Almquist shellを元にしたもの ;dash : Debian, Ubuntuで採用されているshellで、Almquist shellをdebian Projectで改変したもの ; yash : magicant(WATANABE Yuki)氏が開発したYet Another SHell。一部制限事項を除きPOSIX.1-2008 (IEEE Std 1003.1, 2016 Edition) を全てサポートしているshellで、日本語の情報も十分に提供されている。

しかも、ashとdashは同じものからの派生なので、実質はそれほど変わらない。

自分の場合、OS-X上で開発しているから、/bin/shはdashのようだが、これはcommand-line edit機能をオフにしてコンパイルされているから、login-shellで使うには自力compileするか、HomeBrewで導入する必要がある。

色々探してて、yashがかなり良さそうなので試してみた。

本記事では、この yash をMacOS-X BigSur上のtmuxで利用するためのDraftである。もう少し書きたいことはあるので、何回かに分けて書いた上でまとめたいという野望はある。

yash

yashの情報は以下を参照のこと

特徴は以下の通り

小さい
POSIX.1-2008準拠
コマンドライン補完やコマンドラインエディット機能を持つ
LicenseはGPL… → 個人的には、ここだけ気に入らない。BSDライセンスなら…とも思うが、まぁ、仕方がない。
Software Development Utilities オプションと C-Language Development Utilities オプションを備えた任意の POSIX.1-2001 環境でビルド・実行できる
MacにはHomeBrewからInstallできる

yashの設定

yashの環境としては、

login shellとしては拡張の機能を使いたい
shell scriptを実行する環境としては、POSIX shellとして動いて欲しい

という２つの条件を満たすように設定する。

.yash_profile

login時に読み込まれるファイル。システムの標準設定を記載する。

yashは、特に指定をしない限り、/etc/profileや~/.profileを読み込まない。代わりに、~/.yash_profileを読み込む。

個人的にはこの挙動は気に入らないので、ln -s ~/.profile ~/.yash_profileして共通にしている。

.yash_profile

################################################################################
# Shell Configuration
################################################################################
 
## Environment Variables
# UNIX Standard Paths
PATH='/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin'
# System Specific Paths
[ -d "/usr/local/opt/openssl/bin" ] && export PATH="/usr/local/opt/openssl/bin:${PATH}"
# Personal Paths
[ -d "${HOME}/bin" ] && export PATH="${PATH}:${HOME}/bin"

ここでは、login時にどうしても設定しなければならない最小限の環境変数を設定する。こうすることで、shell scriptを実行する際に怪しい挙動を考えなくて良くなる。

/usr/local/opt/openssl/bin は、MacOS BigSurにおいて最新版のopensslをコマンドラインから実行するためにこのように設定している。
/sbin,/usr/sbin,/usr/local/sbin をPATHに入れずに、コマンド起動時に手入力する人もいるが、私は面倒なので、PATHに入れている。
~/bin は人によって色々な異論があると思うが、個人的にはscriptが大量にある関係もあって、PATHに加えている。

.yashrc

.yashrcは、shellがInteractiveモードで起動された場合に実行される(読み込まれる)ファイル。ここに、生活に関係する大量の設定を投入する。

注意点として

.yashrc は ln -s ~/.login ~/.yashrcを実行して、全てのshellで共通にする
yash/ash/dash/bash/zsh 固有の設定はshellの種類を判別して記述する
yashにおいては、.yash_profileを読み込んだのち、(POSIX非互換モードの場合、)/usr/local/share/yash/initialization配下にあるファイル(特にcommon)を読み込む。その際にPS1を書き換えてしまうので、.yash_profileにPS1など幾つかの設定を記述しても無駄になる。
迂闊な設定ミスをすると、Command-line completionやEditor利用中のCtrl-Zが効かなくなるなどの怪しい挙動を示すので注意が必要

などが挙げられる。

.yashrc

################################################################################
# Shell Configuration
################################################################################
 
### Functions
## Common
hup() { (read pid; kill -HUP $pid) </var/run/$1.pid; }
start_tmux() {
  __TMUX_BIN__=`which tmux`
  [ ! -x ${__TMUX_BIN__:-""} ] && echo "RET" && unset __TMUX_BIN__ && return
  __TMUX_SESS__=`hostname`
  __TMUX_SESS__="${__TMUX_SESS__%%.*}"
  [ ! -z ${__TMUX_SESS__:-""} ] && __TMUX_SESS__="${__TMUX_SESS__}"
 
  if [ -z ${TMUX:-""} -a -z ${STY:-""} ]; then
    __TMUX_OPTION__=""
    if ${__TMUX_BIN__} has-session -t ${__TMUX_SESS__} > /dev/null 2>&1 ; then
      __TMUX_OPTION__="attach -t ${__TMUX_SESS__}"
    else
      __TMUX_OPTION__="new-session -s ${__TMUX_SESS__} ; split-window -h"
    fi
    ${__TMUX_BIN__} ${__TMUX_OPTION__}
  fi
  unset __TMUX_BIN__ __TMUX_SESS__ __TMUX_OPTION__
}
## for yash
if [ -x /usr/local/bin/yash ]; then
  sh() { yash --posix "$@"; }
else
  sh() { /bin/sh "$@"; }
fi
 
## Yash common configuration
if [ ! -z "${YASH_VERSION}" ] ; then
  # set -f      # -f すると'*'が展開されなくなる
  bindkey --emacs '\^L' clear-and-redraw-all # for emacs mode
 
  # POSIX collect modeでは、YASH拡張が使えなくなる
  # set -o posixlycorrect
fi
 
### Personal Environment Variables
# for HomeBrew
export HOMEBREW_GITHUB_API_TOKEN="37edea7e3d75b4a84fb2d913008af7ebef407033"
 
# Shell Variables.
umask 022
 
## Environment Variables
EDITOR=vi
for i in lv less more; do which $i 2>&1 > /dev/null && PAGER=`which $i`; done;
 
## Aliases
alias h='fc -l'
alias j=jobs
alias ll='ls -laFo'
alias l='ls -l'
alias g='egrep -i'
 
alias man="LANG=C /usr/bin/man"
alias nossh='ssh -o "UserKnownHostsFile /dev/null"'
alias noscp='scp -o "UserKnownHostsFile /dev/null"'
alias svn='LANG=ja_JP.UTF-8 svn'
 
## Shell command line editing ***WARN***
set -o emacs
( set -o tabcomplete 2>/dev/null ) && set -o tabcomplete        # for NetBSD /bin/sh
 
: ${__HOSTNAME__:=$(uname -n)}
PS1="${__HOSTNAME__%%.*}"
case `id -u` in
  0) PS1="${PS1}# ";;
  *) PS1="${PS1}$ ";;
esac
unset __HOSTNAME__
 
## Execute command
[ -x /usr/bin/tset ] && eval $(tset -sQrm 'unknown:?unknown')
 
[ -f $HOME/bin/goenv.sh ] && . $HOME/bin/goenv.sh
[ -f $HOME/bin/rbenv.sh ] && . $HOME/bin/rbenv.sh
 
start_tmux
 
################################################################################
#
# 予約環境変数
# i                     : for counter
# __HOSTNAME__          : hostname
#
# __TMUX_BIN__          : tmux executable file
# __TMUX_OPTION__       : tmux options
# __TMUX_SESS_NAME__    : tmux session name
#
# __PAGER__             : temporaly pager commands
#
# This .profile is checked under following OSs.
#   - MacOS-X BigSur
#
# This .profile is checked under following shells.
#   - zsh (5.8)
#   - yash (2.51)
#   - dash (from HomeBrew)
#   - ash (FreeBSD-12.2-p3)
#
# ***** WARNINGS *****
# - dash included in OS-X BigSur is compiled without commandline completion. Must use HomeBrew version.

これで、個人的に必要になる設定は終わり。

注意点は、start_tmux()。

start_tmux

start_tmux() {
  __TMUX_BIN__=`which tmux`
  [ ! -x ${__TMUX_BIN__:-""} ] && echo "RET" && unset __TMUX_BIN__ && return
  __TMUX_SESS__=`hostname`
  __TMUX_SESS__="${__TMUX_SESS__%%.*}"
  [ ! -z ${__TMUX_SESS__:-""} ] && __TMUX_SESS__="${__TMUX_SESS__}"
 
  if [ -z ${TMUX:-""} -a -z ${STY:-""} ]; then
    __TMUX_OPTION__=""
    if ${__TMUX_BIN__} has-session -t ${__TMUX_SESS__} > /dev/null 2>&1 ; then
      __TMUX_OPTION__="attach -t ${__TMUX_SESS__}"
    else
      __TMUX_OPTION__="new-session -s ${__TMUX_SESS__} ; split-window -h"
    fi
    ${__TMUX_BIN__} ${__TMUX_OPTION__}
  fi
  unset __TMUX_BIN__ __TMUX_SESS__ __TMUX_OPTION__
}

tmuxは、複数を重なって起動すると幸せにならないので、Hostnameなどを利用したtmux sessionを作成し、必要があればnew-session、なければ attach、それもなければ、tmuxをskipするようにしてある
一時利用した環境変数はちゃんと消去する
どこかで間違って上書きされないように、被らない変数名をつけ、確実にunsetする
localはPOSIXに存在しないので、利用しない

yashのDebugのために必要な幾つかのコマンド

set -o
- 現在の各種オプションの設定確認
set -o poisly-correct
- POSIX互換モードに移行する
set -o emacs
- emacsモードでの行編集が可能になる
local
- local変数を表示する
typeset -f
- 定義されている関数を表示する

終わりに

まだまだ書くべきことはたくさんあるが、ひとまずここまで。

shell関連メモ

anonymous@undisclosed.example.com (Anonymous) — Tue, 27 Apr 2021 15:15:00 +0000

shell関連メモ

ash/yash/bash/zshで定義済み関数一覧を出力する typeset -f
ash/yash/bash/zshで関数名だけ抜き出す typeset -f | grep '.*()[ ]*[{]*' | tr -d “() {”
ash/yash/bash/zshで関数を消す unset -f [funcname]

個人的なtmux memo

login時にtmuxを起動する(もし起動してたらattachする)ようにしているので、iTerm2でTab２枚目を作成すると問答無用でtmuxがattachされてしまう。ちょっと困るので、自分の設定ベースだがメモ。

^x^z: Suspend the current client
^x^d: Detach the current client
^x D: Choose a client from a list
^x (: Switch to previous client
^x (: Switch to next client
^x c: Create new Window
^x n: Switch to next window
^x p: Switch to previous window
^x w: Choose a window from a list

tmuxは起動時に「tmux server」と「tmux client」を起動するので、psすると2つのprocessが見える。

LibreOffice for Mac 7.1.3.2

anonymous@undisclosed.example.com (Anonymous) — Mon, 24 May 2021 11:25:00 +0000

LibreOffice for Mac 7.1.3.2

Macで便利に使っているLibreOfficeだが、日本語化したあとMenuのToolTipが文字化けするのが非常に気に入らなかった。

色々対策が出ているが、完全なものがなくイライラしていたのだが、どうやら解決したらしいのでメモ。

Terminal Appを利用する
/Applications/LibreOffice.app/Contents/Resources/fonts 及び /Applications/LibreOffice.app/Contents/Resources/resource/common/fontsに必要なFont Grif がないのが問題の根本の模様
以下を実行すれば良い

mv /Applications/LibreOffice.app/Contents/Resources/fonts /Applications/LibreOffice.app/Contents/Resources/fonts.bak
mv /Applications/LibreOffice.app/Contents/Resources/resource/common/fonts /Applications/LibreOffice.app/Contents/Resources/resource/common/fonts.bak

これで文字化けのほとんど（今のところ、文字化けを見ることはない)が解消する

FreeBSD EtherIP でトラブル(未解決)

anonymous@undisclosed.example.com (Anonymous) — Thu, 24 Jun 2021 01:25:00 +0000

FreeBSD EtherIP でトラブル(未解決)

FreeBSD 12-RELEASE を利用して以下の環境を構築したところうまくいかなかった。

以下は、症状を再現するための必要設定のみ記載している。

試験環境: FreeBSD rt12 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC amd64 基盤：VMware 5.5 及び、XCP-ng 8.2.0

Bridge0 -- gif0 -- em0 -- (network) -- em0 -- gif0 -- Bridge0
Node A   FreeBSD 12 ->|               |<- FreeBSD 12   Node B

なお、試験環境は、VMware上で構築している。また、自明だと思うが、kernel側でv4 forwarding/v6 forwardingを1にして、Routerモードにしてある

NodeAで設定したのは以下の通り

ifconfig em0 10.0.0.1/24
ifconfig gif0 create
ifconfig gif0 mtu 1500					# 記述ミス。追記
ifconfig gif0 tunnel inet 10.0.0.1 10.0.0.2
ifconfig gif0 inet 172.16.0.1/24 alias
route add -net 172.16.1.0/24 -iface gif0
ifconfig bridge0 create
ifconfig bridge0 mtu 1500				# 記述ミス。追記
ifconfig bridge0 addm gif0 -stp gif0

NodeBで設定したのは以下の通り

ifconfig em0 10.0.0.2/24
ifconfig gif0 create
ifconfig gif0 mtu 1500					# 記述ミス。追記
ifconfig gif0 tunnel inet 10.0.0.2 10.0.0.1
ifconfig gif0 inet 172.16.1.1/24 alias
route add -net 172.16.0.0/24 -iface gif0
ifconfig bridge0 create
ifconfig bridge0 mtu 1500				# 記述ミス。追記
ifconfig bridge0 addm gif0 -stp gif0

以上のように設定したところ、通信ができなかった。(NodeAでping 172.16.1.1を実行した)

tcpdumpでgif0の通信内容を見る(tcpdump -ni gif0) と、AF Unknown (18), length 46:が表示される。また、この時にtcpdump -ni em0を見ると、IP 10.0.0.1 > 10.0.0.2: ip-proto-97 86 のように、Packetは出て行っており、IPのProtocol番号97で通信しているようだが、pingは届かない。(parameter errorが出る)

この問題は、IP AddressをIPv4からIPv6に置き換えても変わらなかった

追記(記載忘れ。20210530)

いくつかのWeb Pageに、sysctlでkernelパラメータをいじるという記事があるので、実行したが変化なし
- ```
sysctl net.link.bridge.ipfw=0
sysctl net.link.bridge.pfil_bridge=0
sysctl net.link.bridge.pfil_member=0
```
bridge0 に物理I/Fを追加してみたが、これも効果なし
- ```
ifconfig bridge0 addm em1 -stf em1
```

問題を切り分けようと、bridge I/Fを削除すると、問題なくICMPが届くところを見ると、gifでの通信は正常にできていると考えられる。

とすると、FreeBSDのbridge deviceがEtherIP関連でものすごく変なことをしているとしか考えられない… と思って、ifconfig bridge0 deletem gif0 をNodeA/NodeBの両方で実行すると、問題なく通信できるようになる。

よく見る（症状1）と、

bridge0にgif0が所属していない時は、gif経由でいわゆるIPv4/IPv6パケットが流れた
bridge0にgif0が所属している時(addmした時)は、protocol number 97(EtherIP/on em0)/(parameter error/on gif0)の通信のように見える (tcpdumpのBinaryを解析する根性はなかった)。

追記(20210530)

以前、佐藤先生から、中を解析するには、Protocol number=97を追いかけるしかない、というお話をいただいている。

問題は、同一のFreeBSD同士でのgif+bridgeを用いたEtherIP通信が、IPv4でもIPv6でも失敗するところ。なお、NECのIX2000シリーズのEtherIPと繋ごうとしてもつなげないので、流石にFreeBSD側のBUGと考えるしかないが、問題はそのBUGが bridge(if_bridge.c) にあるのか gif(if_gif.c)にあるのかわからない…

なお、いくつか試験するにあたって、

gifのみにIP Address(172.16.0.1/172.16.1.1)を割り当てた場合
bridgeのみにIP Address(172.16.0.1/172.16.0.2)を割り当てた場合 (BridgeはBridgeをDirectに繋いでいるので、同一Segmentである必要がある)
lo9を作成してそこのみにIP Address(172.16.0.1/172.16.1.1)を割り当てた場合

の3パターンを試験したが、全て、上記の症状１が観測された。

FreeBSD 9系列では動いているという報告はあるのだが、それもどこまで信用すれば…(いまさらFreeBSD 9-RELEASEを作る気にならなかった) そして、FreeBSD 13で動くかわからないしなぁ。

なんで俺はこんなに罠にハマるんだろう… しかも、なんで6時間もDebugにはまったんだろう… さて、どうすれば解決できることやら…

FreeBSDのMulti-Fibとpacket送出について(駄文)

anonymous@undisclosed.example.com (Anonymous) — Mon, 02 Aug 2021 17:25:00 +0000

FreeBSDのMulti-Fibとpacket送出について(駄文)

FreeBSDのMulti-FIBとIPパケット送出について、なんとなく色々考えていたら、少し問題がありそうなことに気がついたので考えてみた。なお、実際のcodeは見ていないので、もしかすると大勘違いをしている可能性があります。

そこそこ長いかもしれないので、興味のない人はスルーでお願いします。

前提

想定している構成は以下の通り

                                    AS-A               addr(A)
            AS-C       +-------- ISP-A --- Router ---+
node --- ISP-C --- Internet                        Server
    addr(C)            +-------- ISP-B --- Router ---+
                                    AS-B               addr(B)

上記構成において、仮にserverのnic0がaddr(A)を持ち、nic1がaddr(B)を持っているとする。この仮定は今時の日本においては、それほど荒唐無稽なものではない。

例えば、自宅にFlet'sを引き込み、Multi-Sessionを用いて上流ISPを２社と契約し、固定アドレスを割り当ててもらうような場合がこれに当たる。まぁ、それほど多いとは思わないけど、こういう構成のサイトは企業も含めてそれなりにある。

考察

このようなサイトにおいて、あるnode(addr(C))からaddr(A)にパケットが来たとする。

addr(A)を持つサーバー(Serv)のFIB次第で、返答のパケットが送り出されるNICが決まる現在のFreeBSDの実装だと、以下のような状況が発生する。

ServerのFIBに載っているaddr(C)へのBest経路がnic0側(ISP-A側)にあった場合
- servは、Src: addr(A)、Dst: addr(C) 、Nexthop: nic0側の中継node
ServerのFIBに載っているaddr(C)へのBest経路がnic1側(ISP-B側)にあった場合
- servは、Src: addr(A)、Dst: addr(C) 、Nexthop: nic1側の中継node

としてパケットを送出する

現在FreeBSDのnetinet/netinet6の実装は、パケットを送り出す際に、送り出すパケットのsource IP Addressは考慮しておらず、FIBを見た上でベストなI/Fから送り出す。つまり、FreeBSDのip送出ロジックは

Dest Addrを確認
FIBからDest Addrをlookupしてnexthopを決定
nexthopに対してもっとも近いnicを決定
3で決定したnicからpacketを送出

となっていると考えられる。

このような実装において、１の状況になってくれれば問題は発生しないが、もし２の状況になった場合、nic1側の中継nodeがaddr(A)がsrcのパケットを中継してくれるとは限らない。 (これを許すと困ったことになるのはISPで運用していれば理解できると思うので、ここでは詳述しない)

この問題を解決するは、本質的には「全てのI/FにFIBを持たなければならない」と考えられる。なぜなら、入ってきたI/Fからパケットを出すためには、（本質的には）それぞれのI/Fにdest毎のnexthopを持たなければならないからである。（ただし、FIBを共通化することができる可能性はあるし、そのようにNetworkを構成することができる場合も多いとは考えられる。）

現状のFreeBSDの実装でこの問題を無理矢理にでも解決しようとした場合、pfやipfwを用いたpolicy routeで処理するしかない。例えば、SRC ADDRがaddr(A)ならば、nic0側のnexthopにpacketを投げる。addr(B)ならnic1側のnexthopにpacketを投げるといった設定を投入ればよい。

しかし、ここでPolicy Routeを利用せずに問題を解決しようとすると、解決策がない。突破口になりそうな機能としてはMulti-FIBがあるが、そこには下記のような問題がある。

FreeBSDのMulti-FIBは、Process単位にFIBを選択可能である。

問題は、Processに割り当てられるFIBを、起動時に１つ設定できる。(もちろん、FIBを選択できるようにApplicationを作成すれば問題にならないが、nginxやapacheなどにその修正を投入するのはそれほど簡単ではなく、現実的ではない)。逆に言えば、パケット送出時に必要なFIBを選択することは（あくまでProcessがそのように実装されていなければ）できない。

つまり、Processレベルで見ると、上記パケット送出時の問題がそのまま残っていると言える。

結論

今のFreeBSDの実装においては、本問題を解決するためにはpolicy routeを利用するしか手がない。

解決策の案

まず、ほとんどの場合、現在の実装で問題はないと言える。想定した構成は、あくまで例外的な構成であり、構成変更できる場合はやりようがあるからである。

例えば、Serverのnicを１つにまとめて、routerでNATするという手が考えられる。こうすることによって、serverはNATされたsource addressから通信を受け取るので、返答をrouterに送れば良くなる。ただし、この場合は、Routerの性能などが問題になる可能性がある。特にNATはstateを持つので、耐障害性などを考慮すると、故障箇所が増えたりdebugが面倒になるなどのデメリットはある。

まぁ、文句ばかり言っても仕方がないので、もし実装を変えるならどうするべきかを考察してみる。

問題の根本は、FreeBSDにおけるMulti-FIB実装が「Process単位でFIBを選択する」実装になっていることにある。これをI/F単位にFIB指定する(ProcessからはFIBは選択しない)形式に直すことで、本問題は解決できると思われる。ただし、いくつか制限が出てくる(本質的には不要かもしれない。まだそこまで考えたわけではないので）

NIC側の制限
1. (Physical/pseudo問わず)全てのNIC deviceに割り当てられるのは、Address１つのみに制限する
  - 割り当てたAddress毎にFIBを設定するという手はあるのでこの制限は回避可能かもしれないが、管理がややこしいことになりそうな気がする
2. 代わりに、全てのNICには「sub nic」を割り当てられるようにする (すでに不可能ではないはず)
  - en0.0 / en0.1 / en0.2…など
3. 任意のNIC/sub NICにおいて、「同一のIPv(4|6)アドレス」を持ってはならない（prefixlenが違ってもアドレスが同じならだめ)
FIBの制限
1. 原則として、FIBは最低で1つ存在する
2. 原則として、FIBは複数作成できる
3. FIBには条件を指定したsub FIBを作成することが可能
  - 例えば、FIB0(=FIB0.0) / FIB0.1 / FIB0.2 / … / FIB1(=FIB1.0) / FIB2(=FIB2.0) / FIB2.1 / …
4. 条件として設定できるのは、TCP/UDPのport番号など (ここは生煮え)
  - FIB0.0 : FIB0のdefault FIB / FIB1.0 : FIB1のdefault FIB / FIB1.1 : FIB1のsub FIBでTCP443/UDP443の場合にのみ利用する / ….など
5. 1つのNIC/sub NICに割り当てられるのは、FIBのMajor番号が同じである一連のもののみ
  - nic0 : FIB0 / nic0.1 : FIB1.0, FIB1.1 / nic1 : FIB0 など

以上の制限を課した上で、ip_output.cで、

source Addressを元にして output I/Fを決定する
output I/Fが決まれば、FIB Baseが決まる
SubFIBが存在する場合、制限条件を確認し、sub FIBを決定する。制限条件がない場合、sub FIBは0になる (FIB1→FIB1.0やFIB1.1になるという意味)
決定されたFIBから経路をlookupする。
nexthopを決定する。もしnexthopが決定できなかった場合、“DEST UNREACH”とする
パケットを構成し、送出する

という処理を行う。

問題

上記実装の問題として、今思いつくのは、

pfやipfwなどのPolicy Routeと相性が悪そうな気がする
判断が多くなり遅くなる
変更が大きいため、Debug/安定化が遠い
Process単位でFIBを変えたい場合に対応が難しい
- sub FIBを利用すれば解決できそうに見えるが、全ての場合を網羅できるかはわからない

が考えられる。

WireGuard for FreeBSD の(おそらく)BUG

anonymous@undisclosed.example.com (Anonymous) — Wed, 04 Aug 2021 18:55:00 +0000

WireGuard for FreeBSD の(おそらく)BUG

大したBUGではないけど、見つけてしまったのだから仕方がない。

minira# diff -c wg-quick /usr/local/bin/wg-quick
*** wg-quick    Thu Aug  5 03:28:13 2021
--- /usr/local/bin/wg-quick     Mon Jul  5 06:18:56 2021
***************
*** 97,103 ****
                        SaveConfig) read_bool SAVE_CONFIG "$value"; continue ;;
                        esac
                fi
!               WG_CONFIG+="$stripped"$'\n'
        done < "$CONFIG_FILE"
        shopt -u nocasematch
  }
--- 97,103 ----
                        SaveConfig) read_bool SAVE_CONFIG "$value"; continue ;;
                        esac
                fi
!               WG_CONFIG+="$line"$'\n'
        done < "$CONFIG_FILE"
        shopt -u nocasematch
  }

見ればわかるけど、本当に大した話じゃない…

# しかし、空行を削除してもいい気はするし、しなくてもいい気もするなぁ。単にuniq通すだけだからまぁ、どっちでもいいんだけど。

[FreeBSD] ZFS/XCP-ng Disk増加

anonymous@undisclosed.example.com (Anonymous) — Sun, 26 Sep 2021 17:05:00 +0000

[FreeBSD] ZFS/XCP-ng Disk増加

XCP-ng上で動かしているFreeBSDのVMにおいて、zrootの容量を増やす方法なお、FreeBSD 11.2-RELEASEとFreeBSD 13.0-RELEASE-p4で動作確認した。

FreeBSD VM(以下VM)をshutdownする
- しなくてもいいのかもしれないが、block deviceを扱うので、止めておいた方が無難だろう
XCP-ng側で、Storageの容量を増やす
- 今回は20G追加して40Gにした
VMを起動する
dmesgなどで、xvbdの容量を確認し容量が増えていることを確認する
- 今回の対象Diskはada0に割り当てられている

以下の作業を実行

# dmesg
(snip)
xbd0: 40960MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ada0
(snip)
GEOM: ada0: the secondary GPT header is not in the last LBA.
(snip)
# zpool set autoexpand=on zroot
# gpart show
=>      40  41942960  ada0  GPT  (40G) [CORRUPT]
        40      1024     1  freebsd-boot  (512K)
      1064       984        - free -  (492K)
      2048   4194304     2  freebsd-swap  (2.0G)
   4196352  37744640     3  freebsd-zfs  (18G)
  41940992      2008        - free -  (1.0M)
 
# gpart recover ada0
ada0 recovered
# gpart show
=>      40  83886000  ada0  GPT  (40G)
        40      1024     1  freebsd-boot  (512K)
      1064       984        - free -  (492K)
      2048   4194304     2  freebsd-swap  (2.0G)
   4196352  37744640     3  freebsd-zfs  (18G)
  41940992  41945048        - free -  (20G)
 
# gpart resize -i 3 ada0
ada0p3 resized
# gpart show ada0
=>      40  83886000  ada0  GPT  (40G)
        40      1024     1  freebsd-boot  (512K)
      1064       984        - free -  (492K)
      2048   4194304     2  freebsd-swap  (2.0G)
   4196352  79689688     3  freebsd-zfs  (38G)
# zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot  37.5G   708M  36.8G        -         -     0%     1%  1.00x    ONLINE  -
# zpool status
  pool: zroot
 state: ONLINE
config:
 
        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          ada0p3    ONLINE       0     0     0
 
errors: No known data errors
# zpool set autoexpand=off zroot
# zpool get autoexpand zroot
NAME   PROPERTY    VALUE   SOURCE
zroot  autoexpand  off     default
#

これで終わり。