Регистрация Войти
Рейтинг:1
avatar Server

Ограничение трафика между AWS VPC

флаг za
Ralf

У меня есть два VPC: A и B.

Я хочу, чтобы любой узел в A мог открывать TCP-соединение с любым узлом в B, но не наоборот. Любой узел в B также должен иметь возможность открывать исходящие соединения с общедоступными интернет-хостами. Каков наилучший способ добиться этого?

Вариант использования: VPC A содержит множество конфиденциальных внутренних служб, а VPC B содержит узлы, на которых выполняется совершенно ненадежный код. VPC A должен отправлять HTTP-запросы к VPC B, но ни одна из внутренних служб не должна быть раскрыта.

Пиринг VPC позволяет устанавливать прямые соединения между любыми узлами в A и B — это не может быть ограничено на уровне маршрутизации. Группы безопасности можно использовать для блокировки исходящих подключений, но их немного сложно настроить, поскольку нет правила DENY.

Сетевые ACL здесь бесполезны, так как обратный трафик должен быть разрешен из B -> A.

Есть ли другие варианты? Что-то вроде шлюза NAT, который позволяет открывать соединения только в одном направлении? AWS поддерживает частные шлюзы NAT, но я не могу найти документацию для такой конфигурации.

86
0 + 0
Рейтинг:3
Tim avatar Server
флаг gp
Tim

Я не читал ваш ответ подробно, но он кажется немного неправильным. Я не знаю, почему вы вообще используете шлюзы NAT, они предназначены исключительно для того, чтобы разрешить экземплярам в частной подсети доступ в Интернет.

Ключевым моментом здесь является связь в одном направлении, которая настоятельно предполагает, что ответом являются группы безопасности. Мое решение (не слишком задумываясь было бы):

  • Пиринг VPC между двумя VPC, разные диапазоны CIDR
  • Таблица маршрутов в обоих VPC для обеспечения связи
  • Группы безопасности в VPC A, чтобы разрешить исходящий трафик в диапазоны CIDR VPC B, но не входящий. Это позволит разрешить исходящий и обратный трафик, но не трафик, инициированный в VPC A.
  • Группы безопасности в VPC B разрешают входящий трафик из VPC A CIDR, но не разрешают исходящий. Это пропускает трафик и позволяет ему возвращаться, но не позволяет трафику, инициированному в A, попасть в B.
  • Интернет-шлюз в VPC B. Если вам не нужен Интернет для подключения к VPC B, вы можете использовать шлюз NAT в VPC B.
0 + 0
флаг za
Ralf
Самая сложная часть этой настройки — «Группы безопасности в VPC B разрешают входящий трафик из VPC A CIDR, но не разрешают исходящий». Мне нужно разрешить исходящий трафик в общедоступный Интернет из VPC B, но не в VPC A. Поскольку в группах безопасности нет правил «DENY», у меня есть обходной путь: разрешить исходящий трафик в список из 33 блоков CIDR, которые _должны_ охватывают весь общедоступный доступ в Интернет. Шлюзы NAT, кажется, отлично работают для внутреннего трафика, даже если это не обычная настройка.
0
Ответить
Tim avatar
флаг gp
Tim
Я настоятельно рекомендую вам пройти обучение по AWS или хотя бы почитать о группах безопасности. Это несложный сценарий, вы решили его довольно причудливым способом, который может иметь последствия и будет стоить вам дороже данных/платы за NAT. Я довольно хорошо обучен / сертифицирован / имею опыт работы с AWS. Я понятия не имел, что шлюз NAT может делать что-либо, кроме предоставления доступа в Интернет для частных подсетей — похоже, вы используете его, чтобы обойти нетранзитивную природу AWS VPC. Это действительно простая проблема, и ее можно решить с помощью простого решения.
0
Ответить
флаг za
Ralf
Шлюз NAT добавляет накладные расходы и затраты (незначительные для этого варианта использования). Это может быть нетрадиционно, но оно добавляет параметры для дополнительных уровней безопасности на уровне подсети, а не только для групп безопасности. Точно так же в более типичных сценариях, когда вы можете использовать общедоступную подсеть и защищать ее с помощью групп безопасности, вы получаете лучшую изоляцию с помощью частных подсетей + шлюза NAT для доступа в Интернет. То же самое относится и здесь в значительной степени.
0
Ответить
Tim avatar
флаг gp
Tim
Хорошо, все, что работает для вас. Возможно, имейте в виду, что я никогда раньше не слышал, чтобы шлюз NAT использовался таким образом, и могут быть недостатки, которые не очевидны. На самом деле вы не используете передовую практику, но если она работает для вас, отлично.
0
Ответить
Рейтинг:0
avatar Server
флаг za
Ralf

Похоже, это может работать, если добавить частный шлюз NAT в выделенную подсеть.

Эта установка, кажется, работает:

ВКЦ А: 10.1.0.0/16

Подсеть A1: 10.1.1.0/24. Основная подсеть, содержащая узлы в A.
Подсеть A2: 10.1.2.0/24. Выделенная подсеть для шлюза NAT.

ВПК Б: 10.2.0.0/16

Подсеть B1: 10.2.3.0/24: основная подсеть, содержащая узлы в B.

Частный шлюз NAT в подсети A2. (нат-1)
Пиринг VPC между VPC A и B. (pcx-1)

Таблица маршрутов для A1:

10.1.0.0/16 (А): локальный
10.2.3.0/24 (B1): нат-1

Таблица маршрутов для A2:

10.1.0.0/16 (А): локальный
10.2.3.0/24 (B1): pcx-1

Таблица маршрутов для B1:

10.2.0.0/16 (Б): местный
10.1.2.0/24 (A2): pcx-1

Поскольку прямого маршрута между A1 и B1 нет, весь трафик должен проходить через шлюз NAT.А шлюз NAT разрешает входящие соединения только из одного и того же VPC, поэтому узел в B1 не может открыть соединение с узлом в A1.

Группы безопасности и сетевые ACL могут использоваться здесь в качестве дополнительных уровней безопасности, и конфигурация будет довольно простой при таком разделении на подсети. Но это тоже было бы избыточно, так как маршрута из В1 в А1 нет.

0 + 0
Oscar De León avatar
флаг la
Oscar De León
Если нет маршрута из B в A, вы не получите никаких обратных данных. «Он не будет знать, куда идти». Ответ Тима прямо в точку.
0
Ответить
флаг za
Ralf
Нет _прямого_ маршрута из B1 в A1. Существует маршрут от B1 до A2, и обратный трафик проходит обратно через этот шлюз NAT.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.