Устранение распространенных проблем и ошибок подключения к EC2

Когда подключение к EC2 не удается, первый полезный вопрос — недоступен ли инстанс, отклоняет ли он аутентификацию или доступен только по неправильному пути. Независимо от того, используете ли вы SSH для инстансов Linux или протокол удаленного рабочего стола (RDP) для инстансов Windows, сбои подключения распространены и часто вызывают разочарование. Ошибки SSH и RDP имеют тенденцию смешиваться, но Permission denied, Connection timed out, Connection refused и пустой экран RDP указывают на разные уровни. Воспринимайте текст ошибки как подсказку, затем работайте снаружи внутрь.

Этап 1: Первоначальные проверки и работоспособность инстанса

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

1. Проверки статуса инстанса

Используйте консоль управления AWS или AWS CLI, чтобы проверить общую работоспособность инстанса. Две критически важные проверки должны быть пройдены:

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

Действие: Если какая-либо из проверок не удалась, рассмотрите возможность остановки и запуска инстанса (что перемещает его на новое оборудование, если не удалась проверка системы) или проверки системного журнала на предмет подсказок.

2. Проверка публичного IP-адреса и DNS-имени

Убедитесь, что вы пытаетесь подключиться к правильному адресу. Если ваш инстанс должен быть доступен напрямую из интернета, ему нужен публичный IPv4-адрес или Elastic IP, а также маршрут публичной подсети через интернет-шлюз. Если он находится в частной подсети, вы должны подключаться через бастион-хост или использовать AWS Systems Manager Session Manager.

Совет: Если инстанс был остановлен и запущен, его публичный IP-адрес мог измениться, если вы не назначили Elastic IP.

3. Проверка конфигурации клиента (SSH/RDP)

Ошибки подключения иногда возникают на локальной стороне. Убедитесь, что ваше клиентское программное обеспечение работает корректно.

Для SSH (Linux/macOS): Убедитесь, что вы используете правильный файл закрытого ключа (.pem или .ppk) и что права доступа установлены правильно (chmod 400 /path/to/key.pem).
Для RDP (Windows): Убедитесь, что вы используете правильный пароль, полученный путем расшифровки пароля администратора с помощью файла закрытого ключа в консоли EC2.

Этап 2: Диагностика уровней безопасности (самые частые сбои)

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

4. Входящие правила группы безопасности (SG)

Группы безопасности — это stateful брандмауэры, прикрепленные непосредственно к эластичному сетевому интерфейсу (ENI) инстанса.

Требования для Linux (SSH):

Протокол: TCP
Диапазон портов: 22
Источник: Ваш публичный IP-адрес (My IP) или 0.0.0.0/0 (для всех IP, хотя это не рекомендуется по соображениям безопасности).

Требования для Windows (RDP):

Протокол: TCP
Диапазон портов: 3389
Источник: Ваш публичный IP-адрес или 0.0.0.0/0.

Шаг устранения неполадок: Временно измените источник требуемого входящего правила на 0.0.0.0/0 для соответствующего порта (22 или 3389). Если вы сможете подключиться, проблема заключалась в том, что ваш конкретный IP-адрес клиента был заблокирован или неправильно идентифицирован.

Предупреждение: Никогда не оставляйте группы безопасности открытыми для 0.0.0.0/0 для портов управления (22/3389) в производственных средах. По возможности используйте конкретные IP-адреса источников или конечные точки VPC.

5. Сетевые ACL (NACL)

Сетевые ACL — это stateless брандмауэры на уровне подсети. Они независимо проверяют входящий и исходящий трафик. Если трафик разрешен на вход, ответный трафик также должен быть разрешен на выход.

Требования NACL для подключения:

Направление	Протокол	Диапазон портов	Действие правила
Входящий	TCP	22 (SSH) или 3389 (RDP)	Разрешить
Исходящий	TCP	Эфемерные порты (1024-65535)	Разрешить

Эфемерные порты критически важны. Когда ваш клиент подключается (например, с порта 54321), сервер отвечает на высокий номер эфемерного порта. Если NACL блокирует исходящий трафик на этих высоких портах, сервер не может отправить ответ обратно вам, что приводит к тайм-ауту соединения.

