|
On 29/08/2017 19:53, Julian Anastasov wrote:
> Hello,
>
> On Tue, 29 Aug 2017, Owain Jones wrote:
>
>> Hi,
>>
>> The packets seem to be dying at the router. As I can see the packets being
>> received on the director and the response packets being sent from the real
>> server.
>>
>> One thing I'm thinking of, that I failed to mention earlier, is that the
>> router does NAT. I've placed the VIP in the DMZ, so the director should be
>> receiving all external packets directly. But the actual machines themselves
>> are in the router's LAN and being NAT'ed.
>>
>> As I'm using LVS-DR, then the only thing that should be being changed in the
>> incoming packet is the MAC address, yes? But then, when the real server
>> responds, it'll have a different MAC address to the incoming packet because
>> it's actually a physically different machine.
>>
>> So my thought is, could this MAC address mismatch be possibly confusing the
>> router's NATting?
> The MAC usually does not play. You can also check the state
> of conntrack entries in router, if possible.
Not possible, I'm afraid.
The router is an ISP-provided thing which doesn't provide access to that
sort of thing.
> But to be sure that it
> is not the router, you can start client connection from some box
> on the LAN, then the real server will talk directly with this
> client box.
The FTP server is configured to report the external IP address.
But if I change that to the internal IP address and connect to it from a
client box within the LAN, then everything works perfectly. No issues.
So the FTP server itself works.
And using tcpdump to watch the packets, things are failing when the real
server is trying to communicate back to the client, to ACK the
half-close and close the connection (and, behaviourally, that fits
because data is being sent to the server, it's just that the connection
is not closing - so, eventually, it times out and sometimes a few bytes
are missing at the end of the file, but I'm thinking that's just caching
and if the connection did close then it would write back the whole lot
on receipt of EOF, it's only shortened because I'm having to abort the
connection manually).
>> I guess I could test it by rewriting the MAC address on outgoing packets from
>> the real server to have the MAC of the director, so that, from the router's
>> perspective, the LVS is entirely transparent.
> Almost, Linux 4.10+ decrements the IP TTL field for all
> forwarding methods including DR.
>
>> Though surely, that said, the source MAC address on outgoing packets
>> shouldn't
>> really matter, I'd have thought.
> Yep
Yeah, I thought that the source MAC address really ought to do nothing.
But the only reason I'm thinking of this is because things start failing
when the real server is passing its response to the client's FIN packet
on the passive port.
The router "owns" the LAN, by the way, and is providing the NAT. So my
thought was that, though I can't access it, it's got connection tracking
and maybe, as the source MAC coming out of the real server is different
to the dest MAC that came in on the VIP, that the router's conntrack is
not recognising the response as being connected to the request.
Confusing it.
But that's just a guess. I honestly wish I had some clue why this was
happening.
Regards,
Owain
_______________________________________________
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
|
