Люди!!! Ну в чем может быть дело???
Я уже даже стандартный виртуал серв. отрубил - прописал все ручками. Не работает!
Такое ощущение, что пакет по мапленному соединению назад не идет...
Купил я себе WL550gE...купил вообще для Вайфая, но хотел прспособить и под роут тоже.
Втыкаю для теста ноут в ВАН, настраиваю его на статике (роут 192.168.0.1, ноут ...0.2, маска 255.255.255.0). ЛАН - 192.168.175.* на такой же маске.
Ставлю Virtual server стандартными фтп настройками на свой фтп 21й порт.... и все!
Что не делаю - нет коннекта. И файрволл врубал/отрубал и роутов фтп... и порты пробовал менят - ничего!
Сам ФТП по логам пишет коннект, но дисконнект от мгновенного до 30 сек.
IP CONNECT DISCONNECT
192.168.0.2 01/09/2006 19:21:25 01/09/2006 19:21:25
192.168.0.2 01/09/2006 19:20:29 01/09/2006 19:20:50
ФТП - Gene6, клиент - Тотал.
В чем может быть дело?
Люди!!! Ну в чем может быть дело???
Я уже даже стандартный виртуал серв. отрубил - прописал все ручками. Не работает!
Такое ощущение, что пакет по мапленному соединению назад не идет...
В свойствах соединения (в ТС) поставь "use passive mode ... " - через NAT активный FTP не работает.
Попробуй порт смапить 20 еще
А для того, чтобы работал пассивный режим пробрось (порт форвардинг) весь диапазон портов данных пассивного режима (не менее 10).В свойствах соединения (в ТС) поставь "use passive mode ... " - через NAT активный FTP не работает.
Эти же порты также должны быть указаны в настройках FTP сервера.
Проверь, что FTP сервер выдает внешний IP для пассивного режима, а не твой внутренний. Иначе только некоторые (а не любые) FTP клиенты смогут входить на твой сервер (типа SmartFTP с соответствующей галочкой).
Дано:
Роутер Asus WL 500g Premium
Прошивка Олега, pre8. WAN to LAN filter, policy DROP.
DHCP + PPTP, никакие фтп
На роутере нет никаких FTP, все стандартное отключено.
Роутер соединяется с VPN-сервером и получает реальный IP 212.1.x.26 на интерфейс ppp0. Инет при помощи NAT раздается в квартирную сетку 192.168.0.0/24.
Ноутбук с IP 192.168.0.8.
FTP-клиент: Far manager.
Пытаемся соединиться с ftp-сервером ftp.microsoft.com в активном режиме. Соединяемся, успешно получаем листинг директории, файлы etc...
Тем же самым фтп-клиентом пытаемся в активном режиме соединиться с фтп 88.210.60.163
...и НЕ получаем ни листинга, ни всего остального. В чем причина ?
Начинаем думать.
Итак, в активном режиме смотрим что происходит при коннекте с ftp.m$.com.
Включаем сниффер на ноуте... tcpdump -i ppp0 на роутере... и смотрим.
Отправляем пакеты такие:
192.168.0.8:7318 -> ftp.m$.com:21. На роутере они превращаются в
212.1.x.26:7318 -> ftp.m$.com:21
и летят в америку... Ответ с ftp.m$.com на мой внешний ип 212.1.x.26 прилетает
ftp.m$.com:21 -> 212.1.xx.26:7318
Далее dst-IP подменяется(в соответствии с тем, которые есть в сопоставлениях NAT), пакет становится
ftp.m$.com:21 -> 192.168.0.8:7318
Мы передали серверу команду PORT 192,168,0,8,14,178. Это уже уровень приложений, эта команда по пути никем не модифицируется.
Замечательно, авторизация и прочая прелюдия пролетела...
Теперь ftp.m$.com должен постучаться к нам со своего порта 20 на наш порт (14*256)+178=3762.
И действительно...
На роутер прилетает:
ftp.m$.com:20 -> 212.1.xx.26:3762.
====================
Вот здесь у меня возникает резонные теоретические вопросы:
1) Однако, командой PORT ... мы передали серверу 192,168,0,8 ... Почему он стал стучаться на 212.1.x.26 ? Проигнорировал PORT и постучался на SRC-IP ? Или как ?
2) А должен ли этот пакет(ftp.m$.com:20 -> 212.1.xx.26:3762), не имеющий никаких сопоставлений, быть отправлен хосту 192.168.0.8 ? Если и должен, то я не понимаю почему... и откуда роутер узнает какому именно хосту из домашней сетки он предназначен.
====================
Так, или иначе, dst-ip заменяется на 192.168.0.8, пакет становится
ftp.m$.com:20 -> 192.168.0.8:3762 и летит ко мне на ноут... Как и все остальные пакеты. С ftp.microsoft.com к нам прилетел листинг директории и многое другое. Замечательно.
Идем дальше.
В активном режиме смотрим что происходит при коннекте с 88.210.60.163.
Включаем сниффер на ноуте... tcpdump -i ppp0 на роутере... и смотрим.
Авторизация и прочие данные на сервер по dst-порту 21 пролетают аналогично ftp.m$.com. Передаем PORT 192,168,0,8,30,180
Теперь 88.210.60.163 должен постучаться к нам со своего порта 20 на наш порт (30*256)+180=7860.
И действительно...
На роутер прилетает:
ftp.m$.com:20 -> 212.1.xx.26:7860.
====================
...всё те же два вопроса из прошлого пункта.
...тут, наверное, происходит, видимо, что-то еще, о чем я не знаю...
====================
Так, или иначе, dst-ip заменяется на 192.168.0.8, пакет становится
88.210.60.163:20 -> 192.168.0.8:7860 и летит ко мне на ноут...
НО ! Как показывают пакетные снифферы, с этого фтпшника ко мне на ноут пролезает только первый пакет с флагом SYN. Ноут на него отвечает SYN,ACK ... Но на этом все пакеты 88.210.60.163:20 -> 212.1.xx.26:7860 перестают переправляться ко мне на ноутбук...
Вопросы следующий:
1) То, что написано фиолетовым цветом
2) ПОЧЕМУ ? Чего я не понимаю, упускаю из виду и т.п. ?
Помогите, пожалуйста, разобраться.
Last edited by Lesnix; 23-10-2006 at 00:47.
В данном случае как раз модифицируется. Модуль поддержки NAT для FTP (ip_nat_ftp, в данном случае он вкомпилирован в ядро) перехватывает команды PORT и PASV и при необходимости заменяет IP-адрес и порт в них на реальный IP роутера и выбранный свободный порт. При этом оригинальный адрес и порт сохраняются в таблице NAT и используются для переадресации пакетов соединения данных. Именно благодаря этой замене и работает FTP в активном режиме.
Это может быть вызвано неработающим PMTU Discovery из-за того, что кто-то по пути до этого сервера отфильтровал пакеты ICMP с типом Destination Unreachable/Fragmentation Needed (type 3, code 4). Обойти эту проблему можно уменьшением MTU для PPTP-соединения - добавьте в Additional pppd options опцию mtu 1460; если с таким значением не заработает, возможно, придётся ставить ещё меньше.
Вообще mtu 1460 имеет смысл ставить для PPTP почти всегда - без этого получается фрагментация пакетов GRE.
Большое спасибо, как раз вот этого моментика мне и не хватало.
Однако, в таком случае возникает другой вопрос.
Есть у меня в Питере сервер с реальным IP... На нем я проверял "целостность" команды PORT, которая в итоге прилетает на сервер. И прилетало PORT 192,168,0,8,... И именно на основании этого я сделал вывод, что PORT не модифицируется. Однако, кажется, теперь я понимаю в чем дело... Этот мой далекий фтпшник, на который команда долетала в виде PORT 192,168,0,8 ...висит на нестандартном порту. Вероятно, именно поэтому пакеты с ноута на не 21 порт НЕ просматривались роутером на предмет команды PORT для модификации.
Моя "гипотеза" на этот счет верна ?
Что касается фтпшника, который отказался работать в активном режиме (кстати, если я сам ноут сажаю непосредственно на реальный IP(минуя роутер), то этот фтпшник работает).
У меня размер mtu на ppp0 интерфейсе равен 1372. Это общее требование моего провайдера...Это может быть вызвано неработающим PMTU Discovery из-за того, что кто-то по пути до этого сервера отфильтровал пакеты ICMP с типом Destination Unreachable/Fragmentation Needed (type 3, code 4). Обойти эту проблему можно уменьшением MTU для PPTP-соединения - добавьте в Additional pppd options опцию mtu 1460; если с таким значением не заработает, возможно, придётся ставить ещё меньше.
Вообще mtu 1460 имеет смысл ставить для PPTP почти всегда - без этого получается фрагментация пакетов GRE.
Неужели нужно еще меньше, или, возможно, дело не в этом ?
Вообще, если собрать ip_conntrack_ftp и ip_nat_ftp модулями, можно было бы использовать параметр ports для задания нестандартных портов.
Ну и пассивный режим должен работать даже при существующей конфигурации. Либо придётся искать что-то типа socks5-сервера, собранного под этот роутер.
MTU в данном случае, похоже, всё-таки не при чём (хотя проблем с этим тоже хватает).
Разрешите еще вас "помучать", уажаемые.
1) У кого-нибудь еще есть версии относительно вышеописанной ситуации? (почему некоторые фтпшники не работают в активном режиме)
2) Вопрос относительно логичности протокола FTP :
В команде PORT мы передаем нечто вроде
PORT 212,1,x,26,14,178
По сути говоря, это IP и номер порта, куда надо приконнектиться. При этом за номер порта по сути отвечают две последних цифры...
Скажите,
1) Не проще ли было просто передавать одну цифру в явном виде -номер порта и всегда стучаться на IP, с которого идет коннект ?
2) Если я передаю серверу команду PORT <чужой IP>,12,524 - он будет стучаться на этот IP ?
...ни у кого нет желания ответить ?
Отвечать нечегоOriginally Posted by Lesnix
Так сложилось, стандарт де-факто, точнее по RFC . К нему много замечаний.
Заставить FTP-сервер передавать данные на чужой IP изначально было можно - например, чтобы скопировать файл с одного FTP на другой (FXP). Однако в последнее время эта возможность приносит больше вреда, чем пользы (например, таким образом можно использовать FTP-сервер в качестве прокси - FTP bounce attack), поэтому на большинстве серверов указание чужого IP в директиве PORT запрещено.