Обратная пересылка по обратному пути

Мультикаст-RPF, часто просто называемая RPF, применяется совместно с мультикастовыми протоколами маршрутизации, такими как MSDP, PIM-SM и PIM-DM, для обеспечения отсутствия циклов при пересылке мультикастных пакетов. В мультикаст-маршрутизации решение о пересылке принимается на основе адреса источника, а не адреса назначения, как это происходит в уникаст-маршрутизации. Это реализуется либо через отдельную таблицу мультикаст-маршрутизации, либо через обычную таблицу уникаст-маршрутизации маршрутизатора.

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

Это имеет ключевое значение при избыточных мультикастовых топологиях. Поскольку одно и то же мультикастовое сообщение может достичь одного маршрутизатора по разным интерфейсам, проверка RPF является неотъемлемой частью процесса принятия решения о необходимости дальнейшей передачи пакета. Если маршрутизатор пересылает все пакеты, полученные на интерфейсе A, на интерфейс B и наоборот, при этом оба интерфейса получают одинаковый пакет, возникает классическая маршрутизационная петля, при которой пакеты пересылаются в обоих направлениях до тех пор, пока не истечёт их IP TTL. Даже несмотря на то, что потеря TTL со временем предотвращает «вечное» циркулирование пакета, любые виды циклов маршрутизации следует избегать, так как они, пусть и временно, отрицательно влияют на производительность сети.

Основные предпосылки проверки RPF заключаются в следующем:

• таблица уникаст-маршрутизации корректна и сошлась;
• путь, используемый от отправителя к маршрутизатору, и обратный путь от маршрутизатора к отправителю симметричны.

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

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

uRPF, как определено в англ. RFC 3704, является развитием концепции запрета приёма трафика из заведомо невалидных сетей на тех интерфейсах, через которые такой трафик не должен поступать. Изначально (см. англ. RFC 2827) идея заключалась в блокировании трафика на интерфейсе, если он поступает с частных адресов (определённых в англ. RFC 1918). Для многих организаций разумной практикой считается запрещать распространение частных адресов в своих сетях, если это не предусмотрено явно. Это особенно полезно для магистральных сетей Интернет — фильтрация пакетов с явно ложными адресами источника помогает сократить случаи подделки IP-адресов, которая часто используется при DoS, DDoS-атаках и сетевых сканированиях для сокрытия источника.

uRPF расширяет этот подход, используя знания, которыми располагает любой маршрутизатор для своей работы: для проверки используется его основная таблица маршрутизации (Routing Information Base, RIB) или таблица пересылки (Forwarding Information Base, FIB). Это позволяет более строго ограничить допустимые адреса источника, ожидаемые на данном интерфейсе. Пакеты пересылаются только в том случае, если они поступили с интерфейса, который маршрутизатор определил как лучший путь к источнику пакета, что гарантирует:

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

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

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

англ. RFC 3704 подробно рассматривает, как базовая концепция «Адрес источника должен присутствовать в таблице маршрутизации для данного интерфейса» (известная как строгий режим обратной пересылки, strict reverse path forwarding) может быть расширена для поддержки более свободных режимов, позволяющих сохранить часть преимуществ даже при допущении некоторой асимметрии.

RPF нередко ошибочно трактуют как Reverse Path Filtering («фильтрация по обратному пути»), особенно применительно к уникаст-маршрутизации. Такая ошибка понятна, так как при использовании RPF в уникаст-маршрутизации, как описано в англ. RFC 3704, трафик либо допускается, либо отбрасывается в зависимости от прохождения проверки RPF. Возникает ощущение, что трафик отфильтровывается, если не прошёл проверку, однако, согласно англ. RFC 3704, корректное понимание — это пересылка (forwarding) трафика, прошедшего проверку RPF. Примеры корректного применения можно найти в документации Juniper^[1], Cisco^[2], OpenBSD^[3] и, главное, в англ. RFC 3704, где описано применение RPF в уникасте.

Хотя uRPF может использоваться в качестве механизма для фильтрации входящего трафика, такой фильтр достигается именно благодаря механизму пересылки по обратному пути.