sshでアクセスしているサーバ上でiptablesをrestartさせると、ssh接続が切られてしまうのですけど、なんででしょう?



CentOS4で、こういうスクリプトを走らせて
====
#!/bin/sh
IPTABLES='/sbin/iptables'

$IPTABLES -F
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
# icmp(ping)と自端末からの入力を許可
$IPTABLES -A INPUT -p icmp -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT

#ssh
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT

# TCPの接続開始と応答、FTPデータなどを許可
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 他の接続はすべて破棄(ポリシーの再設定)
$IPTABLES -P INPUT DROP
====
その後、
$ /etc/init.d/iptables save
$ /etc/init.d/iptables restart
すると、
====
$ sudo /etc/init.d/iptables restart
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: nat mangle filter [ OK ]
Unloading iptables modules:
====
ここでssh接続が応答しなくなってしまうのです。つなぎ直しても応答しません。

手元にある他のサーバで同じスクリプトを走らせたあと、restartしても普通にssh接続が続行できています。

どういう条件の時つながらなくなるとか、上の手順でおかしいポイントが分る方、おられないですか?

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2009/04/16 15:55:56
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:b-wind No.2

回答回数3344ベストアンサー獲得回数440

ポイント35pt
$ sudo /etc/init.d/iptables restart

これは実際には stop 実行後に start が実行される。

stop の直後には全パケット拒否状態になるので普通はネットワークが切断される。

そして SSH が切断されるとそのコネクションで実行していたプログラムも中断するので

その後の start が実行されずに接続不能になる。


手元にある他のサーバで同じスクリプトを走らせたあと、restartしても普通にssh接続が続行できています。

stop から start までの間が極端に短い場合、SSH のコネクションがタイムアウトにならずぎりぎりで

間に合うケースがある。

負荷が低いとかネットワーク的に近いとか。

そういう場合はコネクションが切断されず、start まできっちり実行されるので問題ない。


対策としてはコネクションが切断されることを全ていに restart が中断されないようにする。

nohup コマンドをつかうか、screen で再接続できるようにしておくとよいだろう。

【 nohup 】 ログアウトした後もコマンドを実行し続ける:ITpro

Let's use SCREEN!

id:mogya

screen使ってみたのですけど、やっぱり切られてしまいました。

2009/04/16 08:42:08

その他の回答1件)

id:JULY No.1

回答回数966ベストアンサー獲得回数247

ポイント35pt

パケット フィルタ リング ルールの適用 (GUI ツール)

CentOS(というか、元になる Redhat Enterprise Linux)では、GUI からの Firewall の設定ができるようになっていて、そのための RH-Firewall-1-INPUT というチェーンが設定されています。それとの兼ね合いでは無いかと思われます。

具体的に、どうなってしまうかは確認していませんが、一度、iptables -L で適用後の状態を確認するとはっきりとした原因が分かると思います。

id:mogya

遠隔にあるサーバなので、sshが切られた状態でコマンドを走らせることは出来ないのです。

2009/04/16 08:44:17
id:b-wind No.2

回答回数3344ベストアンサー獲得回数440ここでベストアンサー

ポイント35pt
$ sudo /etc/init.d/iptables restart

これは実際には stop 実行後に start が実行される。

stop の直後には全パケット拒否状態になるので普通はネットワークが切断される。

そして SSH が切断されるとそのコネクションで実行していたプログラムも中断するので

その後の start が実行されずに接続不能になる。


手元にある他のサーバで同じスクリプトを走らせたあと、restartしても普通にssh接続が続行できています。

stop から start までの間が極端に短い場合、SSH のコネクションがタイムアウトにならずぎりぎりで

間に合うケースがある。

負荷が低いとかネットワーク的に近いとか。

そういう場合はコネクションが切断されず、start まできっちり実行されるので問題ない。


対策としてはコネクションが切断されることを全ていに restart が中断されないようにする。

nohup コマンドをつかうか、screen で再接続できるようにしておくとよいだろう。

【 nohup 】 ログアウトした後もコマンドを実行し続ける:ITpro

Let's use SCREEN!

id:mogya

screen使ってみたのですけど、やっぱり切られてしまいました。

