Проверка источника/назначения — это один шлюз, а не весь путь VPN

VPN завершается на инстансе EC2, вы можете достучаться до адреса туннеля этого инстанса, а трафик, который должен был пройти через него к другому частному хосту, исчезает. Это два разных теста, и их смешение тратит часы. Первый спрашивает, можете ли вы достичь инстанса; второй требует, чтобы он пересылал трафик для назначения, которое не является его собственным, а для этого нужны пересылка в Linux, политика брандмауэра, маршрут на дальней стороне и разрешение на уровне AWS, не имеющее ничего общего с гостевой операционной системой. Ничто в консоли не обращает внимания на эту разницу. Симптом выглядит как сбой маршрутизации, и обычно это не так.

Разделите два теста, прежде чем что-либо менять

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

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

Запишите путь, прежде чем трогать настройку

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

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

Четыре границы, и проверка — лишь одна из них

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

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

Трансляция меняет то, какой источник видит назначение

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

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

Проверяйте с исходного клиента, затем сохраните изменение

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

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