Como os túneis SSH lidam com TCP RSTs em ambos os lados?

Question

Digamos que eu tenha um túnel SSH da minha máquina local para um banco de dados em um servidor remoto.

Se eu enviar uma consulta para o túnel, ela sairá do outro lado, mas na metade do envio da consulta ou do resultado, o Banco de Dados aciona um TCP RST, como o SSH lida com isso?

Isso:

1. Espera para ACK dos pacotes em ambos os lados até que tenha recebido um ACK dos endpoints?
2. Buffer de dados no nível do aplicativo e reenvio até o sucesso?
3. Outro?

Minha preocupação é que, se o encapsulamento ACKs ocorrer antes do ACKs do outro lado, e o outro lado enviar um RST, então não há como propagar o RST de volta. Ambos os lados vão apenas pendurar.

    

Answer 1

Como "os dois lados vão simplesmente parar"? Você realmente observa isso?

Citação de "TCP / IP Illustrated, Volume 1, 2nd edition" p. 628:

The reset segment contains a sequence number and acknowledgement number. Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication "Connection reset by peer" or a similar message.

E na página anterior:

Aborting a connecting provides two features...any queued data is thrown away and a reset segment is sent immediately...the receiver of the reset can tell that the other end did an abort instead of a normal close.

(Você também pode querer rever a opção de socket SO_LINGER que pode ser usada pelo socket de escuta da sua aplicação.)