2009/04/16 08:42:08
  • id:JULY
    最初に

    > $IPTABLES -P INPUT ACCEPT

    と INPUT チェーンのポリシーを ACCEPT にしておいて、最後に

    > $IPTABLES -P INPUT DROP

    と、DROP へポリシーを変更しているのが気になります。これが、ssh の件と直接関係があるのかどうか... 関係ないような気がしますが...。

    実際に適用されている状態を見るのは、やはりコマンドラインで iptables -L とするのが確実なのですが、/etc/rc.d/initd/iptables restart(もしくは start)で実際に適用される内容は、/etc/sysconfig/iptables というファイルに書かれています。
  • id:mogya
    最初にACCEPTしておいて最後にDROPにするのは、この辺から学んだものです。
    http://penguin.nakayosi.jp/linux/iptables.html

    iptablesはルールに当てはまったらそのルールで処理されるから、最後にDROPポリシーにしても問題ないはずだと思うのですけど。

    再起動してもらってつながるようになったので、iptables -Lも取ってみました。

    $ sudo /sbin/iptables -L
    Password:
    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    ====

    もっともこれは、再起動してsshが通る状態で取っていますので、あんまりあてにならん気がします。

    この際だからぶっちゃけると、さくらの専用サーバでして。
    sshがつながらなくなった場合、メールでリブート依頼をかけると
    「再起動しました。sshもつながることを確認しました」といわれて、再びつながるようになります。

    普通に考えると、iptables saveしてるんだから、再起動だけではつながらなくなっても不思議はないと思うのですが、
    サポートの人が「なにやってんだこいつ?」とか思ってさりげなく直してくれていたりするのでしょうか。

    それとも、なにか根本的に勘違いをしているのかなぁ。

  • id:JULY
    > ACCEPT all -- anywhere anywhere
    > ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

    むむ? 先の行で全部 ACCEPT している...。これなら ssh の行が無くても Everything OK だと思うけど。

    ...というか、最初にポリシーに DROP を指定している意味ないし(^^;。

    > 普通に考えると、iptables saveしてるんだから、再起動だけでは
    > つながらなくなっても不思議はないと思うのですが、

    確かに...。
    さくらの方で何か仕掛けがあって、再起動するとリモートからアクセス可能なように、iptables の状態を変えてしまうのかも知れませんね。

    また再起動依頼をかける覚悟で、コマンドラインから、

    # service iptables restart && iptables -L >iptables.log

    とすれば、iptables.log に繋がらなくなっている状態が保存できると思います。


  • id:b-wind
    > screen使ってみたのですけど、やっぱり切られてしまいました。
    切られるのはどうしようもない。
    あと、設定時にどういう順番で定義したかと iptables save で設定される順番は直接関係ない。
    内容を知りたければ、先のコメントにあるとおり /etc/sysconfig/iptables を参照すべし。

    > 普通に考えると、iptables saveしてるんだから、再起動だけではつながらなくなっても不思議はないと思う
    逆だ。
    設定上は正しくて、iptables の再設定が上手く動いていないだけ。

    > iptablesはルールに当てはまったらそのルールで処理されるから、最後にDROPポリシーにしても問題ないはずだと思うのですけど。
    余談だがセキュリティ上は先に DROP から始めた方がよい。ポリシー定義後、各種設定が行われるまでの間一瞬無防備になるからね。
    もっとも、さほど気にするレベルの話ではないけど。

  • id:mogya
    >> screen使ってみたのですけど、やっぱり切られてしまいました。
    >切られるのはどうしようもない。

     切られたという表現がまずかったですね。
    そのとき動いているsshが切れるだけでなく、以後再起動完了までsshもpingも全然つながらなくなってしまうのです。
  • id:mogya
    だぁ~っ!原因が分りました。

    さくらインターネットさんに問い合わせを投げたところ、
    iptables restartのタイミングでカーネルパニックしていたことが分りました。

    こうなるともう全然別の問題なので、この質問についてはここでいったん閉じようと思います。
    b-windさん、JULYさん、ご協力ありがとうございました。

  • id:JULY
    か、か、か~ねるぱにっくっすかぁ~(^^;。
    それじゃぁ、繋がらないわけだ。

    でも、それだったら再起動の依頼をしたときに気付いてくれてもよいような気がするなぁ。
  • id:mogya
    これだぁっ!

    おれ最前線ねっと - [CentOS4.7]CentOS4.7でKernel panicが起こる件。[Bug] : http://ore.saizensen.net/archives/93

この質問への反応(ブックマークコメント)

トラックバック

  • iptablesをリスタートしたらsshが切られる現象が起きまして。 最初は、...
  • CentOSのkernel panic DOOM! DOOMER!! DOOMEST!? 2009-04-22 23:07:30
    一月程前に書いた「kernel panic は体に悪いぜ」に、コメントを頂きました。”もぎゃ”さんありがとうございます。 Red Hart Bugzillの Bug 456664 - Kernel panic when unloading ip conntrack modulesを見...
「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません