Hello,
Please do not reply to a message when you start a new discussion. This
disrupts the existing thread and makes your message less visible.
Shaun Mccullagh a écrit :
Director A (62.101.52.99)
| Virtual Server (62.101.52.106)
|
|
Iptables Firewall (62.101.15.9)
|
Real Server B (10.1.60.10)
The idea is Browser Requests are sent to the Web Director. This then
encapsulates the datagrams using IPIP and tunnels them to the IPtable
Firewall which is on the same LAN as Real Server B
I've setup a tunnel on the IP Tables firewall so that it can return the
datagrams to the client browser with the same source address as the
Director
The IP Addresses used on the Director are
eth0: inet 62.101.52.99/28 brd 62.101.52.111 scope global eth0
inet 62.101.52.106/28 scope global secondary eth0
(This is used as a Virtual Server IP)
Ipvsadm looks like this on the Director:
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 62.101.52.106:80 wlc persistent 86400
-> 62.101.15.9:80 Tunnel 1 4 0
IPtables firewall uses
inet 62.101.15.9/24 scope global secondary eth1.11
inet 10.1.60.5/24 eth0.60
and
tun0@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue
link/ipip 62.101.15.9 peer 62.101.52.99
inet 62.101.52.106 peer 62.101.52.255/32 scope global tun2
This almost works.
The problem is I cannot figure out how to get the IPtables firewall to
forward the decapsulated datagrams to Real Server B. I believe this can
be done with mangling but I can't quite figure this out.
Here is my current NAT table
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 62.101.15.9 dport 80
to:10.1.60.10
If I understand correctly (I have never used IPVS), IPIP encapsulating
tunneling packets have source 62.101.52.99 and destination 62.101.15.9,
and encapsulated TCP packets have source [the client address] and
destination 62.101.52.106. So in the -d option I would put 62.101.52.106
instead of 62.101.15.9.
Input chain look like this
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 62.101.52.106 62.101.15.9 dport 80
In the filter/INPUT chain you must allow IPIP tunneling (protocol 4)
instead of TCP. You must accept TCP port 80 from any to 10.1.6.10 in the
filter/FORWARD chain, and symmetric return traffic from the server of
course.
You may also need to disable source validation (rp_filter) on the tunnel
interface tun0.
-
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
