Наш пакет приложений включает платформу закупок, которая передает заказы на закупку через FTP десяткам поставщиков. До сих пор это приложение работало на одном сервере, поэтому FTP-передачи исходили с одного IP-адреса. На протяжении многих лет многие поставщики вносили этот IP-адрес в белые списки своих внутренних сетей. Наша инфраструктура растет, и нам необходимо разместить этот аспект нашего приложения более чем на одном сервере, поэтому передачи по FTP будут отправляться этим поставщикам с новых IP-адресов. Мы опасаемся, что если мы сделаем этот шаг, передачи начнут отказываться, поскольку передачи запрещены брандмауэрами поставщиков и т. Д. Если возможно, мы хотели бы избежать координации такого рода действий с каждым поставщиком из-за количества поставщиков и разная надежность их ИТ-ресурсов.
В настоящее время мы изучаем FTP-проксирование, но мне было интересно, какие еще варианты у нас могут быть. Я уверен, что есть другие магазины SaaS, которые сталкивались с подобными проблемами, и мне бы хотелось услышать, как они к ним подошли.
Спасибо!
Если вы настроите свой брандмауэр на 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
Честно говоря, я бы просто стиснул зубы. Вы не хотите вечно полагаться на свое старое адресное пространство.
Начните тестирование с вашими поставщиками из нового адресного пространства как можно раньше. Вам не нужно имитировать ничего, кроме входа в систему и списка каталогов, если вас беспокоит белый список IP.
Разберитесь с поставщиками, которые явно не прошли тесты. Сообщите остальным об изменении, даже если тест прошел успешно. Когда вы будете счастливы, что все тесты пройдены, вы можете продолжить перенумерацию.
Мы сами являемся магазином SaaS. Но разница в том, что мы сами закупаем адресное пространство PI непосредственно у RIR и на самом деле не имеем никаких процессов, как вы описываете.
Это может быть актуально, если вы укажете отношения между продавцами, вашими клиентами и вами. Например, было бы немного сложнее, если бы контракт на обслуживание был заключен через доверенное лицо ваших клиентов, поскольку это потребовало бы от них отслеживания запросов на изменение от вашего имени. Однако если вы профессионально проясните, что изменения должны быть внесены вовремя, чтобы вы могли предоставить клиентам уровень обслуживания, на который они рассчитывают, то проблем возникнуть не должно.
Одним из возможных решений может быть предоставление ваших услуг клиентам через туннели VPN. Это потребует изменений, но как только вы реализуете туннель, вы сможете вносить изменения на стороне сервера по своему желанию.
Если сервер Linux, вы можете использовать iptables для nat в качестве другого внешнего IP-адреса.