это очень связано с этот вопрос относительно GCP, но на AWS, а также пытаемся решить эту проблему другим подходом.
У меня есть FTP-клиент, который пытается подключиться в активном режиме ftp к некоторым ftp-серверам, расположенным в Интернете. У FTP-клиента есть частный адрес, и он находится за сервером экземпляра NAT (не шлюзом NAT).
Этот NAT-сервер также имеет частный адрес и сам находится за VPC Internet GW.
Диаграмма:
FTP-клиент (10.60.0.0/24) -> NAT-сервер (10.254.254.0/24) -> IGW -> Интернет -> Межсетевой экран / NAT -> FTP-серверы
Сервер NAT - это AWS NAT Linux (ядро 4.9) с включенным маскированием.
С Active-FTP (режим порта) это не работает.
Я уже активировал помощник CT FTP (nf_nat_ftp) и его правило запуска iptables:
iptables -A PREROUTING -t raw -p tcp --sport 1024: --dport 21 -j CT --helper ftp
и я вижу, что команда "PORT" правильно переводится с частного IP-адреса FTP-клиента на частный IP-адрес сервера NAT.
К сожалению, этого недостаточно, потому что FTP-сервер получает команду FTP «PORT» с частным адресом (адресом NAT-сервера).
Таким образом, соединение для передачи данных ftp, инициированное с сервера ftp, конечно же, никогда не возвращается.
Я не могу, по крайней мере, сейчас, «заменить» ftp-клиент (это часть устаревшего приложения).
Есть ли способ «вставить» публичный IP в команду PORT? Некоторые идеи приходили мне в голову, но я не мог найти доказательств, реалистичны они или я зря трачу время:
создание «поддельного» интерфейса на сервере nat с общедоступным IP-адресом и выборочное включение / отключение помощника CT для изменения команды PORT. Однако у меня проблемы с правильной маршрутизацией для этого (не говоря уже о том, чтобы убедить себя, что стоит попробовать)
изменение вспомогательного модуля nf_nat_ftp с жестко заданным общедоступным IP-адресом (так уродливо!)
изменение команды порта на ftp-клиенте (это машина с Windows), не знаю, существует ли уже драйвер / инструмент для этой цели
грубое исправление ftp-клиента (может быть, самый реалистичный способ ...?)
О варианте 3: пробовал NETSED, который на самом деле может изменить команду PORT, но это, похоже, испортило нат для ftp-клиента! :(
Разумеется, приветствуются другие решения!
Спасибо.
Пытаюсь ответить на свой вопрос в ограниченном варианте использования
Ограничение: только 1 ftp-клиент в активном режиме за нат-сервером (с маскарадингом не работает)
Сначала запустите netsed на сервере nat, локальный порт 21, преобразуя все пакеты, содержащие «PORT 10,60,10,11», в «PORT 1,2,3,4» (при этом номера портов остаются неизменными):
./netsed tcp 21 0 0 s/PORT%2010,60,10,11,/PORT%201,2,3,4,
Во-вторых, перенаправьте трафик с ftp-клиента на netsed:
iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to 21
Это сделает ftp-сервер «счастливым», и он будет эффективно пытаться открыть новое соединение с порта 20 на публичный IP. IGW пропустит, но сервер NAT не знает, как обрабатывать соединение (это не в CT, это новое соединение).
Так, как бы уродливо это ни было, теперь перенаправляем весь входящий трафик с порта 20 на внутренний FTP-клиент:
iptables -t nat -A PREROUTING -p tcp -d 10.254.254.203 --sport 20 --dport 1024:65535 -j DNAT --to-destination 10.60.10.11:1024-65535
Это работает !!
Но, отчасти из-за взлома, похоже, что он ограничен только одним ftp-клиентом.
Благодарим @Steffen за то, что он указал, что состояние CT не было установлено.
Есть ли способ «вставить» публичный IP в команду PORT?
Даже если бы это было возможно, это не помогло бы. Хотя сервер, вероятно, примет команду PORT с общедоступным IP-адресом, он не сможет подключиться обратно к FTP-клиенту, используя этот IP-адрес и порт, поскольку в IGW нет соответствующего состояния NAT.
Если у вас есть два NAT, как в вашем случае (сервер NAT и IGW), тогда оба из них должны будут преобразовать адрес в команде PORT и создать государство для передачи соединения с сервера на вновь установленный IP, порт на IP, порт из исходной команды PORT.
Я действительно рекомендую отказаться от FTP и использовать альтернативы, которые не нуждаются в динамических подключениях к данным, как это делает FTP. Такие динамические соединения создают проблемы только в том случае, если один из шлюзов NAT не сможет преобразовать PORT / PASV - возможно, из-за отсутствия помощника FTP или из-за того, что вы используете FTPS (то есть FTP с TLS), где шлюз NAT даже не будет иметь возможность видеть исходный IP-адрес и порт, а также не может изменять управляющее соединение по мере необходимости. Вместо этого используйте такие протоколы, как SFTP (FTP через SSH), у которых нет проблем с NAT, поскольку они используют только одно TCP-соединение.