Переадресация по обратному пути

Пересылка по обратному пути (RPF) — это метод, используемый в современных маршрутизаторах с целью обеспечения пересылки многоадресных пакетов без петель при многоадресной маршрутизации и предотвращения подмены IP-адреса при одноадресной маршрутизации.

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

Многоадресный РПФ

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

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

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

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

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

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

Одноадресный РПФ

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

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

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

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

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

Строгий режим

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

Возможный режим

В допустимом режиме FIB поддерживает альтернативные маршруты к заданному IP-адресу. Если входящий интерфейс совпадает с каким-либо маршрутом, связанным с IP-адресом, пакет пересылается. В противном случае пакет отбрасывается.

Свободный режим

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

Фильтрация и пересылка

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

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

См. также

• Наводнение (компьютерные сети)

Внешние ссылки

• Фильтрация сетевого входа: борьба с атаками типа «отказ в обслуживании», в которых используется подмена IP-адреса источника . РФК   2827 .
• Входная фильтрация для многосетевых сетей . РФК   3704 .