On Mon, May 3, 2010 at 3:36 PM, Lars Ellenberg
<[email protected]> wrote:
> On Mon, May 03, 2010 at 02:42:00PM -0400, Sam Tran wrote:
>> Hi Lars,
>>
>> Here is the content of the single state file for the LDAPS TCP connection:
>>
>> [...@info-ldap-015 ~]# cat /tmp/tickle/192.168.8.171
>> 192.168.8.171:636        192.168.240.178:32913
>>
>> I tried to run the tickle_tcp manually:
>>
>> [...@info-ldap-015 ~]# cat /tmp/tickle/192.168.8.171 |
>> /usr/lib64/heartbeat/tickle_tcp -n 3
>>
>> It did send three packets to the LDAP slave. But it didn't break the
>> existing TCP connection between the VIP and the slave.
>
> It is not supposed to do that.
> By sending an invalid ACK, it is supposed to tickle the TCP stack of the
> client into sending a valid ack to the now failed over IP, which then is
> supposed to trigger a valid RST from the new server, because it does not
> know anything about that connection.
>
> As long as the endpoint is still there, the tcp session is supposed to
> be robust against such "attacks".
>
> The point of this "attack" is that the endpoint _changed_, and thus the
> tcp session is no longer valid, even though the client has not noticed
> that yet.
> The trick is to talk the client into sending _anything_ at all, so a
> suitable RST can be send to cause the client to notice, and reconnect.

Thanks for the reminder.


>
>> I have attached
>> the output of the packet capture in text format.
>>
>> Thanks,
>> Sam
>
>> No.     Time        Source                Destination           Protocol Info
>>       1 0.000000    192.168.8.171          192.168.240.178        TCP      
>> [TCP Window Update] ldaps > 32913 [ACK] Seq=1 Ack=1 Win=1234 Len=0
>
> Right. So tickle acks are send out.
> All is well ;-)

Well it didn't seem to send anything when using crm.
I manually triggered this by running the command on the shell.

>
> If some firewall in between filters out the tickle acks as invalid
> packets, well, the client is not tricked into sending anything, and
> thus needs to notice all by itself.
>

I will look into the firewall configuration between the two hosts.
Thanks, Lars for your valuable input.

Regards,
Sam
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to