アプリ版:「スタンプのみでお礼する」機能のリリースについて

RedHatで構築したファイアウォールサーバのDMZにアクセスできない原因が解らない。

『図解でわかる Linuxサーバ構築・設定のすべて 一戸英男(日本実業出版社)』を参考に、
RedHat Enterprise Linux 5 で ファイアウォールサーバ(以下、FW-Server)の構築を勉強しています。
構築した環境は以下になります。

========================
TestPC : RedHat
-----------------------
IP : 111.222.333.65/28
========================
  |
==========================
FW-Server : RedHat              =====================
--------------------------         Web-Server : RedHat
eth0 : 111.222.333.70/28           ---------------------
 eth2 : 111.222.333.73/29 --- DMZ --- 111.222.333.75/29
eth1 : 192.168.1.1                =====================
==========================
  |
  |
  LAN

eth0 : WAN
eth2 : DMZ
eth1 : LAN
と、想定して構築しています。

route、iptables の設定は、本の通り設定を行ったつもりなのですが、
TestPCからWeb-Serverに接続する(Webページを表示する)ことができません。

・Ping について
TestPC からは、Pingは eth0、eth2 まで飛び、Web-Serverまで飛ぶことができません。
LAN からは、PingはWeb-Serverに飛び、Webページを表示することができます。
FW-Serverからは、PingはWeb-Serverに飛び、Webページを表示することができます。

・tcpdump コマンドについて
FW-ServerとWeb-Serverでtcpdumpコマンドを実行し、TestPCから接続を試みたところ、
FW-Serverでは反応がありますが、Web-Serverでは反応がありません。

・route の設定について
routeの設定は以下になります。

route add -net 111.222.333.72/29 gw 111.222.333.73 eth2
route add -net 111.222.333.64/28 gw 111.222.333.70 eth0
route add -net 192.168.1.0/24 gw 192.168.1.1 eth1
route add -net 0.0.0.0 gw 111.222.333.65 eth0

・iptables の設定について
iptablesの、基本ポリシーと各NICのFORWARDの設定は以下になります。

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth2 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth2 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT


iptables や route の設定を変えて接続テストを行っていますが、接続することができません。
RedHat については、インストールから行っています。
ネットワーク初心者ですので、行った設定について不備な点・怪しい点について見当がつきません。
確認事項だけでもアドバイスを頂けると助かります。よろしくお願いします。

A 回答 (3件)

おそらくこういうことだと思います。

(間違っていたらごめんなさいです)
ネットワークが重複しているので、TestPCから見てDMZが同一サブネットであるためゲートウェイ(111.222.333.70)を使用しません。
そのためTestPCブロードキャストドメイン内で111.222.333.75(Web-Server)を探しますが、111.222.333.75(Web-Server)はゲートウェイの向こう側であるため通信出来ないということだと思います。
従って、そもそもDMZ側にパケットが流れません。
そうすると、eth2のIPアドレスへのpingが応答することが不思議だと思われるかもしれませんが、これはLinuxのデフォルトの仕様です。
arp_ignoreをキーワードに調べると詳細がわかると思います。

質問者さんの環境でTestPCとDMZ側のノードが通信出来るようにするためには、proxy_arpの設定が必要だと思いますが、参考書籍にそのような記載はありませんでしょうか。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

詳しく説明頂き、ありがとうございます。
同一サブネット内はゲートウェイを使用しないのですね。
ARP についても勉強になりました。

proxy_arp の設定は書籍内に見つけられませんでしたが、
以下の設定を追加することで、TestPCからの接続ができるようになりました。

/etc/sysctl.conf
net.ipv4.conf.eth0.proxy_arp = 1
net.ipv4.conf.eth2.proxy_arp = 1

どうもありがとうございました。

お礼日時:2010/06/03 13:57

回答(1)の方も指摘されていますが、


WAN側のネットワークとDMZ側のネットワークが重複しているからでしょう。

WAN側のネットワークアドレス 111.222.333.64/28
有効なIPアドレス 111.222.333.65~111.222.333.78
ブロードキャスト 111.222.333.79

DMZ側のネットワークアドレス 111.222.333.72/29
有効なIPアドレス 111.222.333.73~111.222.333.78
ブロードキャスト 111.222.333.79

見比べれば重複しているのが判ると思います。

この回答への補足

ご回答ありがとうございます。

ネットワークが重複していることについてですが、参考にしている本に
「DMZ側にパケットが流れた場合、WAN側テーブルにもDMZ側テーブルにも一致するが、
 ロンゲストマッチによりDMZ側へのテーブルが参照され、WAN宛とDMZ宛パケットは振り分けられる」
とあるのですが、そのようにはいかないのでしょうか。。。

補足日時:2010/06/02 14:32
    • good
    • 0

111.222.333.64/28



それ以外は面倒なので見てません。

この回答への補足

ご回答ありがとうございます。

ネットワークが重複していることについてですが、参考にしている本に
「DMZ側にパケットが流れた場合、WAN側テーブルにもDMZ側テーブルにも一致するが、
 ロンゲストマッチによりDMZ側へのテーブルが参照され、WAN宛とDMZ宛パケットは振り分けられる」
とあるのですが、そのようにはいかないのでしょうか。。。

補足日時:2010/06/02 14:33
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!