仙石浩明の日記

OS って何だろう。

言うまでもなく OS といえば、 コンピュータのリソースを管理するものであり、 またハードウェアの仕様の差を吸収して、 異なるハードウェア上で同一のプログラムを 走らせることができるようにするソフトウェアである。

ただ、OS といっても、 ほとんどカーネルと呼んだほうがいいような場合もあるし、 ミドルウェアの機能をまで含んで、 アプリケーションの操作性を統一するようなものまである。 さらには Windows における Internet Explorer のように、 従来はアプリケーションと思われていたものまで OS としてしまう場合すらある。

わたしが初めて使った OS (と呼べるかどうかは微妙だが) は、 CP/M だった。自作 PC (今風に言う自作 PC ではなく、 回路の設計から半田付けまですべて自分で作る PC である。 CPUなどはもちろん LSI を使うが、 ほかは汎用 TTL でロジックをくみ上げているので、 今風に言うチップセットは存在しない) 用の BIOS を スクラッチから開発して、市販されていた CP/M を移植した。

低機能な OS をハードウェアレベルから くみ上げるところから始めたということもあって、 OS というとわたしはカーネルに近いレベルを想定してしまう。一方、

システム管理コラム集 実践してみてわかったことシリーズその1

などを読むと、 あらためて人によって OS という言葉から思い浮かべるものが 異なるものだと実感する。 私にとっては Linux の各ディストリビューションごとの差異など あまり気にしなかったりするのだが、 最近の人にとっては、ディストリビューションが違うと、 異なる OS ととらえることもあるのだろう。

ちなみに、私の自宅サーバは、 10年以上前にインストールした Slackware をベースにしている。 ベースにしているといっても、 カーネルや libc をはじめとして ほとんどすべてのプログラムをアップデートしているので、 元のディストリビューションの痕跡は皆無といっていい。 自作ディストリビューションと呼べるかもしれない。 これを私が管理する全ての Linux マシンにコピーして使っている。

会社 (KLab(株)) のサーバは、私の直轄のチームが管理していて、 こちらはさすがに自作ディストリビューションというわけにはいかず、Debian をベースにしているが、 コアの部分は KLab 独自の拡張を加えている。 つまり誰が作っても同じようになる部分は 既存のディストリビューションを使うことによって「手を抜き」、 コアの部分は独自に開発して運用コストを下げたり、 耐故障性能を向上させたり、パフォーマンスを改善したりしている。

VRRP のマルチキャスト (VRRP Advert) を取りこぼすのは、 NIC が悪いのかも、 と思って別NIC を使用するように変更してみたのだが、 相変わらずスタンバイが勝手にアクティブに昇格したがる。

アクティブ側から見ると

Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Received lower prio advert, forcing new election
Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Sending gratuitous ARPs on eth1 for 192.168.0.254

スタンバイ側から見ると

Mar 22 12:58:30 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Transition to MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      setting protocol VIPs.
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Sending gratuitous ARPs on eth1 for 192.168.0.254
Mar 22 12:58:31 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 added

Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Received higher prio advert
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering BACKUP STATE
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      removing protocol VIPs.
Mar 22 12:58:36 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 removed

tcpdump で確認すると、 VRRP Advert パケットはスタンバイ側に届いているのだが、 keepalived がそれを読めないらしい。 勝手にアクティブになるくせに、 5秒程度で Received higher prio advert して おとなしくスタンバイに戻る。

アクティブになったときに、 (自分がゲートウェイになったつもりで) 本当のゲートウェイへのルーティングを削除してしまうと、 外部への通信が途絶してしまうので、 PPPoE が成功したときのみルーティングを変更するようにした。 これで、勝手にアクティブになったとしても PPPoE が失敗する限りは 実質的に何も変わらないようになった。

keepalived を単なる死活確認にしか使っていない (しかも死んでないのに死んだと誤判断することあり) わけで、 モッタイナイお化けがでそうだ (^^;)。

sshによるバックアップ回線の監視を仕掛けて一日、 タイムアウト(監視プログラムには 10秒のalarmを仕掛けている) エラーが発生。

なぜかと思って調べてみると、 同一IPアドレスからのsshアクセスが多い、 という理由でブロックされてしまっていた (^^;)。 ssh攻撃が多い昨今、GCDのサーバには、 次のようなフィルタが仕掛けてある:

iptables -N block_ssh 2>/dev/null || iptables -F block_ssh
iptables -N ssh 2>/dev/null || iptables -F ssh
iptables -A block_ssh -j LOG --log-prefix block_ssh: \
        -m recent --name block_ssh --set
iptables -A block_ssh -j DROP
iptables -A ssh -j REJECT -p tcp --syn \
        -m recent --update --seconds 600 --name block_ssh
iptables -A ssh -j block_ssh -p tcp --syn \
        -m recent --rcheck --seconds 60 --hitcount 5 --name syn_ssh
iptables -A ssh -p tcp --syn \
        -m recent --set --name syn_ssh
iptables -A ssh -j ACCEPT

# この設定は http://d.hatena.ne.jp/hirose31/20050920/1127208718
# を参考にさせて頂きました (_O_)

つまり 1分間に 5回以上、同じIPアドレスから ssh接続があると、 10分間ブロックする。 監視元IPアドレスが、いったんブロックされると、 毎分接続を試みるわけだから、ずっとブロックされたままになる。 あわてて、監視元IPアドレスをブロック対象からはずした:

iptables -I ssh -j ACCEPT -s 60.32.85.216/29

GCD は、bフレッツでインターネットに接続している。 普通に PPPoE しているほか、 フレッツ・ドット・ネットを使っているので、 ネイティブ IPv6 でも外部から (といっても、フレッツ・ドット・ネットを使っているサイト限定だが) 接続できるので、 PPPoE がこけた (設定変更をミスったときなど) ときでも リモートから復旧させることができる。

普通はこれで十分なのだが、さらに念のためということで、 フレッツADSL でもインターネットへ接続して バックアップ回線としている。 bフレッツ側が全滅しても、 ADSL経由でログインできるようにしてある (もちろん、それぞれ別系統のハブに接続してあるし、 ログイン先のサーバは複数ある)。

このバックアップ回線は滅多に使わないので、 いつのまにか不通になっていても気づかないかもしれない、 ということで、さくっと (設定込みで 30分くらい) 監視プログラムを仕掛けた。 単に bフレッツ→インターネット→フレッツADSL 経由で ssh ログインするだけのプログラムを cron で定期的に走らせるだけだが、 不通になっていることに気づかない、という事態は避けられるだろう。

GCDの二台のゲートウェイのうちの片方 (senri.gcd.org) の 1000baseT NIC (eth0) が時々マルチキャストをとりこぼす。 二台のゲートウェイは、 VRRP で アクティブ・スタンバイ構成になっているのだが、 senri がスタンバイのときに、 もう片方 (asao.gcd.org) からの VRRP Advert をとりこぼしてしまい、 勝手に アクティブへ昇格しようとする。 一日～数日に一度くらい、このとりこぼしは起きるようだ。 アクティブになっても、 OCN へ PPPoE しに行って失敗して (asao が PPPoE しているから) スタンバイへ戻るので、まあ実害はないのだが、 あまり気持ちのよいものではない。

eth0 で VRRP するのをやめて、 eth1 (100baseT NIC) で VRRP するようにしてみた。 eth1 は PPPoE (と、フレッツ・ドット・ネットのネイティブ IPv6) 専用で、 IPv4 アドレスは割り当てていないのだが、 マルチキャストなので VRRP Advert は受け取れるようだ。

keepalived.conf はこんな感じ:

vrrp_instance VI {
    state MASTER
    interface eth1
    garp_master_delay 10
    virtual_router_id 33
    priority 230
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass XXXX
    }
    virtual_ipaddress {
        192.168.0.254/24 dev eth1
    }
    preempt_delay 300
    notify "/etc/rc.d/vrrp_notify"
}

アクティブの時の asao:

asao.gcd.org:/ # ip addr show dev eth1
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
　　link/ether 00:a0:cc:xx:xx:xx brd ff:ff:ff:ff:ff:ff
　　inet 192.168.0.254/24 scope global eth1
　　inet6 2001:c90:1448:200a:2a0:ccff:fexx:xxxx/64 scope global dynamic
　　　　valid_lft 2591983sec preferred_lft 604783sec
　　inet6 fe80::2a0:ccff:fexx:xxxx/64 scope link
　　　　valid_lft forever preferred_lft forever

セキュリティって、 分かっている人にとっては、 条件反射というか無意識のうちに意識してしまうというか、 あまりに自然な感覚だけに、 分かっていない人にどう説明するのがいいのか、とても難しい。