- ベストアンサー
iptablesでRDPが通らない
- CentOSのiptablesで設定したルールにもかかわらず、RDP通信ができない状況に困っています。
- iptablesログを確認したところ、FORWARDチェインとOUTPUTチェインでパケットがドロップされていることがわかりました。
- 追加でルールを設定しても通信がうまくいかないため、原因を特定することができずにいます。
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
そういう事では無いです。 iptablesがLinuxのカーネルへ要求を出す時に インターフェースの指定が無いと、カーネルが認識している 1番最初のインターフェースと見做して応答する と言う事です。 *なので、eth0を利用していない場合はeth1となる。 もう少し違う言い方をすると、インターフェースの指定が無いから デフォルト（eth0）が指定されたものとして動作している と言う事です。 eth0 eth1 eth2 eth3 と合った場合、iptablesでインターフェースの指定をしないと どの向きからどの向きへの通信かは不明です。 そのため、デフォルトが利用される と言う事かと思います。
その他の回答 (6)
- pakuti
- ベストアンサー率50% (317/631)
全部読んでいなかったので、そこが疑問と気が付きませんでした。。。。 理由が以外と簡単です。 Linuxのカーネルのネットワークの認識に関する動作です。 基本的に何も指定が無いと、eth0が優先的に選択されます。 これはiptablesに限らず、例えばtcpdumpとかでインターフェースを指定しない場合もそうです。 eth0以外のインターフェースを持つ場合、該当するインターフェースを指定する癖を付けた方が良いです。
補足
補足ありがとうございます。 ＞Linuxのカーネルのネットワークの認識に関する動作です。基本的に何も指定が無いと、eth0が優先的に選択されます。 下記一文の設定をtopには入れているのですが、下記の内容ではダメなのでしょうか？ 【内容】 #cat /etc/sysconfig/network-scripts/route-eth2 172.30.2.0/24 via 172.30.1.253 それとも、 #cat /etc/sysconfig/network-scripts/ifcfg-eth0 の 【DEFROUTE=yes】 のことをおっしゃられているのでしょうか？ (ちなみに、topには、eth0,eth1,eth2と3枚のNICがありますが、 全て使用しており、3枚共に、DEFROUTE=yes の設定が入っています。)
- pakuti
- ベストアンサー率50% (317/631)
No4です。 ふっと思いました。 この通信って、行きと帰りで経路が違いますよね？ そのような通信をiptablesで設定するのは厳しいんじゃないでしょうか？ セッション管理が出来ないので、通信を許可して通信パケットが流れた場合 iptablesのバッファがいっぱいになってしまうような でも、icmp redirectで、downに投げ続ければセッションはたまらない？？ どちらにせよ、あまりお勧めな構成では無いかと思います。
補足
＞ふっと思いました。 この通信って、行きと帰りで経路が違いますよね？ そうなんです。 私もnby1215tkdさんから教えて頂きながら作業してた時にこれには気づいたんですが、 自分の考えが正しいのかわからなかったのです。 予想 行き：PC1→ハブ→top→ハブ→down→PC2 帰り：PC2→down→ハブ→PC1 (downとPC1が同セグメントのため) という経路だと思っています。 ただ、PC1に「route」を入れたときは、 強制的に経路が変わるのでつながる理由が分かるのですが 「topにiptables -A FORWARD -i eth2 -o eth2 -j ACCEPT」 を入れたとき、なぜ通るようになったのか理由が分からないので気持ち悪い状態になっています。 ＞どちらにせよ、あまりお勧めな構成では無いかと思います。 うーん。やっぱりお勧めではないですか。 なんとか、原因を解明してすっきりしたいのですが…。うーん。
- pakuti
- ベストアンサー率50% (317/631)
何をしたいのでしょう ・iptablesの勉強？ ・RDP通信？ RDP通信が優先なら、PCにルーティングを書くか downでNATするか。 iptablesの勉強と言う事であれば まずは、緩めて絞る の方針で、どこで引っかかるかを試すべきでしょう。 私は、同一インターフェースでの設定を行った事がありませんが 単純に、-i eth2 -o eth2 で、行けそうな気もします
補足
iptablesでブロックされているようなので、 それを解除させてRDP通信をしたいのです。 -i eth2 -o eth2でいけるのですが、 なぜ通るようになったのかが分からないのです。
- nby1215tkd
- ベストアンサー率60% (9/15)
topにiptables -A FORWARD -i eth2 -o eth2 -j ACCEPT を入れるとRDPが出来る なら、ＯＳ自体は、ICMP Redirect メッセージは出るように設定されていると思います。 topがtop自身が出力する ICMP Redict メッセージをフィルタしていると思います。 （topは、ICMP redirect を返そうとしているが、肝心のフィルタで、自分が出力した ICMP redirect パケットをフィルタしている） というか、最初の質問を良く見ると ICMP Redirecｔ 「PROTO=ICMP TYPE=5」 をフィルタして落としていますね。 PROTO=ICMP TYPE=5 CODE=1 GATEWAY=172.30.1.253 [SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=4519 DF PROTO=TCP SPT=58238 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 ] これ、RDPのパケットを落としているログではなく、 [172.30.1.11から172.30.2.2ヘTCP=3389(RDP)へ接続」に来たけど、ゲートウェイは 172.30.1.253だからこっちに投げないでね。とTOPが返そうとしているICMP redirect パケット(ICMP type=redirect(5) )で、これを落としているようです。 ログに出ていた分の通過フィルタを設定したように書かれていたので、ちゃんと見てません でした。RDPだけ通したということだったのですね。 中継パケットでなく、top自身が生成するパケットなので、 iptables -A OUTPUT -o eth2 -p icmp --icmp-type redirect -j ACCEPT とかで,、ICMP redirect が出るようになると思います。 おそらく,RDPの許可フィルタは不要です。PC1は、ICMP redirect を topから受け取って、 PC2宛のゲートウェイ(172.30.1.253)を学習しますから、topは直接はRDPパケット中継に 関わりません。リダイレクトメッセージで正しいＧＷに送りなおせと指示するだけですので。
お礼
情報ありがとうございました。 色々試してみた所、一応つながるようになりました。 過去設定してた内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT →RDPつながらず 今回設定変更してつながるようになった内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -j ACCEPT なぜかわかりませんが、「 -m state --state NEW,ESTABLISHED,RELATED」を消すことで RDP出来るようになりました。
補足
補足ありがとうございます。 早速リダイレクトを許可しました。 設定：iptables -A OUTPUT -o eth2 -p icmp --icmp-type redirect -j ACCEPT 確かに、リダイレクトエラーが出なくなりましたが、以下メッセージが出るようになりました。 PC1からPC2へのRDP(3389)がDROPしているようです。 【ログ】 Feb 12 21:49:32 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=24498 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK URGP=0 Feb 12 21:49:32 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24499 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:32 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24507 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:32 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=24511 DF PROTO=TCP SPT=50981 DPT=3389 WINDOW=0 RES=0x00 ACK RST URGP=0 Feb 12 21:49:33 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24521 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:34 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24545 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:35 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=24564 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK URGP=0 Feb 12 21:49:37 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24596 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:41 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=24688 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK URGP=0 Feb 12 21:49:41 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=59 TOS=0x00 PREC=0x00 TTL=127 ID=24696 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=64240 RES=0x00 ACK PSH URGP=0 Feb 12 21:49:51 top kernel: IPTABLES_FORWARD_DROP : IN=eth2 OUT=eth2 SRC=172.30.1.11 DST=172.30.2.2 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=24901 DF PROTO=TCP SPT=50986 DPT=3389 WINDOW=0 RES=0x00 ACK RST URGP=0 以下2行ルールを追加しましたが、 RDPはつながらないまま、上記エラーログが出力されます。 【追記】 iptables -A FORWARD -p tcp -s 172.30.1.11 -d 172.30.2.2 --dport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -s 172.30.2.2 -d 172.30.1.11 --sport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT 良い解決方法が無いでしょうか？ ご教授お願いします。
- nby1215tkd
- ベストアンサー率60% (9/15)
１．TOPに 172,30.2.0/24宛の経路として、GW:172.16.1.253に向ける設定はありますか？ ２．TOPは、ICMP redirectを返すように設定していますか？ 要は、ICMP Redirect機能が無効になっていませんか？ PC1はおそらく、デフォルトゲートウェイ 172.30.1.254に向いているのだと思いますが、 PC１はPC2(172.30.2.2)宛パケットをTOP(172.30.1.254)に投げることになります。 しかし、172.30.2.0/24の空間は、TOP(172.16.1.254)ではなく、DOWN（172.16.1.253)の方 にありますから、 TOPは、ICMP redirectメッセージで DOWN宛に投げなおすように 指示を行い、PC1は、DOWN宛に投げるようになります。 このとき、ICMP redirect をフィルタしていると、172.30.2.2がDOWN(172.30.1.253）側に あることが判らないため、パケットを投げることができません。 参考URL http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=29999&forum=11 ３．DOWN側でもフィルタしている、あるいは、IPフォワーディングを無効にしているという (確率はほぼ０ですが）オチはありませんか？ ＲＤＰ以外で他のPC1→PC2宛パケットが通るならその問題はないとは思います。 ４．PC1の172.30.2.2の経路を確認するとどうなりますか？ Windows でもコマンドラインで、route コマンドが利用できるため、 route -4 print で、それぞれの状態の確認してみてください。 1度も通信していない時 通信しようとしている時 1度でも通信しようとした後、通信していない時 前述のICMP Redirectの動作が確認できるかもしれません。 ５．PC1へ一時的に172.30.2.0/24の経路を設定するとどうなりますか？ Windows でもコマンドラインで、route コマンドが利用できるため、 route add 172.30.2.0 mask 255.255.255.0 172.30.1.254 保存できないため、再起動したら消えてしまいますすが、こうすると TOPは介在しないため、TOPが悪いのかDOWNが悪いのか区別がつく かもしれません。 その他 ルータであるLinux上(TOP,DOWN両方）でtcpdumpを実行してパケットを見てもよい かもしれません。 ICMP redirect等、どこまで、どの機器が関係して、パケットのフローが通っているか 判るかもしれません。 RDPパケットと（ICMP Redirectが発生しないといけないため）ICMPパケット両方 を見ることが重要です。
補足
＞1．TOPに 172,30.2.0/24宛の経路として、GW:172.16.1.253に向ける設定はありますか？ ・設定済みです。route -nで表示されていることも確認しております。 ＞2．TOPは、ICMP redirectを返すように設定していますか？ /etc/sysctl.confに、 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 二行を追記してみましたが、RDPできないままでした。 (PC1はWin7で、ICMPのエコー受信要求は、プライベートパブリック共に許可になっています。) >3．DOWN側でもフィルタしている、あるいは、IPフォワーディングを無効にしているという (確率はほぼ０ですが）オチはありませんか？ ping疎通、http疎通が取れています。 (この2点おかしな通り道をしてる気がするのですが、下記で説明させていただきます。) downのFWは全てACCEPTです。 >4．PC1(172.30.1.1)の172.30.2.2の経路を確認するとどうなりますか？ route -4 printを、pingを打つ前、打った後で試してみましたが、変化がなく 全てデフォルトゲートウェイで処理されているように見えます。 0.0.0.0 0.0.0.0 172.30.1.254 172.30.1.11 266 ＞5．PC1へ一時的に172.30.2.0/24の経路を設定するとどうなりますか？ 「route add 172.30.2.0 mask 255.255.255.0 172.30.1.253」 をPC1で設定したところ、PC2へのRDPができるようになりました。 [root@down]# tcpdump host 172.30.1.11 and port 3389 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:46:05.211388 IP 172.30.1.11.54044 > 172.30.2.2.ms-wbt-server: Flags [S], seq 1154478877, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 14:46:05.212929 IP 172.30.2.2.ms-wbt-server > 172.30.1.11.54044: Flags [S.], seq 2749818179, ack 1154478878, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 14:46:05.213160 IP 172.30.1.11.54044 > 172.30.2.2.ms-wbt-server: Flags [.], ack 1, win 16425, length 0 14:46:05.217266 IP 172.30.1.11.54044 > 172.30.2.2.ms-wbt-server: Flags [P.], seq 1:20, ack 1, win 16425, length 19 14:46:05.219296 IP 172.30.2.2.ms-wbt-server > 172.30.1.11.54044: Flags [.], ack 20, win 256, length 0 14:46:05.219378 IP 172.30.2.2.ms-wbt-server > 172.30.1.11.54044: Flags [P.], seq 1:20, ack 20, win 256, length 19 14:46:05.425499 IP 172.30.1.11.54044 > 172.30.2.2.ms-wbt-server: Flags [.], ack 20, win 16420, length 0 14:46:22.241290 IP 172.30.1.11.54044 > 172.30.2.2.ms-wbt-server: Flags [F.], seq 20, ack 20, win 16420, length 0 14:46:22.241648 IP 172.30.2.2.ms-wbt-server > 172.30.1.11.54044: Flags [.], ack 21, win 256, length 0 14:46:22.241727 IP 172.30.2.2.ms-wbt-server > 172.30.1.11.54044: Flags [R.], seq 20, ack 21, win 0, length 0 と認証画面が出るまでのやり取りをキャプチャでました。 「route add 172.30.2.0 mask 255.255.255.0 172.30.1.253」を削除して もう一度キャプチャしようとしましたが全く通信ログが表示されませんでした。 【現在わかったこと】 1点目．topにiptables -A FORWARD -i eth2 -o eth2 -j ACCEPT を入れるとRDPが出来るようになる。 2点目．httpの通信を試してみた所、PC1のウインドウズFWログで、PC2ではなく、172.30.1.253(downのeth0)インターフェースから、接続要求があったとありました。DROPされていたので、 WindowsFWのapache接続ルール「172.30.1.253」を許可するとhttp通信が出来るようになりました。 3点目．PC1に、「routeを足して通信がいけた」ので、TOPのICMP Redirect設定が良くないということでしょうか。topにリダイレクト設定は入れたつもりなのですが。 tcpdumpでどのようなコマンドを入力するとRedirect通信が行われいるか確認出来るでしょうか。 【現状やりたいこと】 できれば個々の端末にrouteaddするのではなく、topが原因ぽいので topのリダイレクト設定で解決したいと思います。 どのように解決していくのがいいのでしょうか よろしくお願いします。
- tsuduki123
- ベストアンサー率32% (21/65)
FWは詳しくないので、まとはずれだったらごめんなさい。 とりあえず確認してほしいのは、 （top） ・ルール変更後、ドロップのログが出力されていないこと ・downに対して pingが通ること （down） ・ドロップのログが出ていないこと ・topに対してpingが通ること ・ディスプレイマネージャが起動していること
お礼
情報ありがとうございました。 色々試してみた所、一応つながるようになりました。 過去設定してた内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT →RDPつながらず 今回設定変更してつながるようになった内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -j ACCEPT なぜかわかりませんが、「 -m state --state NEW,ESTABLISHED,RELATED」を消すことで RDP出来るようになりました。
補足
＞FWは詳しくないので、まとはずれだったらごめんなさい。 少しでも情報が欲しいので、大変助かります。 ＞（top） ・ルール変更後、ドロップのログが出力されていないこと →変更後表示されているログは、質問に記述させていただいたログだけとなります。 ・downに対して pingが通ること →PC1からdown、pc2に対してpingは通ります。 ＞（down） ・ドロップのログが出ていないこと →ALL ACCEPTのため問題ありません。 ・topに対してpingが通ること →PC2、downからPC1、topへのpingは通ります。 ・ディスプレイマネージャが起動していること →ディプレイマネージャというのはRDPのことでしょうか？ 【現在わかったこと】 1点目．topにiptables -A FORWARD -i eth2 -o eth2 -j ACCEPT を入れるとRDPが出来るようになる 。 2点目．httpの通信を試してみた所、PC1のウインドウズFWログで、172.30.1.253(downのeth0)インターフェースから、接続要求があったとありました。DROPされていたので、 WindowsFWのapache接続ルール「172.30.1.253」を許可するとhttp通信が出来るようになりました。 downをPC2がまたぐことによりIPが変わってる？1点目のルールは広すぎるすぎるので、 もう少し粒度を落してRDPが通るようにしたいのです。 (172．30．1．0/24 から 172．30．2．0/24 へのRDPを通す みたいなルール)
お礼
情報ありがとうございました。 色々試してみた所、一応つながるようになりました。 過去設定してた内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT →RDPつながらず 今回設定変更してつながるようになった内容：iptables -A FORWARD -s 172.30.1.11 -d 172.30.2.2 -p tcp --dport 3389 -j ACCEPT なぜかわかりませんが、「 -m state --state NEW,ESTABLISHED,RELATED」を消すことで RDP出来るようになりました。