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

Когда ваш EC2-инстанс запущен, но SSH, RDP или трафик приложения истекает по тайм-ауту, проблема обычно находится в сетевом пути вокруг инстанса. Диагностируйте подключение к EC2, сначала проверив таблицу маршрутизации, затем сетевой ACL подсети, а затем группу безопасности инстанса.

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

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

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

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

---

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

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

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

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

• Цель: Убедиться, что подсеть, содержащая публичный инстанс, имеет маршрут по умолчанию к Интернет-шлюзу (IGW).
• Действие: Перейдите в консоль VPC, выберите Таблицы маршрутизации и изучите таблицу маршрутизации, связанную с подсетью вашего инстанса. Найдите запись вида:

  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx
  

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

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

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

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

Шаг 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:

Входящие правила:

№ правила	Тип	Протокол	Диапазон портов	Источник	Разрешить/Запретить
100	SSH	TCP	22	IP-адрес вашего клиента/CIDR	РАЗРЕШИТЬ
*	*	*	*	*	ЗАПРЕТИТЬ (По умолчанию)

Исходящие правила:

№ правила	Тип	Протокол	Диапазон портов	Назначение	Разрешить/Запретить
100	Пользовательский TCP	TCP	1024-65535	IP-адрес вашего клиента/CIDR	РАЗРЕШИТЬ
*	*	*	*	*	ЗАПРЕТИТЬ (По умолчанию)

Предупреждение: 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/NAT)?
2. Проверка NACL (без сохранения состояния): Явно ли РАЗРЕШЕН трафик на конкретном входящем порту И явно ли РАЗРЕШЕН ответный трафик (часто высокие эпизодические порты) исходящий?
3. Проверка группы безопасности (с сохранением состояния): Явно ли РАЗРЕШЕН трафик на конкретном входящем порту? (Исходящий обычно должен быть открыт).

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