Подключение сети к её пользователям

Введение

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

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

Связь с сертификацией

Обзор лабораторной работы

Создание маршрута в интернет

На этом шаге вы подключите интернет-шлюз к VPC приложения и явно свяжете таблицу маршрутизации с его подсетью.

Откройте Terminal и AWS View. Сеть приложения и эталонная сеть независимы. У application-server уже есть публичный адрес, потому что его подсеть назначает публичные IP при запуске. Сам по себе публичный адрес не создаёт маршрут в интернет или разрешение на входящий доступ.

В AWS View выберите application-server, User · 198.51.100.10 и Application · 8081, затем нажмите Send request. Ожидайте Blocked. Выберите reference-server с тем же клиентом и портом приложения, отправьте ещё один запрос и убедитесь, что эталонное приложение отвечает. Сохраняйте работоспособность этого эталонного приложения на протяжении всей лабораторной работы.

Перейдите в подготовленный рабочий каталог:

cd /home/labex/project/application-access

Предоставленный terraform.tfvars.json содержит идентификаторы VPC, подсети и группы безопасности этой новой среды. Terraform автоматически загружает эти входные значения. Прочитайте их перед использованием соответствующих переменных:

cat terraform.tfvars.json

Подготовленная конфигурация провайдера выбирает среду курса. Не нужно копировать идентификаторы из предыдущей VM или вводить личные учётные данные. Сохраните и выведите идентификатор предоставленного целевого экземпляра для последующей проверки. $(...) захватывает вывод команды, а --output text возвращает идентификатор обычным текстом.

TARGET_ID=$(aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=application-server Name=instance-state-name,Values=running \
  --query 'Reservations[0].Instances[0].InstanceId' \
  --output text)
echo "$TARGET_ID"

Интернет-шлюз подключается к VPC. Таблица маршрутизации отправляет трафик к заданному назначению через соответствующий шлюз, а связь с подсетью определяет, какая таблица управляет подсетью. Без явной связи подсеть использует главную таблицу маршрутизации своей VPC. Оставьте эту предоставленную главную таблицу без изменений. Назначение 0.0.0.0/0 соответствует IPv4-адресам, для которых нет более конкретного маршрута; оно не даёт разрешения на прохождение через группу безопасности.

Создайте routing.tf. Heredoc с разделителем в кавычках записывает HCL буквально. Ссылки на ресурсы связывают маршрут с его таблицей и шлюзом, а связь подсети — с той же таблицей.

cat > routing.tf <<'HCL'
resource "aws_internet_gateway" "application" {
  vpc_id = var.vpc_id
}

resource "aws_route_table" "application" {
  vpc_id = var.vpc_id
}

resource "aws_route" "internet" {
  route_table_id         = aws_route_table.application.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.application.id
}

resource "aws_route_table_association" "application" {
  subnet_id      = var.subnet_id
  route_table_id = aws_route_table.application.id
}

output "route_table_id" {
  value = aws_route_table.application.id
}

output "subnet_id" {
  value = var.subnet_id
}
HCL

Инициализируйте, отформатируйте и проверьте конфигурацию:

terraform init
terraform fmt
terraform validate

Если init выводит Incomplete lock file information for providers, речь идёт о контрольных суммах для других платформ. Эта подготовленная VM использует linux_amd64; продолжайте после успешного завершения инициализации и валидации.

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

terraform plan

Примените изменения и введите yes в ответ на запрос:

terraform apply

Сохраните и выведите идентификатор новой таблицы и идентификатор предоставленной подсети:

TABLE_ID=$(terraform output -raw route_table_id)
echo "$TABLE_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

Независимо запросите таблицу маршрутизации. Найдите назначение по умолчанию, шлюз igw-... и связь с идентификатором вашей подсети. Локальный маршрут VPC также сохраняется.

aws ec2 \
  describe-route-tables \
  --route-table-ids "$TABLE_ID" \
  --query 'RouteTables[].{Routes:Routes[].{Destination:DestinationCidrBlock,Gateway:GatewayId},Subnets:Associations[].SubnetId}'

Подтвердите назначение публичных адресов в предоставленной подсети:

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{CIDR:CidrBlock,PublicIPOnLaunch:MapPublicIpOnLaunch}'

PublicIPOnLaunch имеет значение true. Эта настройка управляет вновь запускаемыми экземплярами; её изменение не назначает адрес уже существующему экземпляру задним числом. Теперь AWS View показывает фактический шлюз и действующую таблицу маршрутизации. Снова отправьте запрос User/8081 к приложению: он по-прежнему даёт Blocked, потому что ни одно входящее правило пока его не разрешает.

