Кратко

  • Строгая проверка обратного пути может отвергнуть законный пакет, если интерфейс получения не совпадает с интерфейсом лучшего обратного маршрута к адресу источника. RFC 3704 разбирает именно этот конфликт.
  • Feasible-path RPF допускает известные альтернативные маршруты, если они согласованно распространяются; свободная RPF терпимее к асимметрии, но теряет значительную часть доказательств направления источника.

Маршрутизатор проверил путь назад

Сеть подключена к двум провайдерам и отправляет пакет через провайдера B. Адрес источника относится к префиксу, который сеть вправе использовать. Более удалённый маршрутизатор принимает пакет на интерфейсе B, но его таблица указывает, что лучший путь к источнику проходит через провайдера A. При строгой RPF пакет будет отброшен. Маршрутизатор не установил, кто его отправил: он сопоставил входной интерфейс со своим представлением о маршруте.

RFC 3704, опубликованный в марте 2004 года как Best Current Practice 84, обновил RFC 2827 (BCP 38) о фильтрации входящего трафика. Цель — ограничить подмену адресов источника — осталась прежней. Сложность вносят многопровайдерные сети и асимметричные пути: фактический путь в одну сторону может отличаться от того, который маршрутизация выбрала бы для обратного направления.

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

Альтернативные маршруты должны быть известны проверяющим

Feasible-path RPF добавляет к проверке альтернативные маршруты, а не ограничивается единственным лучшим маршрутом в FIB. В многопровайдерной сети это позволяет не отвергать пакет только потому, что в данный момент предпочтён другой путь.

Но список не является полной картой всех возможных маршрутов. RFC 3704 требует, чтобы нужные объявления последовательно доходили до каждого маршрутизатора, который выполняет проверку. Из-за route-map или политики один провайдер может знать префикс, а другой — нет. Если объявление отфильтровано, фильтр может отбросить и пакет. Значит, локальное правило зависит от решений нескольких административных доменов.

Свободная RPF идёт в обратную сторону компромисса: она проверяет лишь наличие маршрута к источнику, а не то, указывает ли маршрут на входной интерфейс. Это допускает асимметрию, но может пропустить поддельный адрес, если он маршрутизируется. Маршрут по умолчанию ещё сильнее ослабляет тест, если реализация не обрабатывает его отдельно. Поэтому RFC 3704 не считает такую проверку основным фильтром на стыке клиента и провайдера; она пригоднее для отсева немаршрутизируемых или зарезервированных источников выше по сети либо для проверки, фильтрует ли другая сеть хотя бы часть трафика.

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

Чем ближе фильтр к исходному узлу, тем точнее он может проверить, какие адреса разрешено использовать подключённому устройству. Дальний маршрутизатор обычно способен установить лишь то, что источник может принадлежать достижимому префиксу. Несколько уровней фильтрации улучшают прослеживаемость, но не устанавливают конкретного злоумышленника и не доказывают повсеместное внедрение. RFC 8704, опубликованный в 2020 году, обновил RFC 3704 методами enhanced feasible-path uRPF. Это свидетельствует о продолжающейся работе над компромиссом, а не об универсальном внедрении или решении каждой топологии.

Практический вопрос не в том, какой режим всегда лучше. Важно, что именно проверяется: лучший обратный маршрут, набор альтернатив или только наличие любого маршрута. Результат зависит от таблицы и точки проверки. RFC 3704 сделал полноту маршрутной информации совместной эксплуатационной обязанностью.

Источники