У меня есть служба SaaS, которая предоставляет URL-адрес (скажем, (https://mylink.foo.com), который доступен только с некоторых IP-адресов из белого списка. Однако теперь нам нужно, чтобы вышеупомянутый URL-адрес был доступен аудитории за пределами этих IP-адресов из белого списка. Я подумал о реализации другого общедоступного облачного сервера в качестве IaaS, который действует как точка опоры, меняя исходный и целевой IP-адреса и перенаправляя запрос моему поставщику SaaS (он отличается от IaaS), единственным IP-адресом в белом списке в этом случае будет опорная точка общедоступный IP-адрес.
Кроме того, поскольку правильный URL-адрес будет указывать на исходный сервер, который недоступен с IP-адресов, не включенных в белый список, я думаю о публикации HTTP-сервера из того же свода, который предоставляет второй URL-адрес (https://accesslink.foo.com), который заменяется исходным URL-адресом в целях доступности.
Поскольку этот сценарий предлагается, он будет включать:
- Сводная точка Linux, действующая как брандмауэр/устройство NAT, перезаписывающая исходные/целевые IP-адреса. Для этой цели подойдет Iptables.
- (возможно?) другой хост, выступающий в роли обратного прокси-сервера HTTP, переписывает URL-адрес для запросов, поступающих на сервер. Здесь используется HTTP-сервер с mod_rewrite или nginx.
Мои опасения и вопросы:
- Возможна ли вся идея о моей реализации? есть ли другое более простое решение такой проблемы?
Возможна ли перезапись, учитывая, что исходный URL-адрес предоставляется через HTTPS, а не через HTTP?
Если вы не возражаете против того, чтобы поделиться другими проблемами/проблемами реализации, которые могут не быть рассмотрены в моем описании, не стесняйтесь раскрывать их.
