EC2 в зонах доступности: проверьте маршрутизацию до VPN

Прежде чем устанавливать программное обеспечение VPN между двумя экземплярами EC2, ответьте на один вопрос: находятся ли они в одном VPC? Если да, частный путь уже существует, и размещение в разных зонах этого не меняет. Большая часть работы в этой ситуации — подтвердить, какую таблицу маршрутов фактически использует каждая подсеть, а затем выяснить, была ли сбой вообще проблемой маршрутизации. Туннель обычно является неверным ответом на этот конкретный вопрос.

Проверка 1: один и тот же VPC или разные VPC

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

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

Проверка 2: что говорят таблицы маршрутов подсетей

Запишите схему с реальными значениями. VPC с адресом 10.60.0.0/16 с подсетями 10.60.1.0/24 и 10.60.2.0/24 даёт экземплярам 10.60.1.10 и 10.60.2.20 путь через локальный маршрут VPC.

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

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

Проверка 3: маршрутизация или авторизация

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

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

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

Проверка 4: действительно ли нужно отдельное подключение

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

Помните и о том, чем VPC не является. Это не расширение домашнего сегмента Ethernet. Приложению, которое зависит от обнаружения широковещанием, требуется отдельная оценка. Это пробел в проектировании, а не ошибка маршрутизации.

Проверка 5: вопрос шифрования

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

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

Что записать

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

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