Войти
Пересылка по обратному пути (RPF) - это метод, используемый в современных маршрутизаторах для обеспечения беспрерывной пересылки многоадресных пакетов при многоадресной маршрутизации и для предотвращения подмены IP-адреса при одноадресной маршрутизации.
При стандартной одноадресной IP-маршрутизации маршрутизатор пересылает пакет от источника для продвижения по дереву распределения и предотвращения петель маршрутизации. Напротив, состояние многоадресной пересылки маршрутизатора работает более логично за счет организации таблиц на основе обратного пути, от получателя обратно к корню дерева распределения в источнике многоадресной рассылки. Этот подход известен как пересылка по обратному пути.
Многоадресный RPF, обычно обозначаемый просто как RPF, используется в сочетании с протоколом многоадресной маршрутизации, таким как Multicast Source Discovery Protocol или Protocol Independent Multicast, чтобы гарантировать пересылку многоадресных пакетов без петель. При многоадресной маршрутизации решение о пересылке трафика основывается на адресе источника, а не на адресе назначения, как при одноадресной маршрутизации. Это достигается за счет использования либо специальной таблицы многоадресной маршрутизации, либо таблицы одноадресной маршрутизации маршрутизатора.
Когда многоадресный пакет входит в интерфейс маршрутизатора, маршрутизатор просматривает список сетей, доступных через этот интерфейс (т. Е. Проверяет пути, по которым пакет мог прибыть). Если маршрутизатор находит соответствующую запись маршрутизации для IP-адреса источника многоадресного пакета, проверка RPF проходит, и пакет пересылается на все другие интерфейсы, которые участвуют в этой группе многоадресной рассылки. Если проверка RPF терпит неудачу, пакет отбрасывается. В результате решение о пересылке пакета принимается на основе обратного пути пакета, а не прямого пути. За счет пересылки только тех пакетов, которые поступают в интерфейс, который также содержит запись маршрутизации для источника пакета, предотвращаются петли.
Это критически важно в топологиях избыточной многоадресной рассылки. Поскольку один и тот же многоадресный пакет может достигать одного и того же маршрутизатора через несколько интерфейсов, проверка RPF является неотъемлемой частью принятия решения о пересылке пакетов или нет. Если маршрутизатор переадресовал все пакеты, которые поступают через интерфейс A, на интерфейс B, а также переадресовал все пакеты, поступающие через интерфейс B, на интерфейс A, и оба интерфейса получат один и тот же пакет, это создаст петлю маршрутизации, в которой пакеты будут пересылаться в обоих направлениях до тех пор, пока их IP TTL истекает. Лучше избегать петель маршрутизации, поскольку они излишне потребляют сетевые ресурсы.
В основе проверки RPF лежат следующие предположения:
Если первое предположение неверно, проверка RPF завершится неудачно, поскольку в качестве запасного варианта она зависит от таблицы одноадресной маршрутизации маршрутизатора. Если второе предположение неверно, проверка RPF будет отклонять многоадресный трафик на всех, кроме кратчайшего пути от отправителя к маршрутизатору, что приведет к неоптимальному дереву многоадресной рассылки. В случаях, когда ссылки являются однонаправленными, подход обратного пути может вообще не работать.
Unicast 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.
