我們的應用程式套件包括一個採購平台，可透過 FTP 將採購訂單傳輸給數十家供應商。到目前為止，該應用程式運行在一台伺服器上，因此這些 FTP 傳輸源自於一個 IP 位址。多年來，許多供應商已將其內部網路上的這個 IP 位址列入白名單。我們的基礎設施正在不斷發展，我們需要在多個伺服器上託管我們的應用程式的這一方面，因此 FTP 傳輸將從新的 IP 位址發送到這些供應商。我們擔心的是，如果我們採取這一舉措，傳輸將開始失敗，因為傳輸被供應商的防火牆等拒絕。資源的可靠性各不相同。
我們目前正在研究 FTP 代理，但我想知道我們還有哪些其他選擇。我確信我們那裡還有其他 SaaS 商店也遇到類似的問題，我很想聽聽他們是如何解決這些問題的。
謝謝！
答案1
如果您將防火牆設定為將所有伺服器 NAT 到一個 IP 位址，您將能夠保留單一面向公眾的 IP，但將服務託管在多個 FTP 伺服器上。您可以使用 cisco 中的動態 NAT 來執行此操作：
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 商店。但不同之處在於，我們自己直接從 RIR 取得 PI 位址空間，並且實際上沒有任何像您描述的過程。
如果您說明了供應商、您的客戶和您自己之間的關係，這可能是相關的。例如，如果服務合約是由您的客戶代理簽訂的，則可能會有點棘手，因為這需要他們代表您追蹤變更要求。但是，如果您專業地明確表示必須按時完成更改，以便為客戶提供他們期望的服務水平，那麼就不會有任何問題。
答案3
潛在的解決方案可能是透過 VPN 隧道向客戶端提供服務。這需要進行更改，但是一旦實現了隧道，您就可以隨意進行伺服器端更改。
答案4
如果伺服器是Linux，可以使用iptables將nat作為另一個外部IP位址。