Наш пакет приложений включает в себя платформу закупок, которая передает заказы на закупку через FTP десяткам поставщиков. До сих пор это приложение работало на одном сервере, поэтому эти FTP-передачи исходили с одного IP-адреса. За эти годы многие поставщики внесли этот один IP-адрес в белый список в своих внутренних сетях. Наша инфраструктура растет, и нам необходимо размещать этот аспект нашего приложения на более чем одном сервере, и поэтому FTP-передачи будут отправляться этим поставщикам с новых IP-адресов. Мы опасаемся, что если мы сделаем этот шаг, передачи начнут прерываться, поскольку передачи будут отклоняться брандмауэрами поставщиков и т. д. Если это возможно, мы хотели бы избежать координации такого рода шагов с каждым поставщиком из-за количества поставщиков и различной надежности их ИТ-ресурсов.
В настоящее время мы изучаем FTP-прокси, но мне было интересно, какие еще варианты у нас могут быть. Я уверен, что есть и другие магазины SaaS, которые сталкивались с похожими проблемами, и мне бы хотелось услышать, как они к ним подошли.
Спасибо!
решение1
Если вы настроите свой брандмауэр на NAT для всех серверов на один IP-адрес, вы сможете сохранить один публичный IP-адрес, но размещать сервисы на нескольких FTP-серверах. Вы бы сделали это с помощью Dynamic NAT в cisco:
access-list DNAT-FTP permit <first ip> <subnet>
access-list DNAT-FTP permit <second ip> <subnet>
access-list DNAT-FTP permit <...> <...>
access-list DNAT-FTP permit <last ip> <subnet>
static (DMZ,outside) <ip to nat to> access-list DNAT-FTP
решение2
Честно говоря, я бы просто стиснул зубы. Вы же не хотите вечно полагаться на свое старое адресное пространство.
Начните тестирование с вашими поставщиками из нового адресного пространства как можно раньше. Вам не нужно будет имитировать что-то большее, чем вход в систему и список каталогов, если вас беспокоит белый список IP.
Возьмитесь за дело поставщиков, которые явно провалили тесты. Сообщите остальным об изменении, даже если тест прошел успешно. Когда вы будете довольны тем, что все тесты пройдены, вы можете приступить к перенумерации.
Мы сами являемся SaaS-магазином. Но разница в том, что мы закупаем адресное пространство PI напрямую у RIR и на самом деле не имеем никаких процессов, которые вы описываете.
Это может быть уместно, если вы указали отношения между поставщиками, вашими клиентами и вами самими. Например, это может быть немного сложнее, если контракт на обслуживание заключается по доверенности ваших клиентов, так как это потребует от них отслеживать запросы на изменения от вашего имени. Однако, если вы профессионально ясно дадите понять, что изменения должны быть выполнены вовремя, чтобы вы могли предоставить клиентам тот уровень обслуживания, которого они ожидают, то никаких проблем возникнуть не должно.
решение3
Одним из возможных решений может быть предоставление вашего сервиса клиентам через VPN-туннели. Это потребует изменений, но как только вы реализуете туннель, вы сможете вносить изменения на стороне сервера по своему желанию.
решение4
Если сервер работает на базе Linux, вы можете использовать iptables для NAT в качестве другого внешнего IP-адреса.