FTP Modo ativo e NAT com endereçamento privado (AWS)

Question

isto está bastante relacionado com esta questão relativa ao GCP , mas na AWS, e também tentando resolvê-lo com uma abordagem diferente.

Eu tenho um cliente FTP tentando se conectar no modo ativo FTP para alguns servidores FTP localizados na Internet. O cliente FTP tem endereço privado e está atrás de um servidor de instância NAT (não do NAT Gateway)

Este servidor NAT também possui um endereço privado e está por trás do VPC Internet GW.

Diagrama:

cliente de FTP (10.60.0.0/24) - > Servidor NAT (10.254.254.0/24) - > IGW - > Internet - > Firewall / NAT - > Servidores FTP

O NAT Server é o AWS NAT Linux (kernel 4.9) com o mascaramento ativado.

Com o FTP ativo (modo de porta), isso não está funcionando.

Eu já ativei o auxiliar de FTP do CT (nf_nat_ftp) e sua regra de iptables de acionamento:

iptables -A PREROUTING -t raw -p tcp --sport 1024: --dport 21 -j CT --helper ftp

e eu posso ver que o comando "PORT" está sendo traduzido corretamente do endereço IP privado do cliente FTP para o IP privado do servidor NAT.

Infelizmente, isso não é suficiente, porque o servidor FTP está recebendo um comando FTP "PORT" ainda com um endereço privado (o do servidor NAT).

Portanto, a conexão de dados do ftp, iniciada a partir do servidor ftp, obviamente nunca volta.

Eu não posso, pelo menos por enquanto, "substituir" o cliente ftp (faz parte de um aplicativo legado).

Existe alguma maneira de "injetar" o IP público no comando PORT? Algumas idéias vieram à minha mente, mas não consegui encontrar provas de serem realistas ou estou perdendo meu tempo:

1. criando uma interface "falsa" no servidor nat com o endereço IP público e ativando / desativando seletivamente o auxiliar de CT para modificar o comando PORT. Eu tenho problemas com o roteamento correto para isso, embora (sem falar em convencer-me vale a pena tentar)

2. modificando o módulo auxiliar nf_nat_ftp com IP público codificado (assim que você usa!)

3. modificando o comando port no cliente ftp (é uma máquina Windows), não sei se um driver / ferramenta já existe para esse propósito

4. atualizando brutalmente o cliente ftp (pode ser a maneira mais realista ...?)

Sobre a opção 3: tentei NETSED , que realmente pode alterar o comando PORT , mas parece atrapalhar o nat para o cliente ftp! : (

Outras soluções são bem vindas!

Obrigado.

    

Answer 1

Tentando responder minha própria pergunta em um caso de uso limitado

O limite é: somente 1 cliente de ftp em modo ativo atrás do nat server (ele não funciona com mascaramento)

• cliente de ftp: 10.60.10.11
• nat server: 10.254.254.203
• ip público: 1.2.3.4

Primeiro, inicie o comando nat no servidor nat, porta local 21, convertendo todos os pacotes contendo "PORT 10,60,10,11" para "PORT 1,2,3,4" (deixando assim os números de porta inalterados ):

./netsed tcp 21 0 0 s/PORT%2010,60,10,11,/PORT%201,2,3,4,

Em segundo lugar, redirecione o tráfego do cliente ftp para o netsed:

iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to 21

Isso tornará o servidor ftp "feliz" e tentará efetivamente abrir uma nova conexão da porta 20 para o IP público . O IGW vai deixar passar, mas o servidor NAT não sabe como lidar com a conexão (não é no CT, é uma nova conexão).

Então, tão feia quanto possível, , agora encaminhe todo o tráfego de entrada da porta 20 para o cliente FTP interno:

iptables -t nat -A PREROUTING -p tcp -d 10.254.254.203 --sport 20 --dport 1024:65535 -j DNAT --to-destination 10.60.10.11:1024-65535

Isso está funcionando !!

Mas, uma parte de ser um hack, parece que é limitado a apenas 1 ftp-client.

Obrigado ao @Steffen por apontar que o estado da CT não foi definido.

    

Answer 2

Is there any way to "inject" the public IP in the PORT command ?

Mesmo que isso seja possível, isso não ajudaria. Embora o servidor provavelmente aceite o comando PORT com o endereço IP público, ele não poderá se conectar novamente ao cliente FTP usando esse endereço IP e porta, pois não há um estado NAT correspondente no IGW.

Se você tem dois NATs como no seu caso (servidor NAT e IGW), então ambos precisariam traduzir o endereço no comando PORT e criar um estado para passar a conexão do servidor para o IP recém-definido, porta para o IP, porta do comando PORT original.

Eu realmente recomendo deixar o FTP e usar alternativas que não precisem de conexões de dados dinâmicas como o FTP. Tais conexões dinâmicas lhe darão apenas problemas se um dos gateways NAT não for capaz de traduzir o PORT / PASV - talvez devido à falta do auxiliar FTP ou talvez porque você está usando FTPS (ou seja, FTP com TLS) onde o gateway NAT não ser capaz de ver o IP original, porta e também não pode modificar a conexão de controle conforme necessário. Use protocolos como SFTP (FTP sobre SSH), que não têm problemas com o NAT, já que eles usam apenas uma conexão TCP.