Já faz algumas semanas que não consigo acessar o servidor SFTP do meu amigo de casa. Usando o Wireshark, vejo que minha tentativa de conexão sai do meu computador, mas não há resposta (veja também os logs do Filezilla abaixo).
Trace: CControlSocket::ResetOperation(66)
Trace: CControlSocket::ResetOperation(66)
Trace: CControlSocket::SendNextCommand()
Trace: CSftpConnectOpData::Send() in state 0
Status: Connecting to XXXX:YYYY...
Trace: Going to execute /usr/bin/fzsftp
Response: fzSftp started, protocol_version=11
Trace: CSftpConnectOpData::ParseResponse() in state 0
Trace: CControlSocket::SendNextCommand()
Trace: CSftpConnectOpData::Send() in state 3
Command: open "ZZZZ@XXXX" YYYY
Trace: Looking up host "XXXX" for SSH connection
Trace: Connecting to XXXX port YYYY
Trace: We claim version: SSH-2.0-FileZilla_3.66.5
Error: Connection timed out after 20 seconds of inactivity
Trace: CControlSocket::ResetOperation(2114)
Trace: CSftpConnectOpData::Reset(2114) in state 3
Error: Could not connect to server
A conexão funciona bem quando uso um roteador diferente, tethering pelo meu celular ou defino meu dispositivo como um "host exposto" no meu roteador (Fritzbox 7530AX). Então, tenho quase certeza de que meu roteador está causando o problema (talvez uma atualização de firmware o tenha quebrado?!)
Após uma investigação mais aprofundada com o Wireshark nesses cenários de trabalho, notei que a resposta do servidor retorna em uma porta diferente (aparentemente aleatória dentro de um intervalo) da minha solicitação inicial. Não quero encaminhar todas as portas nesse intervalo devido a potenciais riscos de segurança.
Então, minhas perguntas são:
- Como posso corrigir esse problema sem expor uma grande variedade de portas ou reverter para um firmware de roteador mais antigo?
- De forma mais geral, como é possível que a resposta SFTP chegue em uma porta diferente da solicitação, e o que o roteador precisa fazer para que isso funcione? Meus métodos de trabalho estão apenas encaminhando todo o tráfego? Isso não parece correto, mas se não for, como as respostas do servidor estão sendo transmitidas ao meu PC?
Qualquer ajuda para entender tanto o lado do roteador/rede quanto as possíveis soluções do Fritzbox seria apreciada!
Verifique novamente as regras do seu firewall. Atualize para um firmware mais recente . Considere que o novo firmware pode simplesmente ter introduzido um bug ou alguma outra alteração não intencional.
Literalmente todas as conexões TCP funcionam dessa maneira (assim como quase todos os fluxos UDP).
Se você observar o Wireshark mais de perto, verá que cada pacote tem duas portas: origem e destino (ou, de um ponto de vista diferente, local/remoto ou cliente/servidor). A porta do lado do cliente é escolhida aleatoriamente, enquanto a porta do lado do servidor é a estática "22", "80" ou "443" que você conhece.
Como uma das portas geralmente é atribuída aleatoriamente, o par de portas (local, remota) atua como uma espécie de ID de conexão exclusivo, permitindo que múltiplas conexões entre os mesmos IPs funcionem.
Nada de especial. Um roteador que utiliza mascaramento SNAT e/ou filtragem de "firewall com estado" do tráfego de saída (como geralmente fazem os roteadores domésticos) precisará rastrear cada conexão TCP para poder encaminhar as respostas de entrada adequadamente, mas faz isso por padrão como parte dos recursos SNAT e/ou firewall. Normalmente, ambos os recursos compartilham a mesma tabela de estados.
(É aí também que a porta exclusiva do lado do cliente ajuda – novamente, agindo praticamente como um ID de conexão exclusivo.)
O único tratamento especial necessário é para protocolos como o FTP tradicional (onde o roteador precisa espionar o tráfego de "controle" para estabelecer preventivamente estados de firewall/NAT para conexões de "dados" de entrada) ou o TFTP baseado em UDP (que transforma ambas as portas em únicas durante o handshake). Nada parecido com SSH/SFTP, que é uma conexão TCP única comum, não diferente do tráfego de navegação HTTPS.
Então, se o HTTP(S) de saída funciona, mas o SSH/SFTP de saída não, então ou é um problema de firmware do roteador ou possivelmente algo que você configurou e que precisa ser _desconfigurado – definitivamente não é um recurso que seria necessário habilitar.
Os roteadores "em funcionamento" estão encaminhando todo o tráfego que corresponde a uma entrada na tabela de estado do NAT/firewall (e usando as informações da entrada para DNAT esses pacotes para o endereço interno correto).
Por exemplo, execute
conntrack -L
para ver a tabela de estados iptables/nftables do seu sistema Linux. (Especialmente se você tiver algo como Docker ou Libvirt e, portanto, o sistema estiver configurado para NAT, exatamente como seu roteador, a tabela conntrack mostrará os campos de entrada 'responder para' que são usados para essa correspondência.)