|
Not a problem LOL. I understand you guys are busy. Grame fowler was
asking some questions yesterday.
Any rate as I was telling him I also switched to trying to use LVS-DR as
well. The problem I'm running into there is I setup an Iptables rule to
do the SNAT for me on the realserver. Show below iptables -t nat -A
POSTROUTING -p udp --source-port 53 -o bond1.201 -j SNAT --to-source
192.168.67.213:53
Without the rule, nothing gets SNATed and the DNS client receives the
realserver's IP address as the source address. With the rule, the client
receives nothing. If I change the to-source to be anything other than
port 53 (i.e. --to-source 192.168.67.213:54) everything works great. The
packet gets SNATed and the DNS client receives the packet from the VIP
but on port 54. I think by SNATing with port 53 and given the fact that
my realservers are DNS servers, that another DNS lookup is happening and
failing and the original message is being dropped. The tcpdump output
from the realserver is below.
[root@jackets-d bin]# tcpdump -i any port 53
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on any, link-type LINUX_SLL (Linux cooked), capture
size 96 bytes
07:55:21.174963 IP 192.168.61.197.39260 > 192.168.67.213.domain: 1+
NAPTR? 9.9.9.0.0.0.0.0.0.9.1.e164.arpa. (49)
07:55:21.175614 IP localhost.40498 > localhost.domain: 49914+ PTR?
213.67.168.192.in-addr.arpa. (45)
07:55:21.175706 IP localhost.domain > localhost.40498: 49914 Refused*-
0/0/0 (45)
07:55:21.175782 IP localhost.40498 > localhost.domain: 49914+ PTR?
213.67.168.192.in-addr.arpa. (45)
07:55:21.175848 IP localhost.domain > localhost.40498: 49914 Refused*-
0/0/0 (45)
07:55:21.175968 IP localhost.40498 > localhost.domain: 16826+ PTR?
197.61.168.192.in-addr.arpa. (45)
07:55:21.176032 IP localhost.domain > localhost.40498: 16826 Refused*-
0/0/0 (45)
07:55:21.176081 IP localhost.40498 > localhost.domain: 16826+ PTR?
197.61.168.192.in-addr.arpa. (45)
07:55:21.176165 IP localhost.domain > localhost.40498: 16826 Refused*-
0/0/0 (45)
Then the message gets dropped. So basically I'm in limbo right now. I
need the SNAT to happen from LVS-NAT if I use that. And I cant get the
iptables rule to work using LVS-DR.
Thanks
Mike
-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Joseph
Mack NA3T
Sent: Monday, April 16, 2007 9:01 PM
To: LinuxVirtualServer.org users mailing list.
Cc: Horms; Julian Anastasov
Subject: RE: SNAT / Masquerading problems using LVS-NAT
On Thu, 12 Apr 2007, Rudd, Michael wrote:
It seems no-one knows. I'm replying so you don't think we're ignoring
you.
Julian, Horms,
Any ideas?
Thanks Joe
> After some more digging it appears this is related to the OPS or One
> Packet Scheduling feature. With the OPS feature turned off, the source
> IP address is correctly SNATed to my VIP. With the OPS feature on and
> working correctly(which we need for our UDP service), the source IP
> address isn't correctly SNATed.
>
> Is anybody aware of the code for this? I assume its related to not
> looking up the connection in the hash table anymore with OPS thus not
> SNATing. Maybe an iptables rule coudl fix this possibly?
>
> Thanks for any help
> Mike
>
> ________________________________
>
> From: Rudd, Michael
> Sent: Tuesday, April 10, 2007 3:10 PM
> To: 'LinuxVirtualServer.org users mailing list.'
> Subject: RE: SNAT / Masquerading problems using LVS-NAT
>
>
> Update has anyone seen this? I am basically seeing using LVS-NAT that
> the return packets are not being SNATed with the LVS directors VIP but
> have a source IP address of the realservers. I saw this work in the
> 2.4 kernel but havent been able to make it work in 2.6. Any clues?
>
> Thanks
> Mike
>
> ________________________________
>
> From: Rudd, Michael
> Sent: Monday, March 19, 2007 9:10 AM
> To: 'LinuxVirtualServer.org users mailing list.'
> Subject: SNAT / Masquerading problems using LVS-NAT
>
>
> My current setup has 1 director and 2 servers behind it. Heres the
> dump from ipvsadm.
>
> [root@jackets-a sysconfig]# ipvsadm
> IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port
> Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> UDP 192.168.67.213:domain rr ops
> -> dnsa-c:domain Masq 1 0 110935
> -> dnsa-d:domain Masq 1 0 110934
> [root@jackets-a sysconfig]#
>
> LVS is working the way it should except return packets are not the
> correct source IP address. They should be from 192.168.67.213 which is
> the address of the service. Instead they are the address of the real
> server. This worked in kernel 2.4 when I tested it 2 months ago. Now
> its broken in my 2.6.18 kernel.
>
> Heres also a dump from ip addr. We are doing our dns traffic based on
> bond1.201.
> ...
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500 qdisc noqueue
> link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
> 9: bond1: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500 qdisc noqueue
> link/ether 00:04:23:c5:63:fd brd ff:ff:ff:ff:ff:ff
> 10: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 11: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 12: bond0.200@bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
> link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
> inet 192.168.66.214/24 brd 192.168.66.255 scope global bond0.200
> inet 192.168.66.244/24 brd 192.168.66.255 scope global secondary
> bond0.200
> 13: bond0.202@bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
> link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.104/24 brd 192.168.2.255 scope global bond0.202
> inet 192.168.2.101/24 brd 192.168.2.255 scope global secondary
> bond0.202
> 14: bond1.201@bond1: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
> link/ether 00:04:23:c5:63:fd brd ff:ff:ff:ff:ff:ff
> inet 192.168.67.214/24 brd 192.168.67.255 scope global bond1.201
> inet 192.168.67.213/24 brd 192.168.67.255 scope global secondary
> bond1.201
> [root@jackets-a sysconfig]#
>
> I've tried the ip_route_me_harder patch I found here
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-NAT.html#br
> ow nfield but it doesnt appear to work correctly at least for me.
> Anybody got any clues as to what broke in 2.6 for this?
>
> Thanks
> Mike
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot)
net - azimuthal equidistant map generator at
http://www.wm7d.net/azproj.shtml Homepage http://www.austintek.com/ It's
GNU/Linux!
|
