Elastic IP в EC2 — не частный VPN-адрес инстанса

У инстанса есть частный адрес, Elastic IP связан с ним, и маршрут для этого публичного /32 добавляется в VPN в надежде, что эти два станут одним и тем же. Не становятся. Elastic IP — это трансляция, выполняемая вне гостя, интернет-шлюзом, над трафиком, который идёт по интернет-пути. Операционная система гостя никогда не видит этот адрес настроенным на интерфейсе. Его добавление на туннельный интерфейс не воспроизводит вышестоящую трансляцию и создаёт вторую, противоречивую идентичность для той же машины.

Два адреса, один инстанс

Сетевой интерфейс инстанса держит частный адрес внутри VPC, и это тот адрес, который знает гость. Elastic IP связан с тем же интерфейсом, но живёт на публичной стороне отображения.

Всё, что достигает инстанса через интернет, приходит транслированным на частный адрес. Всё, что инстанс отправляет в интернет, уходит с Elastic IP в качестве источника — снова из-за этой трансляции.

Внутри гостя существует один адрес. Снаружи — два. Эта асимметрия объясняет большую часть путаницы в этой области. Гость не может настроить то, что транслирует шлюз. Он может отвечать только на том адресе, который действительно у него есть.

Что на самом деле делает интернет-шлюз

Документация AWS об интернет-шлюзе описывает схему: инстанс знает свой частный адрес IPv4, а шлюз обеспечивает соответствующую трансляцию в публичный IPv4 или Elastic IP для трафика на интернет-пути.

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

Именно поэтому частный пакет VPN, адресованный публичному /32, не переосмысливается как частный пакет на локальный адрес гостя. Пакет идёт по маршруту, которому соответствует, а тот отправляет его на интернет-шлюз, и поведение шлюза зависит от того, разрешён ли путь в обоих направлениях.

Почему трюк с туннельным интерфейсом не работает

Назначение Elastic IP туннельному интерфейсу требует от гостя обращаться с публичным адресом как с локальным. Теперь на один адрес претендуют две вещи: трансляция шлюза на интернет-пути и локальный интерфейс внутри туннеля. У обратного трафика нет согласованного ответа, какая из них действует.

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

Адрес никогда не был проблемой. Проблемой был выбор пути.

Три цели, три схемы

Если цель — публичная конечная точка VPN, Elastic IP является правильным инструментом: удалённые партнёры подключаются к ней через интернет, а шифрованный транспорт завершается на инстансе. Внутренний трафик приложения затем использует частный адрес.

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

Если цель — стабильная публичная идентичность выхода для пользователей VPN, это схема NAT на стороне выхода, а не адрес на туннеле клиента. Три похоже звучащие цели дают три разные диаграммы, и только одна из них предполагает размещение Elastic IP в новом месте.

Проверьте выбранный путь

Для частного доступа убедитесь, что маршрут VPN покрывает частный префикс, таблица маршрутов VPC возвращает трафик в туннель, группа безопасности разрешает источник клиента, а собственный брандмауэр клиента разрешает ответ. Затем проверьте один реальный запрос вместо ping.

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

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