CDN:Mecanismo de regras

O console do Alibaba Cloud CDN DCDN disponibiliza recursos básicos, como definição de tempos de expiração de cache e reescrita de parâmetros de retorno à origem, atendendo à maioria das necessidades comuns. Para requisitos específicos, como direcionar requisições que contenham o caminho /example para um servidor de origem determinado, utilize o mecanismo de regras para criar configurações personalizadas. Além disso, o Alibaba Cloud CDN DCDN oferece o recurso EdgeScript, que suporta personalização altamente flexível e permite configurar políticas granulares semelhantes às de provedores de CDN de terceiros, como Fastly e CloudFront.

Operadores lógicos

Parâmetros de uma expressão condicional

Configuração da expressão condicional

Observações comuns de configuração para expressões condicionais

• Ponto inicial da correspondência de URI (caminho): Na correspondência de URI, o valor corresponde à parte do caminho que começa com o primeiro / após o nome do domínio. Esse valor não inclui o nome do domínio nem os parâmetros de requisição. Para a requisição https://example.com/path/file.html?key=value, o valor a ser correspondido é /path/file.html. O valor de correspondência deve começar com /.

• Formato de correspondência de extensão de arquivo: Ao configurar uma correspondência de extensão de arquivo, o valor de correspondência deve incluir um ponto (.). Por exemplo, para corresponder a arquivos .txt, insira .txt, e não txt. Caso contrário, a correspondência poderá falhar.

• Exemplos de uso de caracteres curinga: As correspondências de URI e de extensão de arquivo suportam os caracteres curinga ? (corresponde a um único caractere) e * (corresponde a zero ou mais caracteres). Exemplos comuns:

  • /*.pdf: Corresponde a todos os arquivos PDF no diretório raiz.

  • /api/*/data: Corresponde ao caminho data em qualquer subdiretório sob /api/.

  • .??: Corresponde a todas as extensões de arquivo de dois caracteres, como .js e .ts.

Modo de verificação de endereço IP

O mecanismo de regras oferece dois modos de verificação de endereço IP. O modo selecionado afeta a forma como os nós do CDNDCDN identificam o endereço IP do cliente:

• IP de conexão POP: Este modo corresponde ao endereço IP que o cliente utiliza para se conectar a um nó do CDNDCDN. Se houver um servidor proxy entre o cliente e o nó do CDNDCDN, o IP de conexão POP será o endereço IP do servidor proxy.

• IP XFF: Este modo corresponde ao endereço IP mais à esquerda no cabeçalho de requisição x-forwarded-for. O IP XFF é sempre o endereço IP real do cliente, independentemente de haver ou não um servidor proxy entre o cliente e o nó do CDNDCDN.

A escolha do modo de verificação depende se a requisição do cliente passa por um servidor proxy antes de chegar a um nó do CDNDCDN.

Observe que o local em um nó do CDNDCDN onde um recurso entra em vigor também influencia o modo de verificação de IP. Para recursos relacionados a configurações de origem que atuam em nós L2, os nós L1 pelos quais a requisição passa são considerados servidores proxy intermediários.

Exemplo: Suponha que o endereço IP real do cliente seja 10.10.10.10 e o endereço IP do servidor proxy seja 192.168.0.1.

• Sem servidor proxy:

  • O valor do cabeçalho de requisição x-forwarded-for é 10.10.10.10.

  • O endereço IP real do cliente (o IP mais à esquerda no cabeçalho x-forwarded-for) = O endereço IP usado para estabelecer a conexão entre o cliente e o nó do CDNDCDN = 10.10.10.10.

• Com servidor proxy:

  • O valor do cabeçalho de requisição x-forwarded-for é 10.10.10.10,192.168.0.1.

  • O endereço IP real do cliente (o endereço IP mais à esquerda no cabeçalho x-forwarded-for) é 10.10.10.10.

  • IP de conexão do cliente ao nó do CDNDCDN = IP do servidor proxy = 192.168.0.1.

  • O endereço IP real do cliente (o primeiro endereço IP da esquerda no cabeçalho x-forwarded-for) ≠ o endereço IP da conexão do cliente ao nó do CDNDCDN.

