Linux: IP forwarding を有効にすると ICMP redirect が無効になる

タイトルに書いたとおりなんですが、Linux のデフォルトでは、 IP forwarding を有効にすると ICMP redirect の受け取りが無効になるようです。

Linux の sysctl のマニュアルをよく読めば書いてあるのですが、ぐぐってもあまりこの症例が出てこず、久しぶりに tcpdump とにらめっこしました。

自宅にはローカル用と VPN 用の２つのサブネットが存在していて、 ローカル用のサブネットに属するマシンは、インターネットにつなぐにはルータ A 、 VPN 用のサブネットにつなぐにはルータ B と話さなければならない構成になっており、そのために ICMP redirect を使っています。ルータ A をデフォルトゲートウェイとしておいて、 VPN サブネットにつなぎたいという要求がきたときにルータ B が経路だと応答するわけです。

Windows / Mac ではすでに ICMP redirect の受け取りはデフォルトで無効になっているようで、現代ではそれに頼らずルータ A がパケットをまるっとルータ B に転送したほうが良いようですが、行きと帰りの経路が違うせいかルータ A は最初の SYN パケット以外を転送してくれず、 TCP ではこの手は使えません。良い解決法はないものか…。(似たようなことを言っているブログを見つけました。)

2016/10/18 追記: Proxy ARP による解決策を見つけました。

重症プラティその後

1月25日の投稿で重症だと思っていたプラティは、なんとその後、妊娠中であったことが判明。

しっかり目を凝らさないと見えないですが、可愛いです!!!

以上、2月14日の写真でした。随分と投稿をサボってしまいました。いまではすっかり大人になっています(汗)

btrfs send/receive は rsync よりどのくらい速いのか？

Cinnamon デスクトップ環境のみをインストールした Debian のイメージ (3.7GB, ファイル数114842) を用意し、それを同じマシンの別のハードディスクに同期する時間を計測した。使用した Linux カーネルは 4.3 である。

ベンチマーク結果は次の通り:

同期方法	初回(全コピー)	2回目以降(差分コピー)
ext4 + rsync	1m23.188s	0m3.543s
btrfs send/receive	0m53.661s	0m0.679s

見ての通り、 btrfs send/receive が rsync に比べて圧倒的に高速であった。

差分コピーにおいて、 btrfs send/receive は全ファイル数が増えてもかかる時間はほとんど変わらないのに対し、 rsync は全ファイルの更新時刻をスキャンするためそれに比例した時間がかかる。したがって、同期するファイルシステムが大きくなるにつれ、 btrfs send/receive と rsync の差は拡大する。巨大なファイルシステムのバックアップに btrfs send/receive は非常に適している。一方、 btrfs send/receive はオーバーヘッドは少なくなく、ファイル数が20000以下の場合は rsync のほうが btrfs send/receive より速い。

ただし、 btrfs send/receive は2016年2月現在、実験的機能とされており、既知の問題も多く存在する。rsync は遅いとはいえ、速度より信頼性が求められるバックアップ用途としては十分実用に耐えるものである。でも次期マシンでは rsnapshot (rsync を使ったバックアップツール)から btrbk (btrfs send/receive を使ったバックアップツール)に移行してみてもいいかなと思わせる結果となった。

プラティ重症

尾びれに白点のようなものが1つ見られ要注意対象だったプラティの一匹が、(それが原因ではない気がするが)給水口のスポンジの隙間で動けなくなっていたので、救助し予備水槽に隔離した。

現在左胸びれに異常があり容態は厳しい。

2015 秋 GNOME ログイン問題対応ログ

Debian stretchをアップデートすると

• GNOMEのログインに30秒程度かかる、またはログインできない
• GDM3のTimedLoginが作動しない

という問題に遭遇した。GDM3のバージョンは3.18.0、GNOME Shellは3.18.1である。

/var/log/messagesには

Nov 22 13:12:47 wei gdm3: Tried to look up non-existent conversation gdm-autologin

Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 226:0
Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 13:67
Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 13:68
Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 13:66
Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 13:64
Nov 22 13:13:23 wei /usr/lib/gdm3/gdm-x-session[1722]: (II) systemd-logind: got pause for 13:65

というログがある。

前者は、このバグが関係していると思われる。NVIDIA ドライバでしか発生しないという情報あり。

後者は、見当たらなかったのでファイルした。

GDM 3.14.2、gnome-shell 3.16.2 では、この問題は発生しない。とりあえずそのバージョンで hold しておくことにする。

追記: GDM 3.18.2, gnome-shell 3.18.3 では前者の問題は発生しない。(後者の問題は発生する。)

気泡の数と光量の関係

スクリューバリスネリアという水草が最近、気泡を勢い良くあげています。

LED2灯点灯時:


LED1灯点灯時:


画像の通り、光合成の量は光量に従って増えます。 また反応は速く、2灯の状態から1灯消灯して5秒もたたないうちに泡の数は下の状態になります。

逆に気泡の数を水槽照明の性能比較に使えるかもしれないですね。

追加プラティが届いた

チャイムに全く気づかず受取が3時間遅れましたが元気そうで助かりました。 プラティはメダカの仲間で、このレッドプラティという種類は全身が真っ赤なタイプです。 病原菌を持っていないことを確認するため数日間この殺風景な隔離水槽で過ごしてもらいます！
久しぶりの更新です。今後は水槽ネタを混ぜていきたいと思います。