Диагностика проблем подключения экземпляров EC2: группы безопасности и сетевые списки ACL

Подключение к экземпляру Amazon Elastic Compute Cloud (EC2) является базовой операцией, однако сбои подключения входят в число наиболее распространенных сценариев устранения неполадок для пользователей AWS. Если экземпляр, казалось бы, работает правильно, но остается недоступным — будь то через SSH, RDP или трафик приложений — проблема почти всегда кроется в окружающих слоях сетевой безопасности. Это всеобъемлющее руководство описывает систематический подход к диагностике и устранению проблем подключения, фокусируясь на трех критически важных точках сетевого контроля: Группы безопасности (SG), Списки контроля доступа к сети (NACL) и Таблицы маршрутизации VPC.

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

Три столпа контроля подключения EC2

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

1. Таблицы маршрутизации: Определяют, куда направляется сетевой трафик на основе его целевого IP-адреса. Если трафик, предназначенный для Интернета или вашего клиентского IP-адреса, не может достичь правильного шлюза подсети, подключение завершится неудачей.
2. Списки контроля доступа к сети (NACL): Применяют правила ко всей подсети. Они без сохранения состояния, что означает, что как входящий, так и исходящий трафик должен быть явно разрешен. Они обрабатывают правила по порядку, от правила с наименьшим номером до правила с наибольшим, останавливаясь на первом совпадении.
3. Группы безопасности (SG): Применяют правила непосредственно к сетевому интерфейсу Elastic Network Interface (ENI) экземпляра EC2. Они с сохранением состояния, что означает, что если вы разрешаете входящий трафик, то ответный исходящий трафик автоматически разрешается.

Шаг 1: Проверка таблиц маршрутизации VPC

Первая диагностическая проверка всегда должна подтверждать, что существует путь для трафика, чтобы он вообще достиг подсети, где находится экземпляр EC2.

Проверка входящей маршрутизации

Для экземпляра, доступного из общедоступного Интернета (например, через SSH/RDP):

• Цель: Убедиться, что подсеть, содержащая экземпляр, имеет маршрут к Интернет-шлюзу (IGW) для трафика, исходящего из 0.0.0.0/0 (или вашего конкретного диапазона IP-адресов клиента).
• Действие: Перейдите в консоль VPC, выберите Таблицы маршрутизации и изучите таблицу маршрутизации, связанную с подсетью вашего экземпляра. Ищите запись вида:
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Проверка исходящей маршрутизации (для проблем с состоянием)

Хотя SG сохраняют состояние, проверка исходящего пути имеет решающее значение, особенно для ответного трафика или экземпляров, инициирующих соединения с внешними службами.

• Действие: Если ваш экземпляр находится в частной подсети, убедитесь, что он имеет маршрут к NAT-шлюзу или NAT-экземпляру для доступа к Интернету. Если он находится в публичной подсети, он должен маршрутизировать 0.0.0.0/0 к IGW.

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

Шаг 2: Проверка сетевых списков ACL (уровень подсети)

Списки NACL часто упускают из виду, потому что они работают на уровне подсети и являются без сохранения состояния. Распространенной ошибкой является разрешение входящего трафика, но забывание явно разрешить ответный исходящий трафик.

Проверка правил для входящего трафика

Для попыток входящего соединения (например, SSH на порту 22):

1. Определите NACL, связанный с подсетью экземпляра.
2. Изучите Правила для входящего трафика.
3. Убедитесь, что существует правило, которое разрешает используемый вами конкретный порт и протокол (например, Правило 100: Тип: SSH (22), Протокол: TCP, Источник: 0.0.0.0/0).

Проверка правил для исходящего трафика (ловушка без сохранения состояния)

Именно здесь возникает большинство проблем с подключением NACL.

1. Изучите Правила для исходящего трафика.
2. Если вы разрешили входящий SSH (порт 22), экземпляр должен отправлять трафик обратно вашему клиенту по диапазону высоких портов (эфемерных портов), обычно 1024-65535.
3. Действие: Убедитесь, что правило для исходящего трафика явно разрешает трафик к соответствующему диапазону целевых портов (часто 1024-65535, если клиент инициирует соединение).

Пример набора правил NACL для входящего доступа SSH:

Предупреждение: NACL оценивают правила по номерам. Если Правило 90 — ЗАПРЕТИТЬ ВСЁ, ваше последующее Правило 100 РАЗРЕШИТЬ SSH никогда не будет выполнено. Убедитесь, что ваши явные правила РАЗРЕШЕНИЯ имеют меньшие номера, чем любые широкие правила ЗАПРЕТА, или полагайтесь на окончательное неявное правило ЗАПРЕТИТЬ ВСЁ.

Шаг 3: Аудит групп безопасности (уровень экземпляра)

Группы безопасности — это последняя линия защиты, применяемая непосредственно к экземпляру. Ими легче управлять, потому что они с сохранением состояния.

Проверка правил для входящего трафика

Убедитесь, что SG, прикрепленная к экземпляру EC2, разрешает трафик на требуемых портах из ожидаемого источника:

• Для SSH (Linux): Правило для входящего трафика, разрешающее TCP-порт 22 с вашего публичного IP-адреса или 0.0.0.0/0 (при необходимости).
• Для RDP (Windows): Правило для входящего трафика, разрешающее TCP-порт 3389 с вашего публичного IP-адреса или 0.0.0.0/0.
• Для веб-трафика: Правило для входящего трафика, разрешающее TCP-порт 80 и/или 443 с 0.0.0.0/0.

Проверка правил для исходящего трафика (обычно по умолчанию)

Поскольку SG сохраняют состояние, правила для исходящего трафика обычно настроены на РАЗРЕШИТЬ ВЕСЬ ТРАФИК (0.0.0.0/0 на всех портах). Если вы настроили правила для исходящего трафика, убедитесь, что они разрешают ответы обратно на диапазон эфемерных портов клиента.

Лучшая практика: Если нет строгих требований к безопасности, оставьте Правила для исходящего трафика группы безопасности по умолчанию: Разрешить весь трафик на все направления. Это значительно упрощает устранение неполадок, так как вы можете изолировать проблемы с NACL или таблицей маршрутизации.

Сводка: Контрольный список потока подключения

При сбое подключения EC2 следуйте этой последовательности диагностики:

1. Проверка таблицы маршрутизации: Может ли путь трафика (входящий и исходящий) достичь правильного шлюза подсети (IGW/VPC Peering/NAT)?
2. Проверка NACL (без сохранения состояния): Явно ли РАЗРЕШЕН трафик на конкретном входящем порту И явно ли РАЗРЕШЕН ответный трафик (часто высокие эфемерные порты) для исходящего трафика?
3. Проверка группы безопасности (с сохранением состояния): Явно ли РАЗРЕШЕН трафик на конкретном входящем порту? (Исходящий трафик должен быть, как правило, открыт).

Систематически перемещаясь от широкого сетевого уровня (маршрутизация) до уровня подсети (NACL) и, наконец, до уровня экземпляра (SG), вы можете быстро определить, является ли блокирующий механизм фильтрацией без сохранения состояния, фильтрацией с сохранением состояния или сбоем маршрутизации.