Разрешение доступа нужному клиенту и проверка границ

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

Группа безопасности — сетевая граница с отслеживанием состояния, прикреплённая к сетевому интерфейсу экземпляра. Маршрутизация делает путь доступным; группа по-прежнему определяет, какие входящие подключения разрешены. У предоставленной группы приложения сейчас нет входящих правил.

Создайте один отдельный ресурс входящего правила для этой группы. cidr_ipv4 = "198.51.100.10/32" выбирает единственный IPv4-адрес клиента User. Оба значения порта, равные 8081, разрешают доступ только к слушающему порту приложения. Эталонное приложение использует собственную группу безопасности.

cat > access.tf <<'HCL'
resource "aws_vpc_security_group_ingress_rule" "application" {
  security_group_id = var.security_group_id
  ip_protocol       = "tcp"
  from_port         = 8081
  to_port           = 8081
  cidr_ipv4         = "198.51.100.10/32"
}

output "security_group_id" {
  value = var.security_group_id
}
HCL

Отформатируйте и проверьте конфигурацию, затем изучите план. Должно быть одно добавление входящего правила без замены экземпляра.

terraform fmt
terraform validate
terraform plan

Примените правило и подтвердите, введя yes:

terraform apply

Сохраните и выведите идентификатор существующей группы, затем прочитайте её фактическое разрешение на входящий доступ:

GROUP_ID=$(terraform output -raw security_group_id)
echo "$GROUP_ID"

aws ec2 \
  describe-security-groups \
  --group-ids "$GROUP_ID" \
  --query 'SecurityGroups[].{Group:GroupId,Ingress:IpPermissions}'

Разрешение должно описывать TCP-порт 8081 для источника 198.51.100.10/32. Подтвердите согласованность конфигурации и ресурсов Terraform:

terraform plan

Ожидайте No changes. Теперь выполните все три проверки в AWS View, каждый раз выбирая application-server:

Выберите User · 198.51.100.10 и Application · 8081. Нажмите Send request. Ожидайте Connected · 200 и сообщение Application network connected.

Измените источник на Unrelated · 198.51.100.20, оставьте порт 8081 и отправьте ещё один запрос. Ожидайте Blocked. Вернитесь к источнику User, выберите SSH · 22 и отправьте ещё один запрос. Ожидайте Blocked. Успешный запрос к приложению не разрешает доступ к отдельному слушающему порту SSH гостевой системы.

Результат указывает фактический источник, целевой экземпляр и порт. Request service unavailable — ошибка среды, а не доказательство ожидаемой блокировки сетью. Не расширяйте правило до 0.0.0.0/0: это откроет тот же слушающий порт приложения постороннему клиенту.

В документации провайдера AWS по входящим правилам описаны поля ресурса. Данные CLI, сопоставление Terraform и результаты фактических запросов должны согласовываться.

Удаление ресурсов подключения с сохранением приложений

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

Этот рабочий каталог управляет пятью ресурсами: интернет-шлюзом, таблицей маршрутизации, маршрутом по умолчанию, связью с подсетью и входящим правилом. VPC, подсеть, главная таблица маршрутизации, целевой экземпляр и эталонное приложение предоставлены независимо. Они находятся вне этого состояния и должны сохраниться.

Изучите план удаления:

terraform plan -destroy

Ожидайте удаление пяти ресурсов. Затем выполните удаление и введите yes:

terraform destroy

Убедитесь, что в состоянии нет адресов управляемых ресурсов:

terraform state list

Предоставленный целевой экземпляр должен по-прежнему работать с тем же идентификатором:

aws ec2 \
  describe-instances \
  --instance-ids "$TARGET_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Subnet:SubnetId}'

В AWS View снова отправьте целевому экземпляру запрос User/8081. Он должен дать Blocked, потому что вы удалили ресурсы его подключения. Затем выберите reference-server, User и порт 8081 и отправьте запрос. Эталонное приложение по-прежнему должно возвращать Connected · 200 и Reference application.

Ваши файлы HCL остаются доступными для изучения. Последующий обычный план предложил бы повторно создать удалённые ресурсы; сохранение этой конфигурации после terraform destroy — нормальное поведение.

Резюме

Вы использовали ссылки Terraform, чтобы подключить интернет-шлюз, определить маршрут по умолчанию и связать таблицу маршрутизации с подсетью приложения. Затем вы добавили одно ограниченное входящее правило, проверили фактические границы по источнику и порту, подтвердили согласованность и удалили только свои ресурсы подключения, сохранив предоставленные приложения.