web-dev-qa-db-ja.com

FTPサーバーがSSLハンドシェイク（VSFTPD）を完了できない

Fedora 25で、サーバープログラムとしてVSFTPDを使用して、暗号化を使用してインターネットにアクセス可能なFTPサーバーをセットアップしようとしています。すべてが正しくセットアップされているように見えますが、暗号化が有効になっていると、LANの外部からサーバーに接続できません。ただし、暗号化を無効にしたり、LAN内から接続したりすると接続は可能です。

私が抱えている問題は、クライアントからAUTHコマンドを受信した後、VSFTPDサーバーがSSLハンドシェイクを完了できないことです。 Wiresharkを使用すると、サーバーがハンドシェイク応答のように見えるものを数回送信しようとしていることがわかります。

それが役立つ場合は、サーバーに接続しようとしているクライアントに関するWiresharkのレポートを次に示します。

From    Info
------  ----
Client  64423 → 21 [ACK] Seq=1 Ack=1 Win=13952 Len=0 TSval=996262 TSecr=3062736173
Server  Response: 220 (vsFTPd 3.0.3)
Client  64423 → 21 [ACK] Seq=1 Ack=21 Win=13952 Len=0 TSval=996281 TSecr=3062736371
Client  Request: AUTH TLS
Server  21 → 64423 [ACK] Seq=21 Ack=11 Win=29056 Len=0 TSval=3062736436 TSecr=996282
Server  Response: 234 Proceed with negotiation.
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062736822 TSecr=996282
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
...

その他の情報：TLSv1以降を使用し、パッシブモードで明示的なFTPSを使用し、自己署名RSA証明書を使用するようにVSFTPDを構成しました。同じ証明書を使用してhttpdでhttpsサーバーをホストできるため、証明書に問題はないと思います。これは、LANの外部から問題なくアクセスできます。したがって、問題は何らかの形でVSFTPDに関連している必要があります。

また、ルーターとファイアウォールを、ftp制御ポート接続用にポート21を転送して受け入れるように設定しました。また、VSFTPDを唯一のPASVデータポートとしてポート2048に設定しましたが、何らかの理由で、暗号化されていないFTP接続を機能させるためにルーターでそのポートを転送する必要はありませんでした...さらに、私が抱えている失敗はとにかく、データポートが関与する前に発生します。

誰かがこれを修正する方法について何か考えがありますか？私がここで見逃している明らかな何かがありますか？

ftpsslvsftpdftps
1
mr_johnson22
Server  Response: 234 Proceed with negotiation.
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062736822 TSecr=996282

表示されるのはTLSハンドシェイクではありません。 TLSハンドシェイクはクライアントによって開始されますが、ここではそうではありません。代わりに表示されるのは、サーバーの最後の応答の再送信です。つまり、234 Proceed with negotiation.\r\nこれは正確に31バイトです。
これは、サーバーがこの応答に対してクライアントからACKを受信しないため、サーバーが再送信していることを意味します。つまり、ACKが欠落している場合のTCP接続の一般的な動作）。

問題は、サーバーがACKを受信して​​いない理由です。パケットキャプチャがクライアント側で行われたのかサーバー側で行われたのかはあなたの質問からは明らかではありませんが、サーバー側で行われたと思います。この場合、クライアントとサーバーの間に接続を改ざんするファイアウォールがあると思います。
FTPはデータ転送用の動的ポートを備えたプロトコルであり、これらの動的ポートは制御接続内で交換されるため、ファイアウォールは、どの動的ポートが使用されて開かれているかを確認するために、制御接続へのクリアテキストアクセスが必要です。これらのポート。制御接続が暗号化されている場合（AUTH TLS）、これは不可能になっているため、一部のファイアウォールは、TLSの使用を明示的または不注意にブロックしようとします。そして、あなたが見るものはこれの結果かもしれません。

1
Steffen Ullrich