web-dev-qa-db-ja.com

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...
4
Brann

通過するテキストのほんの少しは、それが何らかのMTUの問題である可能性があることを示唆しています。前進するための最良の方法は、ゲートウェイにWiresharkをインストールし、FTP接続に関連するすべてのトラフィックをキャプチャすることです。大きなパケットが複数回送信されている場合は、MTUです。それ以外の場合は、トレースをどこかに貼り付けてください。明確でない場合は、誰かがそれを解釈できます。

3
womble

ちなみに、CRCの問題は通常、ハードウェアのNIC)で直接行われたチェックサムによって引き起こされます。OSスタックはチェックサムを正しく認識しなくなります。

ネットワークカードのプロパティを開いて、あらゆる種類のオフロードを無効にしてみてください。これらのメッセージが削除されます。

更新:

ログをさらに分析すると、受信されていないように見えるパケットの長さはわずか166バイトです(LANインターフェイスで何度も再送信されるのは「Bienvenue」です)。ここではMTUの問題だと思います。サーバーがすべてのパケットを送信するため、auth/identではないようです。 CRCエラーが含まれているのは最初のものですが。

内部NICですべてのハードウェアアクセラレーション(オフロード)を無効にしてみてください。それでも問題が解決しない場合は、最終的には外部NICでも無効にしてください。一度に1つの潜在的な原因を有効にするためにトラブルシューティングを行う場合、固定速度とデュプレックスを使用することも非常に便利です(10 /半二重が適切な開始です)。それが機能する場合は、問題がどこにあるかを特定できるように、1つずつ再度有効にします。

何も機能しない場合は、FTP-NATingソフトウェアに問題がある可能性があります。FTPは、NAT(通常はここではありません)を介して機能するためにマングルする必要があるプロトコルです。FTPを使用してみてください。 -プロキシ(レイヤー7)ソフトウェア。それが機能する場合は、FTP専用のように見えるため、回避策があります。

2
Steve Schnepp

NATゲートウェイのFTPアプリケーションプロキシは、「220-」マルチライン応答コードで中断しているようです。

FTP応答コードは通常すべて1行ですが、番号の後の「-」は、出力の行がさらに来ることを示します。

私はこれが以前に起こったことを見たことがあります-私の場合、それはPIXファイアウォールでした。

一部のFTPサーバーは、ログインパスワードの前に「-」を付けることで、複数行の応答を送信しないように指示できることを思い出しているようです。[〜#〜] edit [〜#〜] =ただし、この場合、ユーザーがログインを試みる前に220-応答が送信されるため、これは修正されません。

FTPサーバーの管理者と親しみがある場合は、サーバーのログインバナーを一時的に無効にして、ログインがさらに進むかどうかを確認するように管理者に依頼してください。

2
Alnitak

私のオフィスでもIPtablesで同じ厄介な問題が発生していると思いますが、それが発生することがわかっていて、修正したくない場合を除きます。

着信トラフィックをブロックしているポートを確認すると役立つ場合があります。 FTPは着信接続に21しか使用しないと確信しています(つまり、何かに接続することはできますが、ディレクトリに接続することはできません)。

返されるポートはネゴシエート可能であると確信しているので、可能であればFTPを廃棄し、この場合はSFTPを使用することをお勧めします。

1
Peter Turner

Windowsコマンドラインftpでdebugコマンドを使用してみてください。おそらく、解決策につながるいくつかの追加情報が表示されます。

0
splattne

FTPサーバー(proftpd)が機能する方法は、ポート21で接続をリッスンするであり、*接続されると、接続を60000の範囲**(proftpd.confで-として設定)までバンプします。 PassivePorts

NATは元々ポート21のみをFTPサーバーに転送するように設定されていましたが、表示されているものと同様の動作が見られました。

PassivePortsを特定の範囲に制限する、およびその範囲を転送する NAT構成で、問題を解決しました。

もちろん、それはサーバー側の観点から

ただし、すべてのポートを一時的にNATし、問題が解決するかどうかを確認することで、簡単にテストできます。

0
Brent

患者:医者、医者!お茶を飲むと、目に刺すような痛みがあります。
医師:スプーンをカップから取り出してみてください!

重要なのは、なぜサーバーをNATゲートウェイとして使用しているのですか?モデム/ルーターはそれを行わないのですか?サーバーをパスから外してみませんか?

0
Tim Long