Перемежающийся доступ через AWS Client VPN: проверьте каждую связанную подсеть

Пользователь подключается, открывает внутреннее приложение и получает ответ; коллега на той же конечной точке получает тайм-аут с идентичного ноутбука в той же сети Wi-Fi. Этот шаблон — подпись конечной точки client VPN с более чем одной связанной подсетью, где пути не эквивалентны. Я прохожу это от консоли наружу, потому что две вкладки решают, стоит ли остальное расследование. Ничто в конфигурации клиента этого не объясняет.

Начните с конечной точки и перечислите связи

В консоли VPC откройте Client VPN endpoints, выберите конечную точку и прочитайте вкладку Associations. Каждая связь — это подсеть в зоне доступности, и клиент попадает в ту, которую выберет сервис при построении соединения. Запишите ID подсетей и таблицу маршрутов, которую каждая реально использует, потому что эти два списка и есть сравнение, которое вы собираетесь сделать.

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

Сравните таблицу маршрутов конечной точки с каждой связью

Откройте вкладку Route table на той же конечной точке. У каждого целевого CIDR там есть цель, а в client VPN цель — это связь, а не шлюз. AWS требует запись назначения для каждой связанной подсети, поэтому маршрут, указывающий только на одну из них, делает доступ зависимым от того, где оказалась сессия. Проверьте назначение, которое действительно важно, затем его правило авторизации, потому что маршрут даёт путь, а правило решает, кому можно им пользоваться.

Как только вы сведёте оба слоя в таблицу, сбой трудно не заметить.

Вторая строка — это вся ошибка в большинстве тикетов. Маршрут конечной точки есть, поэтому никто не смотрит дальше, и пакет умирает одним переходом позже внутри VPC.

Проследите каждую подсеть до её действующей таблицы маршрутов

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

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

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

Проверьте правила авторизации, затем обратный путь

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

Обратный путь заслуживает такого же внимания. Соединению peering нужен маршрут в VPC приложения обратно к CIDR клиента, правила групп безопасности, разрешающие трафик на обоих концах, и сетевые ACL, которые его не отбрасывают. Односторонняя доступность, когда ping работает, а рукопожатие TCP нет, обычно указывает на ACL или группу безопасности, а не на VPN.

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

Проверяйте переподключением, а не одним удачным запросом

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

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