Eu quero me conectar a um servidor FTP da minha rede local, que está por trás de um NAT.
O gateway é um servidor Win 2008, configurado com roteamento e serviços remotos / Nat ativado. O problema existe em computadores com XP, Vista sp1 e Vista sp2.
Aqui está o que eu recebo (usando o cliente FTP padrão do DOS, mas recebo a mesma coisa usando o FileZilla)
ftp> open ftp.foo.com
Connected to ftp.foo.com.
220-
[here I wait for 30s before getting the following line]
Connection closed by remote host.
ftp>
Como você pode ver, estou desconectado antes do processo de login, por isso não tenho a oportunidade de usar o PASSV.
Veja o que funciona:
A empresa que fornece o ftp diz que o problema não está no seu final, já que posso conectar-me a partir do meu servidor NAT. O mesmo raciocínio leva ao problema de não estar do meu lado nem (eu posso conectar em outros servidores ftp)
O que devo verificar?
EDIT: aqui está o que eu recebo quando eu sniff a conexão no gateway ao tentar se conectar do meu computador por trás do nat:
Na interface voltada para a Internet:
No. Time Source Destination Protocol Info
1312 320.576218 213.186.xx.xxx 192.168.1.1 FTP Response: 220-
1313 320.576602 213.186.xx.xxx 192.168.1.1 FTP Response: 220-Bienvenue,
1315 320.610911 213.186.xx.xxx 192.168.1.1 FTP Response: 220-
E na minha interface de LAN interna:
No. Time Source Destination Protocol Info
9288 118.698920 213.186.xx.xx 192.168.0.100 FTP Response: 220-
9293 118.890406 213.186.xx.xx 192.168.0.100 FTP Response: 220-Bienvenue,
Frame 9293 (166 bytes on wire, 166 bytes captured)
Ethernet II, Src: Tp-LinkT_c6:e2:3f (00:21:27:c6:e2:3f), Dst: Giga-Byt_22:b0:99 (00:1f:d0:22:b0:99)
Internet Protocol, Src: 213.186.xx.xx(213.186.xx.xx), Dst: 192.168.0.100 (192.168.0.100)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: jini-discovery (4160), Seq: 7, Ack: 1, Len: 112
Source port: ftp (21)
Destination port: jini-discovery (4160)
Sequence number: 7 (relative sequence number)
[Next sequence number: 119 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 65536 (scaled)
Checksum: 0xa5bc [incorrect, should be 0x96cb (maybe caused by "TCP checksum offload"?)]
[SEQ/ACK analysis]
File Transfer Protocol (FTP)
9306 119.187327 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
9326 119.787350 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
No. Time Source Destination Protocol Info
9373 120.987450 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
Alguma idéia de por que esse problema de CRC pode estar acontecendo?
btw, aqui estão as minhas configurações de mtu (no gateway) e elas são idênticas no meu computador.
C:\Windows\system32>netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- --- ----- ----------- -------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 30 1500 connected Local Area Connection
13 20 1500 connected Local Area Connection 2
E aqui estão algumas análises de MTU no meu computador:
Pinging 192.168.0.1 with 1472 bytes of data:
Reply from 192.168.0.1: bytes=1472 time<1ms TTL=128
Pinging 192.168.0.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Aqui está o que eu recebo se eu tentar conectar usando o telnet:
220-
Connection to host lost.
Press any key to continue...
O pequeno bit de texto que chega sugere que pode ser algum tipo de problema MTU. A melhor maneira de avançar é instalar o Wireshark no gateway e capturar todo o tráfego envolvido na conexão FTP. Se você vir um grande pacote sendo enviado várias vezes, será MTU. Caso contrário, cole o rastreamento em algum lugar e alguém poderá interpretá-lo para você, se não estiver claro para você.
Como uma nota lateral, o problema de CRC é causado geralmente pela soma de verificação feita direcly no NIC no hardware. A pilha do sistema operacional não vê mais a soma de verificação corretamente.
Tente abrir as propriedades da placa de rede e desative qualquer tipo de descarga, pois ela deve remover essas mensagens.
Atualização:
Após uma análise mais aprofundada de seus logs, o pacote que não parece ser recebido tem apenas 166 bytes de comprimento (é o "Bienvenue " que é retransmitido repetidas vezes na interface LAN), então eu não faço isso. Acho que é uma questão de MTU aqui. Não parece ser auth/ident porque o servidor envia todos os pacotes. É embora o primeiro que tenha um erro de CRC.
Tente desativar todas as acelerações de hardware (descarregamento) no nic interno e, eventualmente, no externo, também, se isso não ajudar. Ter uma velocidade fixa e duplex também é muito bom quando a resolução de problemas permite uma causa potencial de cada vez (10 / half-duplex é um bom começo). Se funcionar, basta reaplicar uma coisa por um, para poder identificar onde está o problema.
Se nada funcionar, pode ser que o software FTP-NATing esteja em falta: O FTP é um protocolo que precisa ser manipulado para funcionar através do NAT (não aqui normalmente). Tente usar um software de proxy FTP (camada 7). Se isso funcionar, você terá uma solução alternativa, pois parece apenas para FTP.
O proxy de aplicação FTP em seu gateway NAT parece estar funcionando com o código de resposta de múltiplas linhas '220'.
Os códigos de resposta FTP são normalmente todos de linha única, mas o '-' após o número indica que mais linhas de saída estão chegando.
Eu já vi isso acontecer antes - da memória, no meu caso, era um firewall PIX.
Parece que lembrei que alguns servidores FTP podem ser avisados para não enviar respostas de várias linhas, prefixando a senha de login com um ' - ', EDIT , mas nesse caso não é o correção porque a resposta 220- está sendo enviada antes que o usuário tente fazer o login.
Se você for amigável com o administrador do servidor FTP, peça a eles que desabilitem temporariamente a faixa de login do servidor e verifiquem se o seu login prossegue mais.
Eu acho que tenho o mesmo problema irritante no meu escritório com o IPtables, exceto que sabemos que isso acontece e não queremos consertá-lo.
Pode ajudar a verificar quais portas você está bloqueando para o tráfego de entrada. Eu tenho certeza que o FTP usa apenas 21 para conexões de entrada (ou seja, você pode se conectar a algo, mas você não pode dir nele).
Tenho certeza de que a porta que você recebe em troca é negociável, por isso, pode ser uma boa idéia desfazer FTP e usar SFTP nesse caso, se puder.
Você pode tentar usar o comando debug no ftp da linha de comando do Windows. Talvez ele mostre algumas informações extras que levam à solução.
Paciente: Doutor, Doutor! Quando bebo uma xícara de chá, sinto uma pontada no olho.
Médico: Tente tirar a colher da xícara!
O ponto é: por que você está usando seu servidor como um gateway NAT? O seu modem / roteador não faz isso? Por que não tirar o servidor do caminho?
A maneira como nosso servidor FTP (proftpd) funciona é que escuta conexões na porta 21 e, em seguida, * uma vez conectado, aumenta a conexão até o intervalo 60000 ** (definido no proftpd. conf as PassivePorts )
Nosso NAT foi originalmente configurado para encaminhar apenas a porta 21 para o servidor FTP, e vimos um comportamento semelhante ao que você está vendo.
Ao restringir PassivePorts a um intervalo específico e encaminhar esse intervalo para a configuração NAT, resolveu nosso problema.
Claro, isso é do ponto de vista do servidor
Poderia ser facilmente testado, no entanto, temporariamente, ligando todas as portas e vendo se isso resolve o problema.