|
For what it's worth, I believe I've figured out the issue. The issue is/was
not with WINS at all - it's with the NetBIOS Datagram Server (NBDS) on port
138. Seems that WINS requests are being handled just fine, but logon requests
are not. I was looking at a traffic dump and noticed that NBDS requests have
the Source IP and Port embedded in the payload of the packet. So, I'm guessing
my Windows NT domain controllers, instead of using the IP header information to
return a response, are attempting to use the data embedded in the packet to
return the response. This explains why I've never seen any reply packets to
the port 138 traffic being generated by my realservers. I'm not sure there's
really much I can do about this - I suppose I can take a look at the Samba
source code and see if there's some way to tear open the NBDS packet, modify
the contents, put it back together, and then listen for the response. Not sure
if I can write a module that will do this, or if some sor
t of external helper application will be required.
-Nick
>>> On 2009/09/07 at 07:44, Joseph Mack NA3T <jmack@xxxxxxxx> wrote:
On Sun, 6 Sep 2009, Nick Couchman wrote:
> Thanks for the suggestions, Joe! On the first count, yes,
> the network where the virtual IP sits has several windows
> machines (a couple dozen). On the second count, I
> actually gave this a shot, set up Samba and turned on WINS
> Proxy, then pointed the real servers at the IP of the LVS
> machine for WINS. Unfortunately I got errors in the Samba
> logs saying that the clients need to contact the WINS
> Server.
Samba is not the easiest thing to debug I'll admit.
You have two networks of windows machines joined by a
machine that happens to be an linux LVS director, but which
isn't doing anything to packets to ports 137,138.
Getting the two networks of windows machines to be on the
same NT domain (or whatever its called) has got to be a
solved problem (although I don't know the solution).
Do the two lots of windows machines have to be on the same
IP network? In this case you'll have to NAT out 137,138 on
the realservers (I think both udp and tcp are involved). If
not, then you'll need to setup the director to do the
routing (turn off lvs first to simplify things).
I expect Samba has got to be able to do it as well.
For the ip2route method of getting realservers to talk to
the outside world have a look at
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.non-lvs_clients_on_realservers.html#3-tier_routes
Joe
--
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!
--------
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is not intended for you, or you are
not responsible for the delivery of this message to the intended recipient,
please note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information. In such a case, you are strictly
prohibited from downloading, photocopying, distributing or otherwise using this
message, its contents or attachments in any way. If you have received this
message in error, please notify us immediately by replying to this e-mail and
delete the message from your mailbox. Information contained in this message
that does not relate to the business of SEAKR is neither endorsed by nor
attributable to SEAKR.
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
