仙石浩明の日記

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

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