Активный режим FTP и NAT с частной адресацией (AWS)
это очень похоже на этот вопрос относительно 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 клиент (я t является частью устаревшего приложения).
Есть ли способ «ввести» общедоступный IP-адрес в команду PORT? Некоторые идеи приходили мне в голову, но я не мог найти доказательств, реалистичны они или зря трачу время:
создание «фальшивого» интерфейса на сервере nat с публичным IP-адресом и выборочное включение / отключение CT помощник для изменения команды PORT. Однако у меня проблемы с правильной маршрутизацией для этого (не говоря уже о том, чтобы убедить себя, что стоит попробовать)
изменение вспомогательного модуля nf_nat_ftp с жестко заданным общедоступным IP-адресом (так уродливо!)
изменение команды порта на ftp-клиенте (это машина Windows), не знаю, существует ли уже драйвер / инструмент для этой цели
грубое исправление ftp-клиента (может быть, наиболее реалистичный способ ...?)
О варианте 3: I попробовал NETSED , , который на самом деле может изменить команду PORT , но, похоже, испортил нат для ftp-клиента! : (
Другие решения, конечно, приветствуются!
Спасибо.
Пытаюсь ответить на свой вопрос в ограниченном варианте использования
Ограничение: только 1 клиент ftp в активном режиме за сервером nat (он не работает с маскарадингом )
- ftp-клиент: 10.60.10.11
- nat server: 10.254.254.203
- public ip: 1.2.3.4
Сначала запустите 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-соединение.