Шаг устранения неполадок: Убедитесь, что как входящий порт (22/3389), так и исходящие эфемерные порты (1024-65535) имеют правило Разрешить в связанном NACL.

Этап 3: Маршрутизация и конфигурация VPC

Если уровни безопасности подтверждены как открытые, проблема заключается в том, как трафик маршрутизируется в подсеть инстанса и из нее.

6. Тип подсети и таблицы маршрутизации

Подключение полностью зависит от того, находится ли ваш инстанс в публичной подсети или частной подсети.

Подключение публичной подсети

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

Инстансу должен быть назначен публичный IPv4-адрес или Elastic IP.
Связанная таблица маршрутизации должна иметь маршрут для 0.0.0.0/0, указывающий на интернет-шлюз (IGW).

Подключение частной подсети

Инстансы в частных подсетях не могут быть достигнуты напрямую из интернета. Для подключения требуется многошаговый путь:

Подключение через бастион-хост (прыжковый хост): Вы подключаетесь по SSH к публичному инстансу EC2, а затем с бастион-хоста по SSH к частному инстансу (используя его частный IP).
Подключение через VPN/Direct Connect: При использовании AWS Site-to-Site VPN или Direct Connect маршрутизация должна быть настроена так, чтобы направлять трафик в вашу локальную сеть, которая затем маршрутизирует его в частную подсеть.

7. Проблемы с брандмауэром на уровне ОС

Если проверки безопасности AWS пройдены, операционная система, работающая на инстансе EC2, может блокировать подключение. Это часто случается, если вы вручную установили или настроили локальные брандмауэры (например, iptables на Linux или брандмауэр Защитника Windows).

Диагностика (если возможно через консоль или Session Manager):

Linux: Проверьте iptables -L или используйте firewall-cmd --list-all. Убедитесь, что порт 22 явно разрешен.
Windows: Проверьте настройки брандмауэра Защитника Windows для входящих правил на порт 3389.

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

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

Не предполагайте, что каждый инстанс EC2 должен принимать SSH или RDP из интернета. Публичным инстансам нужен публичный адрес, маршрут к интернет-шлюзу, разрешающие элементы управления безопасностью и работающий слушатель. Частным инстансам обычно нужен другой метод доступа: бастион-хост, VPN, Direct Connect, конечная точка EC2 Instance Connect или Systems Manager Session Manager.

Session Manager особенно полезен для операционных команд, поскольку может устранить необходимость во входящем SSH. Инстансу нужен агент SSM, профиль экземпляра IAM с соответствующими разрешениями Systems Manager и сетевой доступ к конечным точкам SSM. В частных подсетях это обычно означает конечные точки интерфейса VPC или исходящий интернет через NAT. Если какой-либо из этих компонентов отсутствует, Session Manager не будет отображаться как опция, даже если сам инстанс работоспособен.

Для конструкции с бастионом проверьте оба этапа. Сначала подключитесь с вашей рабочей станции к бастиону. Затем подключитесь от бастиона к частному IP целевого инстанса. Группа безопасности целевого инстанса обычно должна разрешать SSH только от группы безопасности бастиона, а не от вашего домашнего IP и не от всего CIDR VPC, если у вас нет на то причин.

Для RDP помните, что загрузка Windows может занять больше времени, чем запуск SSH на Linux, особенно после установки обновлений или первого запуска. Если проверки статуса инстанса только что пройдены, но RDP все еще не работает, проверьте системный журнал и подождите несколько минут, прежде чем изменять правила брандмауэра. Многократная замена групп безопасности может скрыть фактическую проблему загрузки или службы.

Быстрые тесты с вашей рабочей станции

Используйте небольшие сетевые тесты, прежде чем изменять ресурсы AWS. В Linux или macOS nc -vz <public-ip> 22 проверяет, завершается ли TCP-порт 22. Для RDP используйте nc -vz <public-ip> 3389 или инструмент проверки портов в Windows. Тайм-аут указывает на проблемы с маршрутизацией, группами безопасности, NACL или вышестоящим брандмауэром. Отказ в соединении больше указывает на ОС инстанса или службу.

