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

Базовая конфигурация должна быть примерно такой, как на схеме ниже:

-
-  External Connection ----------+
-                                |
-                            Web Server (Externally Facing + VPC Subnet 1)
-                                |
-          +---------------------+-----------------+
-          |                     |                 |
- Data Services Server    Database Server   Compute Headnode
-    (VPC Subnet 1)       (VPC Subnet 1)   (VPC Subnet 1 & 2)
-                                                  |
-                                   +--------------+--------------+
-                                   |              |              |
-                            Worker Node 01  Worker Node 02  Worker Node 03
-                            (VPC Subnet 2)  (VPC Subnet 2)  (VPC Subnet 2)

На данный момент мне удалось настроить две подсети и установить необходимые узлы EC2.

Я настроил сетевой ACL в двух подсетях, чтобы предотвратить прямую связь экземпляров EC2 в подсети 1 с любыми IP-адресами в подсети 2, установив правила в двух подсетях следующим образом:

Подсеть 1:

  • 99 ALL Traffic ALL ALL 10.81.82.0/24 DENY
  • 100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  • * ALL Traffic ALL ALL 0.0.0.0/0 DENY

Подсеть 2:

  • 80 ALL Traffic ALL ALL 10.81.82.0/24 ALLOW
  • 100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  • * ALL Traffic ALL ALL 0.0.0.0/0 DENY

Проблема, с которой я столкнулся с этой настройкой, заключается в том, что я не вижу очевидного способа разрешить вычислительному узлу, подключенному как к подсети 1, так и к подсети 2, не отдавать приоритет 10.81.82.0/24 DENY правило подсети 1 по правилу 10.81.82.0/24 ALLOW подсети 2.

Я прочитал большинство страниц из сетевой документации Amazon VPC, однако Я все еще изо всех сил пытаюсь понять, как достичь такой иерархической структуры. Любая помощь или указатели в правильном направлении будут очень благодарны.

1
qt.cls 22 Апр 2014 в 20:52

2 ответа

Лучший ответ

Проблема решена.

Оказалось, что проблема приоритета была связана не напрямую с конфигурацией сетевого ACL, а с конфигурацией сети (с точки зрения организации подсетей), а также с необходимостью настроить веб-сервер и вычислительный головной узел для выполнения NAT между разными подсетями. .

Что касается организации подсети, при более внимательном рассмотрении документации AWS может показаться, что такую ​​сеть необходимо настроить следующим образом:

  • Подсеть 1: для внешнего подключения к веб-серверу (в моем случае 10.0.1.0/24). Эта подсеть была настроена для маршрутизации 0.0.0.0/0 к интернет-шлюзу.
  • Подсеть 2: для машин, не подключенных напрямую к внешнему соединению, за исключением рабочих узлов (в моем случае 10.0.2.0/24). Эта подсеть была настроена для маршрутизации 0.0.0.0/0 к вторичному сетевому интерфейсу на веб-сервере (внутри подсети). Затем веб-сервер был настроен для выполнения NAT между его интерфейсами 10.0.2.0/24 и 10.0.1.0/24.
  • Подсеть 3: только для рабочих узлов (в моем случае 10.0.30 / 24). Эта подсеть была настроена для маршрутизации 0.0.0.0/0 к вторичному сетевому интерфейсу на вычислительном головном узле. Затем Compute Headnode был настроен для выполнения NAT между его интерфейсами 10.0.3.0/24 и 10.0.2.0/24.

Затем я смог ограничить трафик между этими подсетями, чтобы обеспечить соблюдение иерархии NAT следующим образом, используя сетевые ACL для входящих и исходящих данных:

  • Подсеть 1: 90 ALL Traffic ALL ALL 10.0.2.0/24 DENY, 91 ALL Traffic ALL ALL 10.0.3.0/24 DENY и 100 ALL Traffic ALL ALL 0.0.0.0/0
  • Подсеть 2: 90 ALL Traffic ALL ALL 10.0.1.0/24 DENY, 91 ALL Traffic ALL ALL 10.0.3.0/24 DENY и 100 ALL Traffic ALL ALL 0.0.0.0/0
  • Подсеть 3: 90 ALL Traffic ALL ALL 10.0.1.0/24 DENY, 91 ALL Traffic ALL ALL 10.0.2.0/24 DENY и 100 ALL Traffic ALL ALL 0.0.0.0/0

Поскольку я хотел использовать FreeBSD, а не Linux для своих EC2, у меня было немало головных болей при установке необходимых экземпляров NAT.

В конце концов я нашел очень полезное руководство по этому поводу в выпуске журнала FreeBSD Magazine. Хотя некоторые из шагов настройки в этом больше не требовались для последних AMI FreeBSD, подробно описанных на Daemonology.net, основные этапы настройки не изменились с момента публикации.

Я полагаю, что любой, кто хочет сделать что-то подобное, используя Linux AMI для NAT, найдет этот процесс немного проще, но, поскольку я не пробовал, я не могу сказать точно.

В любом случае, я надеюсь, что это поможет всем, у кого есть подобные проблемы.

0
qt.cls 2 Май 2014 в 11:25

Здесь вы можете использовать группы безопасности. Свяжите экземпляры с группами безопасности и управляйте трафиком на уровне самого экземпляра, а для вычислительного узла вы можете играть с трафиком, используя NACL.

С уважением, Дев

0
Devashish 1 Май 2014 в 10:59