質問: win2008 natの背後から一部のftpサーバーに接続できないのはなぜですか? natの背後にあるローカルネットワークからftpサーバーに接続したい。ゲートウェイはwin2008サーバーであり、ルーティングとリモートサービス/ natが有効になっています。この問題は、xp、vista sp1、およびvistasp2コンピューターに存在します。これが私が得るものです(デフォルトのdos ftpクライアントを使用しますが、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> ご覧のとおり、ログインプロセスの前に切断されているため、passvを使用する機会がありません。動作するものは次のとおりです。 その他すべて(つまり、ftpに関連しないすべての接続) 私のnatゲートウェイからこの特定のサーバーへの接続 私の背後にあるnatコンピューターからの他のサーバーへの接続 私のコンピューターからこの特定のftpサーバーへの直接インターネット接続(つまり、natサーバー)を使用せずに) ftpを提供している会社は、私がnatサーバーから接続できるので、問題は彼らの側ではないと言います。同じ理由で、問題は私の側にもありません(私は接続できます)他のftpサーバー)何を確認すればよいですか?編集:これは、natの背後にあるコンピューターから接続しようとしているときに、ゲートウェイで接続をスニッフィングしたときに得られるものです:インターネットに面したインターフェース: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- そして私の内部lanインターフェース上: 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, このcrcの問題が発生している理由について何か考えはありますか?ところで、これが私のmtu設定(ゲートウェイ上)であり、それらは私のコンピューター上でも同じです。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 そして、これが私のコンピューターでのmtu分析です: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. telnetを使用して接続しようとすると、次のようになります。220- connection to host lost. press any key to continue...
回答: natゲートウェイのftpアプリケーションプロキシは、「220-」マルチライン応答コードで中断しているようです。ftp応答コードは通常すべて1行ですが、番号の後の「-」は、出力の行がさらに来ることを示します。私はこれが以前に起こったことを見たことがあります-私の場合、それはpixファイアウォールでした。一部のftpサーバーは、ログインパスワードの前に「-」を付けることで、複数行の応答を送信しないように指示できることを思い出しているようです。[〜#〜] edit [〜#〜] =ただし、この場合、ユーザーがログインを試みる前に220-応答が送信されるため、これは修正されません。ftpサーバーの管理者と親しみがある場合は、サーバーのログインバナーを一時的に無効にして、ログインがさらに進むかどうかを確認するように管理者に依頼してください。