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...
通過するテキストのほんの少しは、それが何らかのMTUの問題である可能性があることを示唆しています。前進するための最良の方法は、ゲートウェイにWiresharkをインストールし、FTP接続に関連するすべてのトラフィックをキャプチャすることです。大きなパケットが複数回送信されている場合は、MTUです。それ以外の場合は、トレースをどこかに貼り付けてください。明確でない場合は、誰かがそれを解釈できます。
ちなみに、CRCの問題は通常、ハードウェアのNIC）で直接行われたチェックサムによって引き起こされます。OSスタックはチェックサムを正しく認識しなくなります。
ネットワークカードのプロパティを開いて、あらゆる種類のオフロードを無効にしてみてください。これらのメッセージが削除されます。
更新：
ログをさらに分析すると、受信されていないように見えるパケットの長さはわずか166バイトです（LANインターフェイスで何度も再送信されるのは「Bienvenue」です）。ここではMTUの問題だと思います。サーバーがすべてのパケットを送信するため、auth/identではないようです。 CRCエラーが含まれているのは最初のものですが。
内部NICですべてのハードウェアアクセラレーション（オフロード）を無効にしてみてください。それでも問題が解決しない場合は、最終的には外部NICでも無効にしてください。一度に1つの潜在的な原因を有効にするためにトラブルシューティングを行う場合、固定速度とデュプレックスを使用することも非常に便利です（10 /半二重が適切な開始です）。それが機能する場合は、問題がどこにあるかを特定できるように、1つずつ再度有効にします。
何も機能しない場合は、FTP-NATingソフトウェアに問題がある可能性があります。FTPは、NAT（通常はここではありません）を介して機能するためにマングルする必要があるプロトコルです。FTPを使用してみてください。 -プロキシ（レイヤー7）ソフトウェア。それが機能する場合は、FTP専用のように見えるため、回避策があります。
NATゲートウェイのFTPアプリケーションプロキシは、「220-」マルチライン応答コードで中断しているようです。
FTP応答コードは通常すべて1行ですが、番号の後の「-」は、出力の行がさらに来ることを示します。
私はこれが以前に起こったことを見たことがあります-私の場合、それはPIXファイアウォールでした。
一部のFTPサーバーは、ログインパスワードの前に「-」を付けることで、複数行の応答を送信しないように指示できることを思い出しているようです。[〜＃〜] edit [〜＃〜] =ただし、この場合、ユーザーがログインを試みる前に220-応答が送信されるため、これは修正されません。
FTPサーバーの管理者と親しみがある場合は、サーバーのログインバナーを一時的に無効にして、ログインがさらに進むかどうかを確認するように管理者に依頼してください。
私のオフィスでもIPtablesで同じ厄介な問題が発生していると思いますが、それが発生することがわかっていて、修正したくない場合を除きます。
着信トラフィックをブロックしているポートを確認すると役立つ場合があります。 FTPは着信接続に21しか使用しないと確信しています（つまり、何かに接続することはできますが、ディレクトリに接続することはできません）。
返されるポートはネゴシエート可能であると確信しているので、可能であればFTPを廃棄し、この場合はSFTPを使用することをお勧めします。
Windowsコマンドラインftpでdebugコマンドを使用してみてください。おそらく、解決策につながるいくつかの追加情報が表示されます。
FTPサーバー（proftpd）が機能する方法は、ポート21で接続をリッスンするであり、*接続されると、接続を60000の範囲**（proftpd.confで-として設定）までバンプします。 PassivePorts）
NATは元々ポート21のみをFTPサーバーに転送するように設定されていましたが、表示されているものと同様の動作が見られました。
PassivePortsを特定の範囲に制限する、およびその範囲を転送する NAT構成で、問題を解決しました。
もちろん、それはサーバー側の観点から
ただし、すべてのポートを一時的にNATし、問題が解決するかどうかを確認することで、簡単にテストできます。
患者：医者、医者！お茶を飲むと、目に刺すような痛みがあります。
医師：スプーンをカップから取り出してみてください！
重要なのは、なぜサーバーをNATゲートウェイとして使用しているのですか？モデム/ルーターはそれを行わないのですか？サーバーをパスから外してみませんか？