tl; dr Есть ли способ направить трафик с 172.20.0.100 на 200.0.0.100 на диаграмме через 10.0.0.6?
У меня есть установка, в которой у нас есть существующий AWS VPC (172.20.0.0/16) с несколькими хостами. Мы пытаемся настроить VPN для поставщика, у которого есть следующие ограничения:
С этой целью поставщик выделил нам диапазон 10.0.0.0/28. Мы настроили второй VPC в учетной записи с этой сетью, потому что мы не смогли добавить диапазон 10.0.0.0/28 к существующему VPC. Кажется, это ограничение, при котором вы можете добавлять в VPC только дополнительные диапазоны с тем же префиксом (10, 172, 192).
В таблице маршрутов VPC 2 есть маршрут, который отправляет весь трафик для 200.0.0.0/24 через внутренний интерфейс (eni) хоста IPSEC VPN.
VPN-соединение от 10.0.0.6 до 200.0.0.100 работает.
VPC 1 и 2 являются одноранговыми, а маршруты и SG были изменены таким образом, что все машины в 172.20.0.0/16 могут подключаться ко всем хостам в 10.0.0.0/28 (весь трафик, а не определенные правила UDP / TCP / ICMP). Итак, 172.20.0.100 может подключиться к 10.0.0.6.
Есть ли способ настроить это так, чтобы:
Заранее спасибо !
У вас интересный сценарий. Я расскажу о пяти методах поддержки маршрутизации двух сетей с другой сетью между ними.
Вы задали два вопроса:
Есть ли способ настроить это так, чтобы:
1) Весь трафик к 200.0.0.0/24 от VPC 1 направляется через внутренний сетевой адаптер на хосте VPN.
2) Весь трафик на 200.0.0.0/24 от VPC 2 направляется через внутренний сетевой адаптер на хосте 10.0.0.6, так что он может быть NAT?
1) Для Q1 ваш VPN-хост является маршрутизатором, который поддерживает добавление записей маршрута? Если да, то возможно (см. Нижние комментарии к МЕТОДУ 3). Если нет, просмотрите МЕТОД 3 или МЕТОД 4.
2) Для Q2 посмотрите МЕТОД 4, чтобы настроить прокси-сервер на этом экземпляре. Однако не используйте этот экземпляр ни для чего другого, только для обслуживания прокси. Размер и тип будут зависеть от того, сколько трафика вам нужно проложить.
Однако, если ваш поставщик разрешает исходные адреса только от 10.0.0.0/28, то МЕТОД 4 (прокси-сервер), вероятно, является единственным решением.
Теперь о различных методах. Не все приемлемы с учетом ваших требований. Я перечисляю их все на всякий случай, если вы можете изменить свою среду.
МЕТОД 1. Простейшее решение - разрешить поставщику использовать VPN от VPC 1 до своего центра обработки данных и разрешить 172.200.0.0/24. Вы можете уменьшить его до / 28, создав подсеть 172.200.X.0 / 28 (которая допускает только 11 хостов)
МЕТОД 2. Переместите ресурсы с VPC 1 на VPC 2. Применяются те же ограничения подсети.
МЕТОД 3. В VPC 2 необходимо настроить экземпляр, на котором запущено программное обеспечение маршрутизации (R1). Этому экземпляру нужны адреса в подсети / 28. Затем из VPC 1 вы создаете запись в таблице маршрутов для трафика, идущего на 200.0.0 / 24, и отправляете его на R1. Аналогичная запись должна быть внесена в таблицу маршрутизации поставщиков для отправки трафика для 172.20.0.0/16 на R1. Обе сети (VPC 1 и поставщик) потребуют маршруты для 10.0.0.0/28. Возможно, вы сможете настроить маршрутизацию на своем IPsec VPN-хосте (это экземпляр, на котором запущено программное обеспечение VPN или VGW?). Примечание. Ваш поставщик должен будет разрешить ваши адреса 172.20.0.0/16 (или подсеть) в своей сети, так как это будет исходный IP-адрес, а не 10.x.x.x.
МЕТОД 4. Настройте прокси-сервер в VPC 2 и направьте трафик на прокси-сервер. Это означает, что трафик исходит в одном направлении VPC 1 -> Vendor (или в обратном направлении). Поставщик не сможет направить трафик на VPC 1. Вы можете выполнить сопоставление портов на прокси-сервере для поддержки Vendor -> VPC 1. Однако с сопоставлением портов вы не сможете сопоставить все порты для всех адресов (только те, которые вы настраиваете).
[ИЗМЕНИТЬ с МЕТОДОМ 5]
Если VPN-хост в VPC2 является виртуальным шлюзом AWS (VGW), вы можете настроить маршрут к VPC 1 (несколько VPC могут использовать один и тот же VGW). Это может быть самое простое решение.
Я думаю, что самый простой и эффективный способ - использовать AWS Route Tables. Достаточно добавить запись с адресом назначения 200.0.0.0/24 в NIC-id | Instance-id в подсетях в VPC, где установлен ваш VPN-экземпляр. И от 200.0.0.0/24 до 10.0.0.1/32 на другом VPC.
Поскольку VPC уже проверены, это должно выполнить свою работу. И прелесть такого решения в том, что на экземплярах не нужно возиться / настраивать.
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Имейте в виду, что есть sourcs destination check
вариант на уровне EC2, который может стать ловушкой для AWS. Скорее всего, вам нужно отключить это на вашем хосте ipsec (10.0.0.1).