Operadores de correspondência (matchOperator)

Caracteres curinga

Gerenciamento de configurações

• Gerenciamento de ações: A página Rules Engine serve apenas para definir condições de regra. Para gerenciar uma ação (como expiração de cache, reescrita de URL ou limitação de taxa), acesse a página de configurações do recurso correspondente. Por exemplo, se uma configuração de expiração de cache referenciar uma condição de regra, acesse Cache settings > Cache expiration para visualizá-la ou modificá-la.

• Remote Authentication: O recurso remote authentication não pode referenciar condições de regra, o que significa que não é possível usar o Mecanismo de Regras para controlar quando ele é acionado.

• Limite de tempo de autenticação: O Remote Authentication Timeout pode ser definido em no máximo 3000 milissegundos (3 segundos). O valor padrão é 500 milissegundos. Este é o valor máximo suportado pelo sistema.

Casos de uso avançados

É possível implementar as seguintes configurações avançadas com o Mecanismo de Regras:

• Políticas de limitação diferenciadas: Se desejar limitar algumas requisições mas não outras (por exemplo, limitar URLs que incluam parâmetros de assinatura, mas não limitar outras URLs), ou se precisar de uma política de limitação alternativa, crie condições de regra no Rules Engine para diferenciar as requisições. Em seguida, nas configurações de Single-request throttling, referencie diferentes condições de regra e configure valores de limitação distintos.

• Liberação canário baseada em IP para busca na origem: Para implementar uma liberação canário baseada em endereços IP de clientes ou rotear requisições de IPs específicos para origens diferentes, crie condições de correspondência baseadas em IP no Mecanismo de Regras. Depois, nas configurações de Conditional origin, referencie essas condições para especificar endereços de origem distintos.

• Recomendação para arquiteturas de origem mista: Se você utilizar tanto o WAF quanto o OSS como origens, não os configure como múltiplas origens primárias. Em vez disso, use o Mecanismo de Regras para criar condições de correspondência baseadas em caminhos de URL. Assim, nas configurações de Conditional origin, será possível rotear dinamicamente as requisições para a origem adequada a cada caminho. Essa abordagem ajuda a prevenir conflitos.

Cenário 1: Lista de permissões de IP e redirecionamento

Objetivo: Permitir que apenas endereços IP específicos acessem seu site e redirecionar todo o restante do tráfego para uma página de manutenção.

Implementação:

1. No Rules Engine, crie uma condição de regra. Defina o Match Type como Client IP, o Match Operator como Does not contain any of e insira seus endereços IP permitidos como Match Value.

2. Em Cache Configuration > URL Rewrite, referencie essa condição de regra para redirecionar as requisições correspondentes (de endereços IP não permitidos) para a URL da página de manutenção especificada, como uma página HTML hospedada em uma origem OSS.

Observações:

• Se requisições de endereços IP fora da lista de permissões retornarem um erro 403 em vez de serem redirecionadas, verifique se você configurou múltiplas origens OSS, o que pode causar conflito de origem. Recomendamos que cada domínio CDNDCDN tenha apenas uma origem OSS primária.

• Certifique-se de que a URL da página de manutenção seja publicamente acessível e não esteja bloqueada por outras regras de controle de acesso.

Cenário 2: Proteção de Referer e correspondência de extensão de arquivo

Objetivo: Aplicar proteção contra hotlinking por Referer à maioria dos arquivos, isentando extensões específicas dessa verificação.

Implementação:

1. No Rules Engine, crie uma condição de regra. Defina o Match Type como File Extension, o Match Operator como Does not contain any of e insira as extensões de arquivo que deseja isentar (como .pdf) como Match Value.

2. Em Access Control > Referer Hotlink Protection, referencie essa condição de regra. Isso aplica sua lista de permissões ou bloqueios de Referer a todas as requisições, exceto aquelas para as extensões de arquivo isentas.

FAQ