Por que o vsftpd (por trás do firewall) está retornando seu endereço IP interno para o endereço pasv?

Question

Estou usando o vsftpd em um servidor Debian por trás de outro firewall do Debian. O natting está correto e eu posso conectar ao servidor ftp do lado de fora. No entanto, quando o cliente emite o comando PASV , o servidor ftp retorna seu IP interno (192.168.0.19).

Eu não tenho a diretiva pasv_address definida dentro do arquivo conf para que "o endereço seja obtido do soquete conectado de entrada" (copiado de o manual ). Parece-me que, quando um cliente externo emite PASV , o endereço IP externo do firewall deve ser retornado e, quando um cliente interno se conecta, o IP do servidor FTP interno deve ser retornado.

Quando defino a diretiva pasv_address para o IP externo do firewall, tudo funciona externamente, mas depois quebra internamente. Quando eu o defino para o endereço IP interno ou comento o pasv_address , os clientes internos funcionam, mas os externos não.

Alguém tem alguma ideia sobre isso?

Editar 1: Aqui está o arquivo de log do lado do servidor:

Thu Sep  7 10:36:15 2017 [pid 9093] FTP command: Client "x.x.x.x", "USER yyy"
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP response: Client "x.x.x.x", "331 Please specify the password."
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP command: Client "x.x.x.x", "PASS <password>"
Thu Sep  7 10:36:15 2017 [pid 9092] [yyy] OK LOGIN: Client "x.x.x.x"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "230 Login successful."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "OPTS utf8 on"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Always in UTF8 mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PWD"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "257 "/""
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "CWD /DownloadProduction/"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "250 Directory successfully changed."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "TYPE A"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Switching to ASCII mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PASV"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "227 Entering Passive Mode (192,168,0,19,192,27)."

Editar 2: Consegui fazer isso funcionar usando o ProFTPD. Aqui está o caso serverfault para isso: O servidor ProFTPd atrás do firewall retorna o endereço IP interno para conexões WAN e LAN

    

Answer 1

Se você estiver atrás de um firewall externo, a conexão de entrada virá realmente do firewall externo. Portanto, o endereço IP do servidor é seu endereço IP interno. O que você descreve é um comportamento "correto". O servidor FTP não está ciente (e não pode ser) do endereço IP externo do firewall.

O que você pode fazer é atribuir dois endereços IP ao servidor FTP. Um para um uso externo e outro para um uso interno . E configure o servidor FTP para retornar o endereço IP externo do firewall para conexões no endereço IP externo ; e endereço IP interno para conexões no endereço IP interno .

Embora eu não tenha certeza, se o vsftpd permitir tal configuração. O ProFTPD faz.

    

Answer 2

O FTP causa headake com muita frequência, porque não faz transporte de dados na conexão de controle já estabelecida, mas requer a abertura de uma conexão adicional para o transporte de dados. A primeira versão do FTP exigia que o servidor abrisse essa conexão ao cliente - isso era, às vezes, em que o NAT era desconhecido. Para fazer isso funcionar com o NAT, o PASV foi inventado para que o cliente pudesse abrir essa segunda conexão. Melhor, mas - como você experimentou - não é o ideal.

Três opções vêm à minha mente:

• Você usa o sftp em vez disso - ele não sofre com esse problema, porque está essencialmente usando ssh para controle e dados em uma e apenas uma conexão. É claro que este é um protocolo diferente, portanto, dependendo do seu ambiente, isso pode não ser uma opção.
• Ao invés de NAT no seu firewall Debian, você usa algum software de proxy ftp como o "ftp-proxy".
• Você configura dois servidores vsftp, um que atende conexões internas na porta padrão, outro, digamos, 2121, para uso externo, que obtém o pasv_address configurado para o IP externo do firewall. O NAT precisa ser adaptado para traduzir a porta 21 na porta 2121.

Answer 3

Para trabalhar com o vsfptd, fiz algumas coisas:

1. Alterou o arquivo conf para o serviço vsfptd existente
   • Ouça na porta 2121
   • Responder com IP externo
2. Encaminhe a porta 21 do firewall para a porta 2121 no servidor ftp
3. Adicionado um segundo serviço vsftpd (chamado vsftpd-internal)
   • Ouça na porta padrão 21
   • Responder com IP interno

Isso faz com que o serviço existente manipule apenas as conexões externas e o novo serviço vsftpd-internal manipule apenas as conexões internas.