Filtros Avançados para (re-) Classificação de Pacotes

Capítulo 12 - Filtros Avançados para (re-) Classificação de Pacotes

Como explicado na seção sobre disciplinas de enfileiramento classful, filtros são necessários para classificar pacotes em qualquer uma das sub-filas. Esses filtros são chamados de dentro da qdisc classful.

Aqui está uma lista incompleta de classificadores disponíveis:

fw

Baseia a decisão em como o firewall marcou o pacote. Isso pode ser a saída fácil se você não deseja aprender a sintaxe do comando ‘tc filter’. Veja o capítulo Queueing (Enfileiramento) para detalhes.

u32

Baseia a decisão a partir dos campos dentro do pacote (ou seja, endereço IP origem, etc.).

route

Baseia a decisão sobre qual rota o pacote será roteado.

rsvp, rsvp6

Roteia pacotes baseado no RSVP. Útil somente em redes que você controla – a Internet não respeita o RSVP.

tcindex

Usado na qdisc DSMARK, veja a seção relevante.

Observe que em geral existem muitas maneiras em que você pode classificar pacotes e que geralmente recai na preferência a cerca de qual sistema você deseja usar.

Os Classificadores em geral aceitam alguns argumentos em comum. Eles são listados aqui por conveniência:

protocol

O protocolo que esse classificador aceitará. Geralmente você somente estará aceitando somente tráfego IP. Exigido.

parent

O handle ao qual esse classificador será associado. Esse handle precisa ser uma classe já existente. Exigido.

prio

A prioridade desse classificador. Números mais baixo são testados primeiro.

handle

Esse handle significa diferentes coisas para diferentes filtros.

Todas as seções seguintes assumirão que você está tentando fazer o shape do tráfego que segue para o HostA. Elas assumirão que a classe root foi configurada como ‘1:’ e que a classe para qual você deseja enviar o tráfego selecionado é a 1:1.

12.1. O Classificador u32

O filtro U32 é o filtro mais avançado disponível na implementação atual. Ele é inteiramente baseado nas tabelas de função hash, que o torna robusto quando existem muitas regras de filtros.

Em sua forma mais simples o filtro U32 é uma lista de registros, cada um consistindo de dois campos: um seletor e uma ação. Os seletores, descritos abaixo, são comparados com o pacote IP processado atualmente até que ocorra o primeiro match, e então a ação associada é executada. O tipo de ação mais simples seria direcionar o pacote para dentro da classe definida.

A linha de comando do utilitário tc filter usado para configurar o filtro, consiste de três partes: a especificação do filtro, um seletor e uma ação. A especificação do filtro pode ser definida como:


tc filter add dev IF [ protocol PROTO ]
                     [ (preference|priority) PRIO ]
                     [ parent CBQ ]

O campo protocol descreve a qual filtro será aplicado. Nós somente discutiremos o caso do protocolo ip. O campo preference (priority pode ser usado alternativamente) define a prioridade do filtro definido atualmente. Isso é importante, já que você pode ter vários filtros (listas de regras) com diferentes prioridades. Cada lista será passada na ordem que as regras foram adicionadas, então a lista com prioridade mais baixa (número de preferência mais alto) será processada. O campo parent define o topo da árvore CBQ, à qual o filtro deve ser associado.

As opções descritas acima se aplicam a todos os filtros, e não somente ao filtro U32.

12.1.1. Seletor U32

O seletor U32 contém a definição do padrão, com o qual será conferido o pacote processado atualmente. Precisamente, ele define quais bits devem ser conferidos no cabeçalho do pacote e nada mais, mas esse método simples é muito poderoso. Analisemos os exemplos seguintes, tomados diretamente de um filtro moderadamente complexo do mundo real:


# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
     match u32 00100000 00ff0000 at 0 flowid 1:10

Por agora, deixemos a primeira linha isolada – todos esses parâmetros descrevem as tabelas hash do filtro. Foquemos na linha do seletor, que contém a palavra chave match. Esse seletor vai conferir os cabeçalhos do IP, cujo segundo byte será 0x10 (0010). Como você pode imaginar, o número 00ff é a máscara de batimento, que diz ao filtro exatamente quais bits conferir. Aqui ela é 0xff, assim o byte será conferido se ele for exatamente 0x10.

A palavra chave at significa que a conferência deve começar no offset especificado (em bytes) – nesse caso ele está no início do pacote. Traduzindo tudo isso para a linguagem humana, o pacote vai conferir se o seu campo Tipo de Serviço (Type of Service – TOS) tiver os bits ‘low delay’. Analisemos uma outra regra:


# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
     match u32 00000016 0000ffff at nexthdr+0 flowid 1:10

A opção nexthdr significa próximo cabeçalho encapsulado no pacote IP, ou seja, o cabeçalho do protocolo da camada superior. O match aqui também começará no início do próximo cabeçalho. O match deve ocorrer no segundo, palavra de 32 bits do cabeçalho. Nos protocolos TCP e UDP esse campo contém a porta destino do pacote. O número é fornecido no formato big-endian, ou seja, os bits mais significativos primeiro, assim nós simplesmente lemos 0x0016 como 22 decimal, que se refere ao serviço SSH se esse for o TCP. Como você imaginou, esse match é ambíguo sem um contexto, e nós discutiremos isso depois.

Tendo entendido tudo acima, descobriremos o seletor seguinte totalmente fácil de ler: match c0a80100 ffffff00 at 16. O que nós temos aqui é um match de três bytes no byte décimo sétimo, contando a partir do inicio do cabeçalho IP. Esse vai bater com pacotes com endereço de destino em qualquer lugar na rede 192.168.1.0/24. Após analisar os exemplos, nós podemos resumir o que nós temos aprendido.

12.1.2. Seletores Gerais...

Autores Originais dos textos:

Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl

Thomas Graf (Autor de Seção)
tgraf@suug.ch

Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx

Remco van Mook (Autor de Seção)
remco@virtu.nl

Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com

Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com

Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl

Pedro Larroy (Autor de Seção)
piotr@member.fsf.org