Descripción de RPF de unidifusión (enrutadores)
En el caso de las interfaces que transportan tráfico IPv4 o IPv6, puede reducir el impacto de los ataques de denegación de servicio (DS) configurando el reenvío de ruta inversa de unidifusión (RPF). El RPF de unidifusión ayuda a determinar el origen de los ataques y rechaza paquetes de direcciones de origen inesperadas en las interfaces en las que está habilitada la RPF de unidifusión.
Puede proteger una red mediante la aplicación de la función de verificación de RPF de unidifusión en el borde (en interfaces orientadas al cliente) de la red. En un entorno de ISP, esto puede afectar a la red, lo que puede imponerse a una configuración escalada. En caso de que ya haya protegido el borde de su red, un paquete con una dirección IP de origen falsificada ni siquiera aparecerá en una interfaz orientada al núcleo. En este caso, no es necesaria la comprobación de RPF de unidifusión. Habilitar la función RPF de unidifusión puede afectar el rendimiento del plano de control, así que úsela donde sea necesario. Por lo tanto, se recomienda encarecidamente no habilitar esta función en las interfaces del núcleo de red (internas).
Actualmente, en las plataformas PTX, la configuración de la especificación de flujo del BGP (flowspec) crea un filtro implícito para establecer la instancia de VRF. En las plataformas PTX, la búsqueda de filtro precede a la búsqueda de IP de origen/destino. Por lo tanto, la búsqueda de IP de origen y destino se produce dentro del contexto de la instancia de VRF.
Actualmente, en las plataformas PTX, cuando se configura la resolución de ruta inversa de unidifusión (uRPF) y el reenvío basado en filtros (FBF) en una interfaz, el comportamiento predeterminado es que la búsqueda de dirección IP de origen de un paquete entrante se realiza mediante uRPF en la instancia de enrutamiento a la que apunta la interfaz y la búsqueda de dirección IP de destino se realiza en la instancia de enrutamiento especificada por el filtro FBF. Puede usar set forwarding-options no-rpf-fbf-handling para anular este comportamiento predeterminado y, cuando aplique esta configuración, la búsqueda de dirección IP de origen de un paquete entrante se realiza mediante uRPF en la instancia de enrutamiento especificada por el filtro FBF.
RPF de unidifusión y ruta predeterminada
Cuando no se puede elegir la ruta activa de entre las rutas de una tabla de enrutamiento, el enrutador elige una ruta predeterminada. Una ruta predeterminada equivale a una dirección IP de 0.0.0.0/0. Si configura una ruta predeterminada y configura RPF de unidifusión en una interfaz que utiliza la ruta predeterminada, RPF de unidifusión se comportará de manera diferente a como lo haría de otra manera.
Para determinar si la ruta predeterminada utiliza una interfaz, ingrese el show route comando:
user@host> show route address
address es la dirección de salto siguiente de la ruta predeterminada configurada. La ruta predeterminada utiliza las interfaces que se muestran en el resultado del show route comando.
En las siguientes secciones se describe cómo se comporta RPF de unidifusión cuando una ruta predeterminada utiliza una interfaz y cuando una ruta predeterminada no utiliza una interfaz:
- Comportamiento de RPF de unidifusión con una ruta predeterminada
- Comportamiento de RPF de unidifusión sin una ruta predeterminada
- RPF de unidifusión con asimetría de enrutamiento
Comportamiento de RPF de unidifusión con una ruta predeterminada
En todos los enrutadores, excepto aquellos con MPC y el enrutador MX80, el RPF de unidifusión se comporta de la siguiente manera si configura una ruta predeterminada que utilice una interfaz configurada con RPF de unidifusión:
Modo suelto: todos los paquetes se aceptan automáticamente. Por este motivo, recomendamos no configurar el modo RPF suelto de unidifusión en interfaces que utiliza la ruta predeterminada.
Modo estricto: el paquete se acepta cuando la dirección de origen del paquete coincide con cualquiera de las rutas (ya sean predeterminadas o aprendidas) a las que se puede acceder a través de la interfaz. Tenga en cuenta que las rutas pueden tener múltiples destinos asociados; Por lo tanto, si uno de los destinos coincide con la interfaz entrante del paquete, se acepta el paquete.
En todos los enrutadores con MPC y el enrutador MX80, el RPF de unidifusión se comporta de la siguiente manera si configura una ruta predeterminada que utilice una interfaz configurada con RPF de unidifusión:
Modo suelto: se aceptan todos los paquetes, excepto los paquetes cuyo origen se aprende de la ruta predeterminada. Todos los paquetes cuyo origen se aprende de la ruta predeterminada se descartan en el motor de reenvío de paquetes. La ruta predeterminada se trata como si la ruta no existiera.
Modo estricto: el paquete se acepta cuando la dirección de origen del paquete coincide con cualquiera de las rutas (ya sean predeterminadas o aprendidas) a las que se puede acceder a través de la interfaz. Tenga en cuenta que las rutas pueden tener múltiples destinos asociados; Por lo tanto, si uno de los destinos coincide con la interfaz entrante del paquete, se acepta el paquete.
En todos los enrutadores, el paquete no se acepta cuando se cumple alguna de las siguientes condiciones:
La dirección de origen del paquete no coincide con un prefijo de la tabla de enrutamiento.
La interfaz no espera recibir un paquete con este prefijo de dirección de origen.
Comportamiento de RPF de unidifusión sin una ruta predeterminada
Si no configura una ruta predeterminada o si la ruta predeterminada no utiliza una interfaz configurada con RPF de unidifusión, RPF de unidifusión se comportará como se describe en Configuración del modo estricto de RPF de unidifusión y Configuración del modo flexible de RPF de unidifusión. En resumen, RPF de unidifusión sin una ruta predeterminada se comporta de la siguiente manera:
Modo estricto: el paquete no se acepta cuando se cumple alguna de las siguientes condiciones:
El paquete tiene una dirección de origen que no coincide con un prefijo de la tabla de enrutamiento.
La interfaz no espera recibir un paquete con este prefijo de dirección de origen.
Modo suelto: el paquete no se acepta cuando el paquete tiene una dirección de origen que no coincide con un prefijo en la tabla de enrutamiento.
RPF de unidifusión con asimetría de enrutamiento
En general, se recomienda no habilitar RPF de unidifusión en interfaces internas de la red, ya que es probable que las interfaces internas tengan asimetría de enrutamiento. La asimetría de enrutamiento significa que las rutas de salida y retorno de un paquete son diferentes. Los enrutadores en el núcleo de la red tienen más probabilidades de tener rutas inversas asimétricas que los enrutadores en el borde del cliente o proveedor. La Figura 1 muestra RPF de unidifusión en un entorno con asimetría de enrutamiento.
de enrutamiento
En la Figura 1, si habilita RPF de unidifusión en la interfaz so-0/0/0, no se rechaza el tráfico destinado al enrutador A. Si habilita RPF de unidifusión en la interfaz so-1/0/1, se rechaza el tráfico del enrutador A.
Si necesita activar RPF de unidifusión en un entorno de enrutamiento asimétrico, puede utilizar filtros de error para permitir que el enrutador acepte paquetes entrantes que se sabe que llegan por rutas específicas. Para obtener un ejemplo de un filtro de fallas que acepta paquetes con una dirección de origen y destino específica, consulte Configurar RPF de unidifusión.
Configuración del modo estricto de RPF de unidifusión
En el modo estricto, RPF de unidifusión comprueba si el paquete entrante tiene una dirección de origen que coincida con un prefijo de la tabla de enrutamiento y si la interfaz espera recibir un paquete con este prefijo de dirección de origen.
Cuando se configura el modo de ruta activa , se crea una lista de interfaces de salida de solo la ruta activa. Cualquier paquete que venga a estas interfaces se considera válido y se procesa.
Si el paquete entrante no supera la comprobación RPF de unidifusión, no se acepta en la interfaz. Cuando un paquete no se acepta en una interfaz, RPF de unidifusión cuenta el paquete y lo envía a un filtro de error opcional. Si el filtro de errores no está configurado, la acción predeterminada es descartar el paquete de forma silenciosa.
El filtro de error opcional le permite aplicar un filtro a los paquetes que no superan la comprobación RPF de unidifusión. Puede definir el filtro de error para realizar cualquier operación de filtro, incluida la aceptación, el rechazo, el registro, el muestreo o la vigilancia.
Cuando se habilita RPF de unidifusión en una interfaz, la interfaz no acepta paquetes de protocolo de arranque (BOOTP) ni DHCP. Para permitir que la interfaz acepte paquetes BOOTP y DHCP, debe aplicar un filtro de errores que acepte todos los paquetes con una dirección de origen y una dirección de destino de Para obtener un ejemplo de 255.255.255.255. configuración, consulte Configurar RPF de0.0.0.0 unidifusión.
Para obtener más información acerca de cómo definir filtros de error, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y reguladores de tráfico.
Para configurar RPF de unidifusión, incluya la rpf-check instrucción:
rpf-check <fail-filter filter-name>;
Puede incluir esta instrucción en los siguientes niveles de jerarquía:
[edit interfaces interface-name unit logical-unit-number family (inet | inet6)][edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6)]
El uso de RPF de unidifusión puede tener varias consecuencias cuando se implementa con filtros de tráfico:
Los filtros de falla de RPF se evalúan después de los filtros de entrada y antes de los filtros de salida.
Si configura un contador de filtros para los paquetes caídos por un filtro de entrada y desea conocer el número total de paquetes caídos, también debe configurar un contador de filtros para los paquetes caídos por la comprobación RPF.
Para contar los paquetes que no superan la comprobación de RPF y son aceptados por el filtro de error de RPF, debe configurar un contador de filtros.
Si un filtro de entrada reenvía paquetes a cualquier lugar que no sean las tablas de enrutamiento inet.0 o inet6.0, no se realiza la comprobación de RPF de unidifusión.
Si un filtro de entrada reenvía paquetes a cualquier lugar que no sea la instancia de enrutamiento para la que está configurada la interfaz de entrada, no se realiza la comprobación de RPF de unidifusión.
En la lista con viñetas mencionada anteriormente, los puntos primero, penúltimo y último no son aplicables a las plataformas MX porque en las plataformas MX uRPF se procesa antes de la ejecución de los filtros de firewall. La comprobación de uRPF se procesa para la comprobación de direcciones de origen antes de habilitar cualquier acción FBF (reenvío basado en filtros) para interfaces estáticas y dinámicas. Esto se aplica a las familias IPv4 e IPv6.
En enrutadores ACX y serie MX:
El filtro de error uRPF se admite en ACX1000, ACX2000, ACX4000 y ACX500, ACX5048 y ACX5096. El filtro no es compatible con ACX5448, ACX710, ACX7100-32C, ACX7100-48, ACX7509 ni en todos los enrutadores de la serie ACX7000.
- El filtro de errores de uRPF no puede coincidir con los paquetes con errores en la comprobación del puerto de entrada (modo estricto).
- El filtro de error de uRPF puede coincidir con paquetes que fallan en la búsqueda de IP de origen, pero no puede coincidir con paquetes que no logran la comprobación de interfaz de entrada (modo estricto).
- El filtro de error de uRPF solo se aplica a instancias específicas de interfaz del filtro de firewall.
- Los filtros de error de uRPF no admiten acciones de instancia de enrutamiento ni de rechazo.
- La opción rutas factibles no se admite en la serie ACX7000.
Configure el modo estricto de RPF de unidifusión y aplique un filtro de error que permita que la interfaz acepte paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen de 0.0.0.0 y una dirección de destino de 255.255.255.255.
Para configurar RPF de unidifusión en modo estricto:
Configuración del modo flexible de RPF de unidifusión
De forma predeterminada, RPF de unidifusión utiliza el modo estricto. El modo suelto de RPF de unidifusión es similar al modo estricto de RPF de unidifusión y tiene las mismas restricciones de configuración. La única comprobación en modo flexible es si el paquete tiene una dirección de origen con un prefijo correspondiente en la tabla de enrutamiento; El modo suelto no comprueba si la interfaz espera recibir un paquete con un prefijo de dirección de origen específico. Si no se encuentra un prefijo correspondiente, el modo suelto de RPF de unidifusión no acepta el paquete. Al igual que en el modo estricto, el modo suelto cuenta el paquete con errores y, opcionalmente, lo reenvía a un filtro de errores, el cual acepta, rechaza, registra, muestra o controla el paquete.
Cuando se configura el modo de rutas factibles , se crea una lista de interfaces de salida de rutas activas e inactivas. Cualquier paquete que venga a estas interfaces se considera válido y se procesa.
Para configurar el modo RPF suelto de unidifusión, incluya lo siguiente mode:
Configuración del modo flexible de RPF de unidifusión con capacidad para descartar paquetes
El modo suelto de RPF de unidifusión tiene la capacidad de descartar paquetes con la dirección de origen apuntando a la interfaz de descarte. El uso del modo suelto de RPF de unidifusión, junto con el filtrado de ruta nula activada remotamente, proporciona una manera eficiente de descartar paquetes provenientes de fuentes de ataque conocidas. Las políticas de BGP en enrutadores de borde garantizan que los paquetes con direcciones de origen que no son de confianza tengan su próximo salto establecido en una ruta de descarte. Cuando un paquete llega al enrutador con una dirección de origen que no es de confianza, el RPF de unidifusión realiza una búsqueda de ruta de la dirección de origen. Dado que la ruta de dirección de origen apunta a un siguiente salto de descarte, el paquete se descarta y se incrementa un contador. Esta característica se admite tanto en familias de direcciones IPv4 (inet) como IPv6 (inet6).
Para configurar el modo flexible RPF de unidifusión con la capacidad de descartar paquetes, incluya la rpf-loose-mode-discard family (inet | inet6) instrucción en el nivel de [edit forwarding-options] jerarquía:
rpf-loose-mode-discard {
family {
inet;
}
}
En este ejemplo, no se requiere ninguna configuración especial más allá de la inicialización del dispositivo.
Configure el modo holgado de RPF de unidifusión y aplique un filtro de error que permita que la interfaz acepte paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen de 0.0.0.0 y una dirección de destino de 255.255.255.255.
Para configurar el modo flexible de RPF de unidifusión con la capacidad de descartar paquetes:
Configurar RPF de unidifusión en una VPN
Puede configurar RPF de unidifusión en una interfaz VPN habilitando RPF de unidifusión en la interfaz e incluyendo la interface instrucción en el [edit routing-instances routing-instance-name] nivel de jerarquía.
Puede configurar RPF de unidifusión solo en las interfaces que especifique en la instancia de enrutamiento. Esto significa lo siguiente:
Para VPN de capa 3, se admite RPF de unidifusión en la interfaz del enrutador CE.
El RPF de unidifusión no se admite en interfaces orientadas al núcleo.
Para instancias de enrutamiento de enrutador virtual, se admite RPF de unidifusión en todas las interfaces que especifique en la instancia de enrutamiento.
Si un filtro de entrada reenvía paquetes a cualquier lugar que no sea la instancia de enrutamiento para la que está configurada la interfaz de entrada, no se realiza la comprobación de RPF de unidifusión.
Configure RPF de unidifusión en una interfaz VPN de capa 3:
[edit interfaces]
so-0/0/0 {
unit 0 {
family inet {
rpf-check;
}
}
}
[edit routing-instance]
VPN-A {
interface so-0/0/0.0;
}
Configuración de RPF de unidifusión
Configure el modo estricto de RPF de unidifusión y aplique un filtro de error que permita que la interfaz acepte paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen de 0.0.0.0 y una dirección de destino de 255.255.255.255.
[edit firewall]
filter rpf-special-case-dhcp-bootp {
term allow-dhcp-bootp {
from {
source-address {
0.0.0.0/32;
}
address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-bootp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp-bootp;
}
}
}
}
Ver también
Comportamiento específico de la plataforma
Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.
Utilice la siguiente tabla para revisar el comportamiento específico de la plataforma para su plataforma:
Plataforma |
Diferencia |
|---|---|
Enrutadores de la serie ACX en Junos OS Evolved |
Cuando la IP de origen se resuelve a través de un grupo ECMP, RPF funciona en modo flexible mediante la anulación de la configuración estricta de uRPF de la interfaz en la que ingresó el paquete. |