Если задействован DNS, разрешите его явно:

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Затем сравните результат с текущим публичным IP в консоли EC2. Elastic IP остаются стабильными, но автоматически назначенные публичные IP могут измениться после остановки/запуска. Это простая причина неработающих runbook и сохраненных профилей RDP.

Если вы используете корпоративный VPN, протестируйте из другой сети, прежде чем редактировать VPC. Некоторые корпоративные сети блокируют исходящий SSH или RDP, а некоторые домашние маршрутизаторы или интернет-провайдеры мешают нестандартным портам. Успешное подключение из другой сети говорит о том, что с инстансом, вероятно, все в порядке.

VPC Reachability Analyzer стоит использовать, когда маршрут не очевиден. Он может смоделировать путь между источником и назначением и указать, где маршрутизация или фильтрация блокирует трафик. Он не исправит плохой SSH-ключ или остановленную службу внутри гостевой ОС, но полезен для отделения проблем проектирования сети AWS от проблем операционной системы.

Журналы потоков также могут помочь, особенно когда есть подозрения на NACL или группы безопасности. Отклоненный поток от вашего IP-клиента к порту 22 или 3389 говорит о том, что пакет достиг отслеживаемого сетевого интерфейса или подсети и был отклонен. Отсутствие потока может означать, что трафик никогда не достиг VPC, адрес неверен, или вы смотрите не на тот ENI, подсеть или временной интервал.

Ведите небольшой runbook доступа для каждой среды: утвержденные диапазоны IP-источников, имя бастиона, требования SSM, имена пользователей по умолчанию для AMI и процедуру восстановительного инстанса. Инциденты с подключением замедляются, когда каждому инженеру приходится заново открывать эти детали из консоли.

Также записывайте, какие подсети намеренно являются частными. Эта единственная заметка предотвращает множество бесполезных отладок, когда кто-то пытается подключиться по SSH напрямую к инстансу, который никогда не был предназначен для доступа в интернет.

Чтение сообщения об ошибке

Connection timed out обычно означает, что пакеты не завершают путь. Проверьте публичный IP, таблицу маршрутизации, интернет-шлюз, источник группы безопасности, правила NACL, корпоративный брандмауэр и то, пытаетесь ли вы напрямую достичь частной подсети.

Connection refused обычно означает, что сетевой путь достиг инстанса, но на этом порту ничего не слушает или ОС отклонила его. В Linux проверьте, запущен ли sshd и слушает ли он порт 22. В Windows проверьте, включен ли RDP и работает ли служба удаленного рабочего стола.

Permission denied (publickey) не является проблемой VPC. Обычно это означает неправильное имя пользователя, неправильный закрытый ключ, отсутствие открытого ключа в authorized_keys, измененные права доступа к домашнему каталогу или несоответствие имени пользователя AMI, например, использование ec2-user для образа Ubuntu вместо ubuntu.

Для Windows RDP ошибки аутентификации часто возникают из-за использования старого расшифрованного пароля администратора после замены инстанса, подключения к неправильному публичному IP после остановки/запуска или переопределения политикой домена прав локального входа.

Пути восстановления, когда вы не можете войти

Если на инстансе установлен агент Systems Manager, профиль экземпляра с разрешениями SSM и сетевой доступ к конечным точкам SSM или интернету, Session Manager обычно является наименее разрушительным путем восстановления. Вы можете просматривать журналы, исправлять правила брандмауэра или восстанавливать authorized_keys, не открывая SSH для всего мира.

Если SSM недоступен, используйте последовательную консоль EC2, где это поддерживается, или отсоедините корневой том и подключите его к восстановительному инстансу в той же зоне доступности. Аккуратно смонтируйте его, исправьте сетевую конфигурацию или конфигурацию SSH, отмонтируйте его и снова подключите к исходному инстансу. Сначала сделайте снимок, чтобы попытка восстановления не ухудшила ситуацию.

Когда подключение не удается, следуйте этому приоритетному контрольному списку: работоспособность инстанса, правильный адрес, правильное имя пользователя/ключ или пароль RDP, группа безопасности, NACL, таблица маршрутизации, брандмауэр ОС и работоспособность службы. Такой порядок не позволит вам изменить пять элементов управления AWS, когда реальная проблема заключается в одном устаревшем ключе или отсутствующем маршруте.