ftp-доступ из частной подсети AWS VPC за экземпляром NAT

Question

Я создал VPC с публичными и частными подсетями на AWS. Все серверы приложений находятся в частных подсетях, и все исходящие запросы должны выполняться через экземпляр NAT с доступом в Интернет.

На данный момент для нашего проекта требуется, чтобы серверы приложений получали доступ к ftp-серверу, предоставленному поставщиком услуг.

Я пробовал несколько способов управлять этим, но все не повезло. Я сделал, чтобы открыть диапазон портов, скажем (40000 - 60000), как для групп безопасности NAT, так и для APP, а также стандартных портов ftp 20-21.

Аутентификация пользователя может быть передана, но я не смог отобразить содержимое с серверов приложений.

Я могу получить доступ к ftp-серверу из NAT, а не к проблеме вообще.

Итак, что мне делать, чтобы заставить его работать?

Answer 1

Попробуйте использовать Пассивный (PASV) режим на FTP.

От Slacksite: Active FTP vs. Passive FTP, a Definitive Explanation:

В активном режиме FTP клиент соединяется со случайным непривилегированным порта (N> 1023) в командном порт FTP-сервере, порт 21. Затем, клиент начинает слушать порт N + 1 и отправляет команду FTP PORT N + 1 на FTP-сервер. Затем сервер подключится к указанному порту данных клиента из своего локального порта данных, который является портом 20.

Таким образом, трафик пытается связываться на дополнительном порту, который не передается через NAT. Пассивный режим вместо этого создает исходящее соединение, которое затем будет разрешено через NAT

Answer 2

@JohnRotenstein абсолютно прав, если вы можете использовать Passive FTP. Если, как и я, вы застряли с клиентом, который настаивает, что вы используете Active FTP, потому что их FTP-сайт, с которым они хотят подключиться, работает с 1990 года, и теперь его изменение совершенно необоснованно, а затем читайте дальше.

Серверы NAT AWS не поддерживают машину в частной подсети, подключаясь с помощью активного FTP. Полная остановка. Если вы спросите меня, это ошибка, но если вы спросите поддержку AWS, они скажут, что это неподдерживаемая функция.

Решение, которое мы наконец придумали (и это работает) заключается в следующем:

• Добавить интерфейс Эластичные сети (ENI) в публичной подсети на к экземпляру EC2 в частной подсети
  • Так что теперь ваш экземпляр EC2 имеет 2 сетевых адаптера, 2 внутренних IP-адресов и т.д.
  • Давайте назовем этот новый ENI ваш «публичный ENI»
• Прикрепление выделенный эластичный IP для вашего нового пользователя ENI
  • Предположим, вы получили 54.54.54.54, а новый внутренний IP-адрес ENI - 10.1.1.10

• Добавить маршрут в сетевой конфигурации операционной системы, чтобы использовать только новый общественный ENI

  • В окнах, the command будет выглядеть следующим образом, предполагая, что злой активный сервер передачи файлов вы пытаетесь подключиться, в 8.1.1.1:

    route add 8.1.1.1 mask 255.255.255.254 10.1.1.1 metric 2 
    

  • Это добавляет маршрут для всего трафика на FTP-сервер в 8.1.1.1, используя маску подсети 255.255.255.254 (т.е. этот IP и только т. его IP) должны идти в Интернет шлюз 10.1.1.1, используя сетевой адаптер 2 (ваш второй NIC)

• ФРС еще до? Да, я тоже, но теперь наступает сложная часть. ОС не знает, что это общедоступный IP-адрес для публичного EIN. Поэтому вам нужно научить вашего FTP-клиента отправлять команду PORT с открытым IP-адресом. Например, если с помощью CURL, используйте команду --ftp-порт так:

  curl -v --ftp-port 54.54.54.54 ftp://8.1.1.1 --user myusername:mypass 
  

И вуаля! Теперь вы можете подключиться к активному FTP-сайту с кошмаром с компьютера EC2, который (почти полностью) находится в частной подсети.