В виртуальной сети несколько маршрутов совпадают с адресом назначения. Как выбирается маршрут?
Сначала выбирается маршрут с наиболее длинным совпадающим префиксом — то есть наиболее специфичный маршрут. Например, маршрут к сети /24 имеет приоритет над маршрутом к более широкой сети /16, если адрес назначения входит в обе. Если несколько маршрутов имеют одинаковую длину префикса, используется дополнительное правило конкретной платформы: приоритет, метрика, тип маршрута или иной порядок разрешения конфликта.
IP-маршрутизация должна была позволять пересылать пакеты как в конкретные подсети, так и в любые сети, для которых нет отдельной записи. Поэтому таблицы маршрутизации поддерживают широкие маршруты, например маршрут по умолчанию, и более узкие маршруты для отдельных диапазонов адресов.
Правило наиболее длинного префикса появилось как способ совместить масштабируемость с точностью. Администратору не требуется описывать отдельное направление для каждого адреса: достаточно задать общий маршрут и при необходимости переопределить его более специфичным.
Представим виртуальную сеть, в которой есть маршрут по умолчанию через интернет-шлюз, маршрут к корпоративной сети через VPN и отдельный маршрут к подсети базы данных через приватное соединение. Один и тот же адрес назначения может попадать сразу под несколько таких диапазонов.
Если выбрать маршрут случайно или только по порядку добавления, трафик может уйти через интернет вместо VPN, обойти ожидаемый межсетевой контроль или попасть в несуществующее направление. Это приводит к недоступности сервисов, нарушению требований безопасности и трудно диагностируемым задержкам.
Маршрутизатор сопоставляет IP-адрес назначения с каждым маршрутом и оставляет подходящие записи. Затем выбирается запись с максимальным количеством фиксированных битов сетевого префикса. Поэтому /32 обычно точнее /24, /24 точнее /16, а любой конкретный маршрут точнее маршрута 0.0.0.0/0.
После выбора маршрута маршрутизатор использует его следующий узел или целевой интерфейс. Само наличие более специфичного маршрута не гарантирует успешную доставку: следующий узел должен быть достижим, а правила безопасности, обратный маршрут и состояние соединения должны позволять обмен трафиком.
Если совпало несколько маршрутов с одинаковым префиксом, универсального поведения для всех облачных платформ нет. В одних системах применяется административный приоритет, в других — метрика, тип источника маршрута или внутренняя политика платформы; это нужно проверять по документации конкретного облака.
Важно отличать выбор маршрута от фильтрации трафика. Таблица маршрутизации отвечает на вопрос «куда отправить пакет», но не решает, разрешён ли он правилами группы безопасности, сетевого ACL, межсетевого экрана или политикой сервиса.
Слишком широкие маршруты упрощают конфигурацию, но могут перехватить трафик, который должен идти через специализированный канал. Слишком большое количество узких маршрутов даёт точный контроль, однако усложняет сопровождение, повышает риск конфликтов и может упереться в ограничения платформы.
В облачной сети приложение должно обращаться к корпоративному API через VPN. При этом в таблице маршрутов уже был маршрут по умолчанию через NAT-шлюз. После появления VPN запросы продолжали уходить в NAT, потому что для корпоративного диапазона не существовало более специфичного маршрута.
Рассматривались два варианта. Можно было изменить маршрут по умолчанию и направить через VPN весь исходящий трафик, но это увеличивало зависимость от VPN и усложняло доступ к публичным сервисам. Другой вариант — добавить маршрут только для корпоративного CIDR через VPN; он сохранял обычный путь для остальных адресов и ограничивал область изменений.
Выбрали второй вариант. После добавления более специфичного маршрута корпоративный трафик стал направляться через VPN, а обращения к публичным адресам остались за NAT-шлюзом. Дополнительно проверили обратные маршруты и правила фильтрации, поскольку одного правильного направления в одну сторону недостаточно для рабочего соединения.
Ответ: Нет. Он выигрывает только среди маршрутов, которые действительно установлены в рабочую таблицу маршрутизации и применимы к данному интерфейсу или виртуальной сети. На результат также могут влиять таблица, связанная с конкретной подсетью, политика платформы, отсутствие доступного следующего узла и специальные правила обработки трафика.
Кроме того, одинаково специфичные маршруты разрешаются по платформенным правилам. Поэтому нельзя переносить предположения о приоритете или метрике из одной облачной системы в другую без проверки документации и фактической таблицы маршрутов.
Ответ: Пакет должен пройти весь путь в обе стороны. Даже если исходный трафик направлен правильно, ответ может не иметь обратного маршрута, быть заблокирован сетевым ACL или межсетевым экраном либо потеряться из-за несовместимой трансляции адресов.
Для диагностики проверяют маршрут в прямом и обратном направлениях, правила фильтрации, наличие NAT при переходе между адресными пространствами и фактический следующий узел. Маршрутизация определяет направление, но не заменяет контроль доступа и проверку обратного пути.
Ответ: Если приватный диапазон описан слишком узко или вообще не добавлен в таблицу маршрутов, адрес назначения перестанет совпадать со специальным маршрутом. Тогда сработает менее специфичный маршрут, часто маршрут по умолчанию через интернет-шлюз или NAT.
Например, маршрут к одной подсети не охватывает соседнюю подсеть того же корпоративного диапазона. В результате часть адресов будет идти через VPN, а часть — через публичный путь. Предотвращают такую ошибку проверкой CIDR, просмотром эффективной таблицы маршрутов и тестированием адресов на границах диапазона.