FTP-сервер не может выполнить рукопожатие SSL (VSFTPD)

Question

Я пытаюсь настроить доступный через Интернет FTP-сервер с шифрованием, используя VSFTPD в качестве серверной программы на Fedora 25. Несмотря на правильную настройку, я не могу подключиться к серверу вне локальной сети, когда включено шифрование. Однако подключение возможно, если я отключаю шифрование или подключаюсь из локальной сети.

У меня проблема в том, что сервер VSFTPD не может завершить рукопожатие SSL после получения команды AUTH от клиента. Используя 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
...

Другая информация: у меня есть VSFTPD, настроенный для использования TLSv1 или выше, для работы в пассивном режиме и с явным FTPS, и с самозаверяющим сертификатом RSA. Я не думаю, что есть проблема с моим сертификатом, так как я могу использовать тот же сертификат для размещения сервера https с httpd, к которому я могу получить доступ из-за пределов локальной сети. Так что проблема должна быть как-то связана с ВСФТПД.

Я также настроил свой маршрутизатор и брандмауэр на переадресацию и прием 21 порта для соединений через порт управления ftp. Я также настроил VSFTPD на использование порта 2048 в качестве единственного порта данных PASV, но по какой-то причине мне не нужно было переадресовывать этот порт на моем маршрутизаторе, чтобы разрешить работу незашифрованных FTP-подключений ... и, кроме того, моя ошибка во всяком случае, происходит до того, как порт данных подключается.

У кого-нибудь есть идеи как это исправить? Есть ли что-то очевидное, что я здесь скучаю?

Answer 1

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 от клиента на этот ответ и, следовательно, он ретранслирует его, то есть обычное поведение соединений TCP при пропущенном ACK.

Вопрос в том, почему сервер не получает ACK. Из вашего вопроса не ясно, был ли захват пакета выполнен на стороне клиента или сервера, но я предполагаю, что это было сделано на стороне сервера. В этом случае я думаю, что между клиентом и сервером существует некоторый межсетевой экран, который вмешивается в соединение:
Поскольку FTP - это протокол с динамическими портами для передачи данных, и эти динамические порты обмениваются внутри управляющего соединения, брандмауэр должен иметь доступ к управляющему соединению в открытом виде, чтобы выяснить, какие динамические порты используются, и открыть эти порты. Если управляющее соединение зашифровано (AUTH TLS), это больше невозможно, поэтому некоторые брандмауэры пытаются явно или непреднамеренно заблокировать использование TLS. И то, что вы видите, может быть результатом этого.