당사의 애플리케이션 제품군에는 FTP를 통해 구매 주문서를 수십 개의 공급업체에 전송하는 조달 플랫폼이 포함되어 있습니다. 지금까지 이 애플리케이션은 하나의 서버에서 실행되었으므로 이러한 FTP 전송은 하나의 IP 주소에서 시작되었습니다. 수년에 걸쳐 많은 공급업체가 내부 네트워크에서 이 IP 주소를 화이트리스트에 추가했습니다. 우리의 인프라는 성장하고 있으며 하나 이상의 서버에서 애플리케이션의 이러한 측면을 호스팅해야 하므로 FTP 전송은 새 IP 주소에서 이러한 공급업체로 전송됩니다. 우리가 이러한 조치를 취하면 공급업체의 방화벽 등에 의해 전송이 거부되어 전송이 실패하기 시작할 것이라는 두려움이 있습니다. 가능하다면 공급업체 수와 공급업체 수로 인해 이러한 종류의 이동을 각 공급업체와 조정하는 것을 피하고 싶습니다. IT 리소스의 신뢰성이 다양합니다.
현재 FTP 프록시를 연구하고 있지만 다른 옵션이 무엇인지 궁금합니다. 비슷한 문제를 겪은 다른 SaaS 상점이 있을 것이라고 확신하며 그들이 어떻게 접근했는지 듣고 싶습니다.
감사해요!
답변1
모든 서버를 하나의 IP 주소로 NAT하도록 방화벽을 설정하면 단일 공용 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를 사용하여 다른 외부 IP 주소로 NAT를 사용할 수 있습니다.