- ベストアンサー
RedHatで構築したファイアウォールサーバのDMZにアクセスできない原因と解決方法
- RedHatで構築したファイアウォールサーバのDMZにアクセスできない原因を解明するため、質問者は『図解でわかる Linuxサーバ構築・設定のすべて』という参考書を利用して勉強を行っている。
- 設定には本の通りに設定を行っているが、TestPCからWeb-Serverに接続できず、pingの結果やtcpdumpの結果も異常が見られる。
- routeとiptablesの設定を見直して接続テストを行っているが、問題の解明には至っていない。ネットワーク初心者の質問者は、アドバイスを求めています。
- みんなの回答 （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の設定が必要だと思いますが、参考書籍にそのような記載はありませんでしょうか。
その他の回答 (2)
- maesen
- ベストアンサー率81% (646/790)
回答(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宛パケットは振り分けられる」 とあるのですが、そのようにはいかないのでしょうか。。。
- pakuti
- ベストアンサー率50% (317/631)
111.222.333.64/28 それ以外は面倒なので見てません。
補足
ご回答ありがとうございます。 ネットワークが重複していることについてですが、参考にしている本に 「DMZ側にパケットが流れた場合、WAN側テーブルにもDMZ側テーブルにも一致するが、 ロンゲストマッチによりDMZ側へのテーブルが参照され、WAN宛とDMZ宛パケットは振り分けられる」 とあるのですが、そのようにはいかないのでしょうか。。。
お礼
ご回答ありがとうございます。 詳しく説明頂き、ありがとうございます。 同一サブネット内はゲートウェイを使用しないのですね。 ARP についても勉強になりました。 proxy_arp の設定は書籍内に見つけられませんでしたが、 以下の設定を追加することで、TestPCからの接続ができるようになりました。 /etc/sysctl.conf net.ipv4.conf.eth0.proxy_arp = 1 net.ipv4.conf.eth2.proxy_arp = 1 どうもありがとうございました。