TLDR;Краткий обзор
Можно ли организовать группу виртуальных машин, каждая со своим общедоступным IPv4-адресом, чтобы имитировать нахождение в частной подсети, и если да, то как я могу подключить эти серверы к остальной части моей сети?
Текущая конфигурация
10.0.0.0/24 AWS Орегон — общедоступный
10.1.0.0/24 AWS Орегон — частный
10.52.5.0/24 Дом, Сан-Диего
10.62.5.0/24 Дом, Лас-Вегас
В общедоступной сети AWS есть сервер OpenVPN. И в Сан-Диего, и в Лас-Вегасе есть свои собственные выделенные клиенты OpenVPN, которые подключаются к этому серверу AWS.
Благодаря использованию этой настройки VPN «точка-точка» любая виртуальная машина в моей сети может общаться с любой другой виртуальной машиной без помех NAT. Все работает безупречно.
Проблема
Меня попросили доказать, что разработанное мной веб-приложение, которое в настоящее время работает в AWS Oregon, может так же успешно работать за пределами экосистемы AWS.
— Нет проблем, — говорю я. Итак, я арендую пять серверов у швейцарского поставщика и готовлюсь подключить эти серверы к своей сети.
Я предполагаю, что мое предположение заключалось в том, что SwissVendor предоставит мне пять серверов и разместит их во внутренней сети по моему выбору (например, 10.72.5.0/24, gw:.1) и, возможно, предоставит мне общедоступный (то есть «эластичный?») IP-адрес. просверлить мой путь снаружи. Затем я выбираю один из пяти серверов в качестве своего OpenVPN-клиента, указываю его на свой сервер AWS Oregon OpenVPN и, бум, швейцарские серверы теперь доступны из любой точки моей сети.
Однако, к сожалению для меня, в SwissVendor все работает иначе. Вместо этого каждый из пяти серверов имеет свой собственный общедоступный IP-адрес, и, кроме того, нет никакой гарантии, что эти IP-адреса находятся даже в одной подсети. Итак, я закончил с чем-то вроде:
Сервер 1: 11.11.11.11/24
Сервер 2: 22.22.22.22/24
Сервер 3: 33.33.33.33/24
Сервер 4: 44.44.44.44/24
Сервер 5: 55.55.55.55/24
Порт RDP 3389 открыт для всего мира на каждом сервере, что позволяет клиенту получить доступ через предварительно общий административный пароль. Все остальные входящие соединения блокируются брандмауэром сервера, который включен по умолчанию. Именно так SwissVendor предоставляет свои серверы таким клиентам, как я. Я не могу это изменить.
Моя цель
Здесь все сложно описать, так как я любитель, а не профессионал. В моем идеальном мире:
- Каждый из швейцарских серверов, в дополнение к собственному реальному общедоступному адресу, также будет иметь своего рода искусственный/виртуальный сетевой адаптер во внутренней сети 10.72.5.0/24.
- Серверы смогут взаимодействовать друг с другом на высокой скорости практически с нулевой задержкой. [Можно предположить, что каждый из швейцарских серверов находится в одном и том же физическом шкафу и действительно может располагаться на одном и том же физическом оборудовании!]
- Один из серверов будет действовать как клиент OpenVPN, подключенный к моему серверу AWS OpenVPN, который эффективно подключит 10.72.5.0/24 к моей сети, сделав каждый из этих серверов доступным для остальной части моей сети, но не для Интернета. и без помех NAT.
Я не совсем понимаю, как это осуществить, и возможно ли это вообще. Вот два подхода, которые я рассматривал, но в конечном итоге исключил:
Неудачная идея № 1: каждый сервер действует как клиент OpenVPN
Я мог бы отказаться от идеи иметь выделенный клиент OpenVPN в швейцарской сети. Вместо этого каждый швейцарский сервер будет запускать свой собственный клиент OpenVPN, предоставляя каждому свой дополнительный IP-адрес. Таким образом, в дополнение к общедоступному IP-адресу каждый сервер также будет иметь виртуальный IP-адрес, вероятно, в соответствии с линиями 10.8.0.0/24.
Это будет работать, поскольку швейцарские серверы смогут общаться друг с другом, а также с остальной частью моей сети.
Проблема в том, что для того, чтобы пакет попал от SwissServer1 к SwissServer2, он должен пройти весь путь до Орегона и обратно, что крайне неэффективно, учитывая, что и SwissServer1, и SwissServer2 живут на одной физической машине. Напомним, что мне нужна быстрая связь с малой задержкой между швейцарскими серверами.
Неудачная идея № 2: швейцарские серверы обмениваются данными, используя свои общедоступные адреса
Я мог бы просто разрешить швейцарским серверам общаться между собой, используя их соответствующие общедоступные IP-адреса. Это, безусловно, решит проблему задержки.
Основная проблема, которую я предвижу в этом подходе, заключается в том, что, поскольку IP-адрес каждого швейцарского сервера является общедоступным и, следовательно, открыт для Интернета, мне нужно быть ДЕЙСТВИТЕЛЬНО осторожным при настройке правил брандмауэра для каждого сервера. Например, если SwissServer1 хочет использовать общий доступ к файлам с SwissServer2, мне нужно точно знать, какие порты используются для этого, и открывать только эти порты и только для SwissServer1. Если я сделаю одну маленькую ошибку, я могу в конечном итоге выставить этот файлообменник в общедоступный Интернет.
Также возникает вопрос, как правильно подключить эти машины к остальной части моей сети. Так что я тоже считаю этот подход неудачным.
Куда отсюда?
Я исследовал это и не могу понять правильный подход. Я думаю, что я ищу что-то, называемое «мостом», и я думаю, что OpenVPN может поддерживать это, но я не уверен. Насколько я понял из своих обширных исследований в Википедии и Reddit, использование технологии моста может позволить пяти швейцарским серверам действовать так, как будто они находятся в какой-то одной сети, например, 10.52.7.0/24, тем самым облегчая быструю связь между этими одноранговыми узлами. . Но тогда что? Как мне сделать 10.52.7.0/24 доступным для остальной части моей существующей сети?
Все серверы работают под управлением Windows 2019 Server или Windows 2022 Server.
Любые советы приветствуются!
