Уважаемый, dima.
Тема, которую Вы затронули, в общем-то хорошо известна. В Сети очень много публикаций. Несмотря на это, не только Вы, но иногда некоторые начинающие админы имеют неверное представление о том, что и как работает. Здесь я ни в коем случае не хочу сказать что-либо обидное для Вас. Напротив, мне импонируем мягкий, вежливый стиль Вашего предыдущего поста.
То, что Вы с моей точки зрения, мягко говоря, несколько заблуждаетесь – это моя и только моя точка зрения. На этом форуме есть специалисты, которые могут Вам подсказать - что и как. Да, и возможно Вы на самом деле являетесь опытным системным администратором. Как знать?
Главная беда здесь (не только Ваша), в том, что люди пренебрегают «базовыми» понятиями и соответствующей литературой (
RFC). Что и как должно работать в FTP, в частности, тоже там написано. Там самое важное. И важность этого не зависит от того, как на той или иной платформе реализован стек TCP/IP и собственно FTP –сервер и клиент. Я не случайно в своём ответе Vims-у отметил именно
RFC 959.
Если Вы почитаете этот документ внимательно, то к своему удивлению Вы возможно обнаружите, что модель FTP тем и отличается от большинства протоколов прикладного уровня, что
использует два соединения по 21–му серверному порту (соединение управления передачей) и по 20-му порту серверному порту(соединение, собственно для передачи данных).
Об этом собственно и был мой пост Vims-у. То, что Вы говорите в своём посте о достаточности только 21-го порта –
это ложное утверждение.
Вы пишете:
1. as far as I know ftp.exe connect to TCP port 21 only, so if it's close on the FireWall, your connect will failed (from the log you can see that connect succeed).
Но!!! Говоря, что Ваш клиент использует только 21 серверный порт и не использует 20 – порт Вы здесь глубоко заблуждаетесь. Действительно управляющее соединение устанавливается по 21-му порту. И Вы правильно пишите, что если закрыть 21-порт на серверной стороне, то ни о какой передаче не может быть и речи. Но то, что FireWall
в момент передачи позволяет Вам отправлять пакеты на 20-порт (и получать пакеты с этого порта) – это всё скрыто в конфигах Вашего FireWall. Загляните в них, и возможно Вы сразу найдёте ответ. Если нет возможности посмотреть конфиг – посмотрите логии Вашего трафика. Там непременно найдётся 20-й порт, если только Вы передавали данные. Если будете анализировать трафик, то обратите внимание, что соединения по 20-му порту существуют только в периоду «перекачки» (затем соединения закрываются), в то время, как управляющее соединение по 21-му порту - существует на протяжении всего сеанса.
Я понимаю, что поскольку я сослался только на RFC (
я действительно считаю RFC- главными документами) у Вас могут возражения, что, дескать, в «практике» это все может быть и не так. Я Вас уверяю, что так. Вот посмотрите на конфигурации прокси от Майкрософт (там два варианта, когда ftp «на» и «за прокси»). Надеюсь, Майкрософт-то Вы доверяете:
1) Co-locating FTP services with Proxy
FTP Server IN (Filter 1 of 2)
Protocol = TCP
Direction = IN
Local Port = 21
Remote Port = Any
FTP Server OUT (Filter 2 of 2)
Protocol = TCP
Direction = BOTH
Local Port = 20
Remote Port = Any
FTP Server Dynamic (Optional)
Protocol = TCP
Direction = BOTH
Local Port = Dynamic port (1025-5000)
Remote Port = Any
2) Ftp за MS Proxy Server 2.0
DIR PROTOCOL LOCAL PORT REMOTE PORT LOCAL ADDRESS REMOTE ADDRESS
In TCP 21 Any Default Any
Both TCP 20 Any Default Any
Дополнительную литературу по конфигурации прокси для работы с FTP вы можете найти здесь:
Q236001
Microsoft Knowledge Base Article – 236001
Err Msg: 425 Can't Open Data Connection
.. to allow FTP port 20 to be bound to the external interface…
Q174785
Microsoft Knowledge Base Article – 174785
Common Packet Filters
FTP Server IN (Filter 1 of 2)
Protocol = TCP
Direction = IN
Local Port = 21
Remote Port = Any
FTP Server OUT (Filter 2 of 2)
Protocol = TCP
Direction = BOTH
Local Port = 20
Remote Port = Any
Вы можете возразить, что, мол, прокси это не ещё не «настоящий» FireWall, да и технология прокси, существенно отличается, например, от NAT. Но тогда посмотрите вот это (это тоже от Майкрософт) про NAT:
Q254018
How to Configure Input Filters for Services That Run Behind Network Address Translation
Client External File Transfer Protocol (FTP) Access
Use the following configuration if you want to enable internal clients to connect to FTP servers on the Internet:
Source 0.0.0.0 Protocol TCP Source Port 21
Source 0.0.0.0 Protocol TCP Source Port 20
FTP Server Access
Use the following configuration if you run a FTP server on the NAT computer and want it to be accessible to Internet users:
Source 0.0.0.0 Protocol TCP Destination Port 21
Source 0.0.0.0 Protocol TCP Destination Port 20
Вы можете возразить, что Майкрософт-майкрософтом. А на других платформах как?
Точно также. Например, прочитайте вот эту статью (или выдержку из неё ниже).
http://info.krc.karelia.ru/unix/FreeBSD/ipfw/ipfw.shtml
Настройка роутера на базе FreeBSD
# Разрешаем работу с FTP серверами
# Обратите внимание что 20 порт протокола TCP используется для
# передачи данных, помимо 21 порта.
${fwcmd} add pass tcp form any 21 to any
${fwcmd} add pass tcp from any to any 21
${fwcmd} add pass tcp from any 20 to any
${fwcmd} add pass tcp from any to any 20
Сразу скажу, чтобы не навредить Вам, что приведённый выше фрагмент ACL для FreeBSD – очень примитивен. И его, конечно, не стоит непосредственно использовать в реальной ситуации. Но фрагмент этого ACL позволяет понять - что и как.
Напоследок приведу Вам реальный трафик, который я записал при попытке «качнуть» файл readme.txt c ftp.microsoft.com. Вначале приводятся команды ftp-клиента (чтобы Вам было понятно, что я там делал), а затем, собственно, фрагмент лога с пояснениями.
C:\>ftp
ftp> open ftp.microsoft.com
Connected to ftp.microsoft.com.
220 Microsoft FTP Service
User (ftp.microsoft.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230-This is FTP.Microsoft.Com
230 Anonymous user logged in.
ftp> cd developr
250 CWD command successful.
ftp> get readme.txt
200 PORT command successful.
150 Opening ASCII mode data connection for readme.txt(1427 bytes).
...
...
open ftp.microsoft.com - активно соединяемся
9/30/2003, 17:41:19, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, SYN
9/30/2003, 17:41:21, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, SYN ACK
9/30/2003, 17:41:21, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
начинаем говорить о паролях и других глупостях
здесь же делаем
ftp> cd developr
9/30/2003, 17:41:23, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:41:23, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:41:27, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, PSH ACK
9/30/2003, 17:41:28, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:41:28, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:41:37, x.y.w.z, 195.133.115.11, Tcp, 65074, 25, ACK
9/30/2003, 17:41:41, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, PSH ACK
9/30/2003, 17:41:42, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:41:42, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:41:44, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:41:44, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:41:58, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, PSH ACK
9/30/2003, 17:42:00, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, ACK
9/30/2003, 17:42:00, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:42:00, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:42:20, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, PSH ACK
9/30/2003, 17:42:21, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:42:21, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, PSH ACK
9/30/2003, 17:42:23, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:42:23, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
Пытаемся качнуть файл readme.txt
ftp> get readme.txt
200 PORT command successful.
150 Opening ASCII mode data connection for readme.txt(1427 bytes).
9/30/2003, 17:42:26, 207.46.133.140, x.y.w.z, Tcp,
20, 65142, SYN
9/30/2003, 17:42:26, x.y.w.z, 207.46.133.140, Tcp, 65142,
20, SYN ACK
9/30/2003, 17:42:27, 207.46.133.140, x.y.w.z, Tcp,
20, 65142, PSH ACK
9/30/2003, 17:42:27, x.y.w.z, 207.46.133.140, Tcp, 65142,
20, ACK
Здесь в четырёх строках выше создано TCP-соединение, собственно для передачи
файла с 20-го порта сервера мелкософта
9/30/2003, 17:42:28, x.y.w.z, 207.46.133.140, Tcp, 65142,
20, RST
Упс... Провода плохие. Возвращаемся к управляющему соединению.
9/30/2003, 17:42:29, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:42:29, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:43:40, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, PSH ACK
9/30/2003, 17:43:40, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:43:46, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, FIN PSH ACK
9/30/2003, 17:43:46, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, ACK
9/30/2003, 17:43:46, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, FIN ACK
9/30/2003, 17:43:51, x.y.w.z, 207.46.133.140, Tcp, 65134, 21, FIN ACK
9/30/2003, 17:44:03, 207.46.133.140, x.y.w.z, Tcp, 21, 65134, ACK
До свидания... (это про трафик)
А Вам всего хорошего.
