Мы - поставщик SaaS, настраивая IPSec VPN между нашим центром обработки данных и сайтом клиента, чтобы он мог напрямую обращаться к своему размещенному серверу базы данных из своей локальной сети.
Вместо того, чтобы предоставлять клиенту доступ к нашему внутреннему диапазону LAN, в нашем `` эталонном дизайне '' NAT используется только для сервера, который им нужен, за другим частным адресом DMZ внутри VPN, и клиент делает то же самое, чтобы не раскрывать нам свой внутренний диапазон .
Так, например, в "эталонном" дизайне
Customer Server --> Cust VPN NAT ====== VPN ======= My VPN NAT --> My server
192.168.27.4 --> 10.10.10.4 =================> 10.20.0.5 --> 192.168.3.16
Пока мы можем согласиться использовать неконфликтующие IP-адреса NAT в частных диапазонах (10.10. Против 10.20.), Это работает нормально. Мы принимаем только входящие соединения от клиента, а в приведенном выше примере увидим трафик только с 10.10.10.4.
Сегодня заказчик говорит, что он может работать только с общедоступными IP-адресами в качестве IP-адресов NAT на обоих концах, чтобы избежать любого шанса конфликта диапазонов. Это крупная глобальная корпорация, у которой есть тысячи свободных публичных IP-адресов, поэтому для них нет проблем. Мы - небольшой поставщик SaaS, размещенный в одном месте, и мы должны обосновывать каждый публичный IP-запрос нашим поставщикам.
Customer Server --> Cust VPN NAT ====== VPN ======= New Public IP --> My server
192.168.27.4 --> 1.2.3.4 =================> 5.6.7.8 --> 192.168.3.16
У нас нет проблем помочь клиенту, пройти весь процесс и получить для этого публичные IP-адреса, но ...
Спасибо за вашу помощь.
Честно говоря, я считаю, что это больше бизнес-решение, чем техническое решение. (Люди, конечно, вправе не соглашаться со мной.) Но ИМХО, это сводится к следующему:
Я бы вообще не беспокоился о № 3. Это обычная установка, и похоже, что они привыкли добиваться своего. Увы.
«Я не хочу этого делать; какие технические причины я должен им дать, чтобы этого избежать?» это совсем другой вопрос.