Juegos de reglas para equilibradores de carga
Utilice juegos de reglas compuestos por acciones que se aplican al tráfico del listener de un equilibrador de carga.
Un juego de reglas es un juego de reglas con nombre asociado a un equilibrador de carga y que se aplica a uno o más listeners de dicho equilibrador de carga. Para aplicar un juego de reglas a un listener, primero debe crear el juego de reglas que contiene las reglas. Las reglas son objetos que representan acciones que se aplican al tráfico dirigido a un listener de equilibrador de carga. El juego de reglas se convierte en parte de la configuración del equilibrador de carga. Se puede especificar el juego de reglas que se va a utilizar al crear o actualizar un listener para el equilibrador de carga.
Se pueden incluir los siguientes tipos de reglas en un juego de reglas:
Reglas de control de acceso, que restringen el acceso a los recursos de la aplicación según el origen de la solicitud.
Reglas de método de acceso, que especifican los métodos HTTP permitidos.
Reglas de redireccionamiento de URL, que direccionan las solicitudes HTTP entrantes a una URL de destino diferente.
Reglas de cabecera de solicitud y respuesta, que agregan, modifican o eliminan cabeceras de solicitud o respuesta HTTP.
Reglas de cabecera HTTP, que especifican el tamaño de la cabecera HTTP y los caracteres permitidos en las cabeceras.
Reglas de máximo de conexiones de listener, que especifican el máximo de conexiones IP para un listener.
Los juegos de reglas solo se aplican a listeners HTTP.
Aplique un juego de reglas existente al editar un listener. Puede aplicar el mismo juego de reglas a diversos listeners del mismo equilibrador de carga.
Los juegos de reglas no se comparten entre equilibradores de carga. Para utilizar el mismo juego de reglas en otro equilibrador de carga, debe crearse un nuevo juego de reglas idéntico en ese equilibrador de carga.
Se permiten hasta 20 reglas en un juego de reglas. Se puede asociar un máximo de 50 reglas a un equilibrador de carga.
Puede realizar las siguientes tareas de gestión de juegos de rutas de acceso:
Mostrar los juegos de reglas de un equilibrador de carga.
Cree un nuevo juego de reglas para un equilibrador de carga.
Obtener detalles de un juego de reglas.
Editar la configuración de un juego de reglas.
Suprimir un juego de reglas de un equilibrador de carga.
Para obtener más información sobre la gestión de los listeners del equilibrador de carga, consulte Listeners.
Reglas de control de acceso
Las reglas de control de acceso permiten acceder a recursos de la aplicación en función de las condiciones de coincidencia de dirección IP o rango de direcciones especificadas por el usuario. Si no se especifica ninguna regla de control de acceso, la regla predeterminada será permitir todo el tráfico. Si se agregan reglas de control de acceso, el equilibrador de carga denegará todo tráfico que no coincida con las reglas.
El servicio solo acepta cadenas con formato de enrutamiento entre dominios sin clase (CIDR) (x.x.x.x/y o x:x::x/y
) para la condición de coincidencia.
Especifique 0.0.0.0/0
o ::/0
para que coincida con todo el tráfico entrante.
Solo las regiones del gobierno de EE. UU. en la nube permiten valores IPv6.
Reglas de método de acceso
Las reglas de método de acceso especifican los métodos HTTP permitidos en el listener asociado. El equilibrador de carga no reenvía una solicitud no permitida a los servidores backend y devuelve una respuesta 405 Method Not Allowed
con una lista de los métodos permitidos. Sólo se puede asociar una lista de métodos permitidos a un listener concreto.
Por defecto, solo se pueden especificar los métodos HTTP estándar definidos en el registro de método HTTP. La lista de métodos HTTP es extensible. Si necesita configurar métodos HTTP personalizados, póngase en contacto con My Oracle Support para eliminar la restricción de su arrendamiento. La aplicación de backend debe poder gestionar los métodos especificados.
La siguiente lista muestra los métodos HTTP por defecto:
ACL | BASELINE-CONTROL | ENLACE |
CHECKIN | CHECKOUT | CONNECT |
COPY | DELETE | GET |
HEAD | LABEL | LINK |
LOCK | MERGE | MKACTIVITY |
MKCALENDAR | MKCOL | MKREDIRECTREF |
MKWORKSPACE | MOVE | OPTIONS |
ORDERPATCH | PATCH | POST |
PRI | PROPFIND | PROPPATCH |
PUT | REBIND | REPORT |
SEARCH | TRACE | UNBIND |
UNCHECKOUT | UNLINK | UNLOCK |
UPDATE | UPDATEREDIRECTREF | VERSION-CONTROL |
Reglas de redirección de URL
Las reglas de redireccionamiento de URL especifican cómo enrutar las solicitudes HTTP entrantes a una URL de destino diferente. Las reglas de redireccionamiento de URL solo se aplican a listeners HTTP. Cada regla de redireccionamiento se configura para un listener concreto y una ruta especificada. Un listener solo puede tener una regla de redireccionamiento para una ruta URL entrante.
Al crear una regla de redireccionamiento de URL, se especifica la cadena de ruta de acceso y la condición de coincidencia que utiliza el servicio para evaluar una URL entrante para el redireccionamiento. También puede definir la URL de redirección y el código de respuesta.
Evaluación de cadena de ruta de acceso entrante
Se especifica la cadena de ruta de acceso, o patrón, que se evaluará en la URL entrante. Por ejemplo:
/video
También se especifica la condición de coincidencia que se aplicará al evaluar la URL entrante para el redireccionamiento. Los tipos de coincidencia disponibles son:
- FORCE_LONGEST_PREFIX_MATCH
El sistema busca una cadena de ruta de acceso de regla de redireccionamiento con la mejor coincidencia más larga de la parte inicial de la ruta URL entrante.
- EXACT_MATCH
La ruta URL entrante debe coincidir exactamente con la cadena de ruta de acceso especificada.
- PREFIX_MATCH
La parte inicial de la ruta URL entrante debe coincidir exactamente con la cadena de ruta de acceso especificada.
- SUFFIX_MATCH
La parte final de la ruta URL entrante debe coincidir exactamente con la cadena de ruta de acceso especificada.
La cadena de ruta de acceso de URL entrante no puede incluir una consulta.
Construcción de URL de redirección
Se define la URL de redireccionamiento aplicada a la solicitud original. Las reglas de redireccionamiento de URL reconocen los siguientes componentes de URL:
<protocol>://<host>:<port>/<path>?<query>
Puede especificar una cadena literal o proporcionar un token para cualquier componente. Los tokens extraen los valores de la URL de solicitud HTTP entrante. Los tokens distinguen entre mayúsculas/minúsculas. Por ejemplo, {host}
es un token válido, pero {HOST}
no.
- Protocolo
Protocolo HTTP que se utilizará en la URL de redirección. Los valores válidos son HTTP y HTTPS.
El token
{protocol}
extrae el protocolo de la URL de solicitud HTTP entrante. Es el único token válido para esta propiedad. - Host
Nombre de dominio o dirección IP válidos que se va a utilizar en la URL de redirección.
El token
{host}
extrae el host de la URL de solicitud HTTP entrante. Todos los tokens de redirección de URL son válidos para esta propiedad. Cualquier token se puede utilizar más de una vez.Las llaves {} son válidas en esta propiedad solo para rodear tokens.
- Puerto
Puerto de comunicación que se utilizará en la URL de redirección. Los valores válidos son números enteros del 1 al 65535.
El token
{port}
extrae el puerto de la URL de solicitud HTTP entrante. Es el único token válido para esta propiedad. - Ruta
Ruta de URL de HTTP que se va a utilizar en la URL de redirección. Para omitir la ruta de la URL de redireccionamiento, ajuste este valor en una cadena vacía.
El token
{path}
extrae la cadena de ruta desde la URL de solicitud HTTP entrante. Todos los tokens de redirección de URL son válidos para esta propiedad. Cualquier token se puede utilizar más de una vez.Si la cadena de ruta de acceso no empieza por el token
{path}
, debe empezar por una barra inclinada/. - Consulta
Cadena de consulta que se va a utilizar en la URL de redirección. Para omitir todos los parámetros de consulta entrantes de la URL de redireccionamiento, ajuste este valor a una cadena vacía.
El token
{query}
extrae la cadena de consulta de la URL de solicitud HTTP entrante. Todos los tokens de redirección de URL son válidos para esta propiedad. Cualquier token se puede utilizar más de una vez.Si la cadena de consulta no empieza por el elemento
{query}
, debe empezar por un signo de interrogación.Se pueden especificar diversos parámetros para consulta como una sola cadena. Separe cada parámetro de consulta con un ampersand &.
Si la cadena de consulta especificada da como resultado una URL de redirección que termina por? o &, el último carácter se trunca. Por ejemplo, si la dirección URL entrante es
http://host.com:8080/documents
y el valor de la propiedad de consulta es?lang=en&{query}
, la URL de redirección eshttp://host.com:8080/documents?lang=en
. El sistema trunca el ampersand final & porque la URL entrante no incluye ningún valor para sustituir el token{query}
.
Si no se especifica un valor para al menos el campo del componente URL, el bucle de redirección se puede generar.
Construcción manual de URL de redirección
La consola proporciona campos de entrada de texto para cada componente de URL. También puede especificar manualmente la URL de redirección completa.
Puede mantener los caracteres literales de un token al especificar valores para las propiedades de ruta y consulta de la URL de redirección. Utilice una barra invertida \ como carácter de escape para los caracteres \, { y }. Por ejemplo, si la URL de solicitud HTTP entrante es /video
, el valor de propiedad de ruta de acceso /example{path}123\{path\}
aparecerá en la URL de redirección creada como /example/video123{path}
.
Ejemplos de ruta de acceso y cadena de consulta:
- /example/video/123 aparece como
/example/video/123
en la URL de redirección. - /example{path} aparece como
/example/video/123
en la URL de redirección cuando/video/123
es la ruta de la URL de solicitud HTTP entrante. - {path}/123 aparece como
/example/video/123
en la URL de redirección cuando/example/video
es la ruta de la URL de solicitud HTTP entrante. - {path}123 aparece como
/example/video123
en la URL de redirección cuando/example/video
es la ruta de la URL de solicitud HTTP entrante. - /{host}/123 aparece como
/example.com/123
en la URL de redirección cuandoexample.com
es el nombre de host de la URL de solicitud HTTP entrante. - /{host}/{port} aparece como
/example.com/123
en la URL de redirección cuandoexample.com
es el nombre de host y123
es el puerto de la URL de solicitud HTTP entrante. - /{query} aparece como
/lang=en
en la URL de redirección cuando la consulta eslang=en
en la URL de solicitud HTTP entrante. - lang=en&time_zone=PST aparece como
lang=en&time_zone=PST
en la URL de redirección. - {query} aparece como
lang=en&time_zone=PST
en la URL de redirección cuandolang=en&time_zone=PST
es la cadena de consulta de la solicitud HTTP entrante. Si la solicitud HTTP entrante no tiene parámetros de consulta, el token{query}
se presenta como una cadena vacía. - lang=en&{query}&time_zone=PST aparece como
lang=en&country=us&time_zone=PST
en la URL de redirección cuandocountry=us
es la cadena de consulta de la solicitud HTTP entrante. Si la solicitud HTTP entrante no tiene parámetros de consulta, este valor se representa comolang=en&time_zone=PST
. - protocol={protocol}&hostname={host} aparece como
protocol=http&hostname=example.com
en la URL de redirección cuando el protocolo eshttp
y el nombre de host esexample.com
en la solicitud HTTP entrante. - port={port}&hostname={host} aparece como
port=8080&hostname=example.com
en la URL de redirección cuando el puerto es8080
y el nombre de host esexample.com
en la URL de solicitud HTTP entrante.
Código de respuesta
Puede especificar el código de estado HTTP que se debe devolver cuando se redirige la solicitud entrante. Los códigos de respuesta válidos para el redireccionamiento de la especificación HTTP estándar son:
301 Moved Permanently
302 Found
303 See Other
307 Temporary Redirect
308 Permanent Redirect
El valor predeterminado es 302 Encontrado
.
Reglas de cabecera de solicitud y respuesta
Las reglas de cabecera de solicitud y respuesta agregan, modifican o eliminan cabeceras de solicitud o respuesta HTTP. Estas reglas pueden ayudarle a transferir metadatos a sus servidores backend para realizar acciones como:
- Identificar el listener enviado una solicitud.
- Notificar a un servidor backend acerca de la terminación SSL.
Ejemplos de cómo los conjuntos de reglas pueden ayudar a mejorar la seguridad de los sitios:
- Agregar cabeceras para evitar que los dominios externos utilicen iframing en su sitio web.
- Eliminación de cabeceras de depuración, como "Server" enviadas por los servidores backend. Esta acción le ayuda a ocultar los detalles de implementación de su backend.
- Adición de la cabecera "strict-transport-security" a las respuestas con un valor adecuado. Esta cabecera permite garantizar que el acceso a su sitio web se realiza solo mediante HTTPS.
- Adición de la cabecera "x-xss-protection" con un valor adecuado. Esta cabecera le ayuda a aplicar la protección Cross-Site Scripting (XSS) incorporada en navegadores modernos.
- Adición de la cabecera "x-content-type" con un valor adecuado. Esta cabecera le ayuda a prevenir ataques en función del cambio de tipo de contenido.
Al agregar o eliminar la cabecera Host incorporada o una de las cabeceras X- como se describe en Cabeceras HTTP "X-" no se elimina ni sustituye el valor de la cabecera. En cambio, al realizar estas acciones se pueden agregar otros valores o duplicar la cabecera.
Ejemplo: notificar a WebLogic que el equilibrador de carga ha terminado SSL
Puede configurar el equilibrador de carga para realizar la terminación SSL. A menudo, sus aplicaciones de backend requieren una notificación de esta acción. Por ejemplo, el procesamiento de transacciones en línea de HTTPS WebLogic e-commerce busca la cabecera WL-Proxy-SSL
para confirmar que ha entrado una solicitud a través de SSL. Puede utilizar juegos de reglas para agregar esta cabecera al listener del equilibrador de carga.
Por motivos en materia de seguridad, WebLogic ignora esta cabecera a menos que marque la casilla Plugin de WebLogic activado en el consola de administración de Webster.
Reglas de cabecera HTTP
Las reglas de cabecera HTTP especifican el tamaño de la cabecera HTTP y los caracteres permitidos en las cabeceras.
- La regla de cabecera HTTP Tamaño de buffer de cabecera HTTP aumenta el tamaño de un buffer utilizado para leer la cabecera de solicitud de cliente HTTP y la respuesta del servidor backend desde los 8 KB por defecto hasta los 64 KB. La memoria intermedia se utiliza para el control de desbordamiento. Cada línea de cabecera de solicitud o respuesta debe ajustarse a este buffer. Por lo tanto, las aplicaciones que utilizan líneas de cabecera HTTP grandes deben ajustar este parámetro.
- La regla de cabecera HTTP Permitir caracteres no válidos en cabecera HTTP permite incluir números, guiones y guiones bajos en cabeceras HTTP.
Para obtener más información sobre la implantación de reglas de cabecera HTTP, consulte Creación de un juego de reglas.
Reglas de Max Listener Connection
La regla de conexión máxima de listener permite aplicar un número máximo uniforme de conexiones de listener para todas las direcciones IP, así como especificar sustituciones a ese valor uniforme para las direcciones IP individuales que identifique.
- Puede definir un valor de conexiones máximo por defecto que se aplique a todas las direcciones IP que no tengan definidos máximos específicos. Si no define este valor máximo por defecto, no hay ningún límite en el número de conexiones que una IP puede realizar a un listener.
- También puede definir valores máximos para una o más direcciones IP que sustituyan el valor máximo de conexiones por defecto.
Para obtener más información sobre la implantación de reglas de conexión de listener máximo, consulte Creación de un juego de reglas.