堀田＠諫早市です。
# マルチフォロー＆引用順序を変えています。
結果的に、生半可な iptables の設定が悪さをしていたようです。
On Mon, 20 May 2002 22:45:07 +0900 (JST)
Subject [vine-users:050690] Re: source-IP に反対側の i/f のものがつく
Hisashi DATE <date@xxxxxxxxxxxxxxxxxxxx> wrote:
> 伊達＠東工大です．
フォローありがとうございます。あ、個人宛の返信は不要です。
> > なお、gw1, gw2 とも ipchains/iptables 等は設定していません。
>
> とのことですが，念のために ipchains/iptables のルールも知りたいです．
ご指摘の通り、これが原因のようです。
> # 空になっているはずなんですよね?
カラに見えるのですが、どうも違うようです？
まず gw1 ですが、IP Masq しています。これはデフォルトルートを
こちらに向けない限り、関係ないと思います。
root@ns ~# ipchains -L -n
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target prot opt source destination ports
MASQ all ------ 192.168.0.218 0.0.0.0/0 n/a
Chain output (policy ACCEPT):
次に gw2 ですが、iptables の勉強中でして、まず以下のスクリプトを
作って流しました。
root@ns2 ~# cat iptables.sh
#!/bin/bash
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -A INPUT -s 127.0.0.1 -p all -j ACCEPT
iptables -A INPUT -s 192.168.0.0/16 -p all -i eth1 -j ACCEPT
# ARP
iptables -A INPUT -s 10.252.0.128/28 -p ip -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p icmp -j ACCEPT
# フラグメント化されたパケットの２番目以降は通す
iptables -A INPUT -s 0.0.0.0/0 -p udp --fragment -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp --fragment -j ACCEPT
# Common service
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport smtp -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport domain -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p tcp -j REJECT
iptables -A INPUT -s 0.0.0.0/0 -p udp -j REJECT
# IP Masquerade
iptables -A POSTROUTING -t nat -s 192.168.0.0/16 -j SNAT \
--to-source 10.252.0.132
たぶん、最後のルールが直接の原因だと思われます。IPマスカレードを
やるつもりで入れたのですが、destination を指定していないのが敗因？
で不思議なのが、そのあと
root@ns2 ~# cat ipclear.sh
#!/bin/bash
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
というスクリプトを流して
root@ns2 ~# ./ipclear.sh
root@ns2 ~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@ns2 ~# ipchains -L -n
ipchains: Incompatible with this kernel
という状態になっているので、iptables 関連の設定はすべて解除され
ているものと思っていました。ところが、この状態でも IP Masq が有
効になっています。
大里さん（テストしていただいたようで、お手数をおかけしました）
からご指摘いただいた、
On Mon, 20 May 2002 20:40:25 +0900
Subject [vine-users:050689] Re: source-IP に反対側の i/f のものがつく
"OOSATO,Kazzrou" <kazz@xxxxxxxxxxxxxx> wrote:
> この時の、ns2 上での tcpdump -i eth1 -n icmp の結果を見たい
> 気がしますが。
root@ns2 ~# tcpdump -i eth1 -n icmp
tcpdump: listening on eth1
12:01:15.960904 10.252.0.132 > 192.168.0.218: icmp: echo request (DF)
12:01:15.961862 192.168.0.218 > 10.252.0.132: icmp: echo reply
12:01:16.955245 10.252.0.132 > 192.168.0.218: icmp: echo request (DF)
12:01:16.956025 192.168.0.218 > 10.252.0.132: icmp: echo reply
これは -t nat のなせるわざでしょうか。
> あと、arp キャッシュはどうなっているのでしょう。
root@ns2 ~# arp -an
? (192.168.0.254) at 00:02:B3:08:7F:98 [ether] on eth1
? (192.168.0.218) at 00:10:A4:15:3E:5E [ether] on eth1
> 次のことが気になります．
>
> ・ Client から ping 10.252.0.132 しても返ってくるか
はい
> ・ ns2 で ping -I eth1 192.168.0.218 とやっても tcpdump 結果は同じか
はい
> ・ ns2 で echo 0 > /proc/sys/net/ipv4/ip_forward してからやりなおすと
> ソースは eth1 のものになるか．
はい。
たださすがに、192.168.0.218 から 192.168.0.253(gw2 の内側) に
ping すると、echo reply 時の source-IP は 192.168.0.253 になる
ようです。
また、クライアント側からの IP Masq も通らなくなります。
で、別の質問になってしまうのですが、
1.nat の設定は iptables -L -n では表示されないのでしょうか。
2.nat の設定を（リブートなしで）解除するにはどうすればよいでしょうか。
--
堀田 倫英 <hotta@xxxxxxxxxxxxxx> <http://www.net-newbie.com>