«

»

nov 21 2012

Wildcards x Máscaras de Rede

Muitos pensam que wildcards (as famosas “máscaras coringa”) são apenas uma forma de máscaras de rede, porém, invertidas. Até mesmo sites especializados (como o Cisco Learning Network) acabam explicando o assunto desta forma. A questão é que isso não é bem verdade. Os wildcards existem por um motivo, não são um capricho exclusivo da Cisco. Eles têm uma função muito importante, especialmente quando o assunto é listas de acesso, nos permitindo uma flexibilidade que máscaras de rede não conseguem.

Bom, para começar, temos de entender por que o wildcard que usamos na ACL tem uma função um pouco diferente das máscaras de rede tradicionais.

Basicamente, os bits no wildcard dizem o seguinte:

“Onde for ZERO, tem que bater bit a bit o que estiver no endereço que o precede, e onde for 1, qualquer variação (0 ou 1) é aceita”

Exemplificando, se tivermos:

192.168.10.0 com wildcard 0.0.0.255,

Estamos dizendo que o “match” – ou a correspondência – ocorrerá em qualquer combinação de 192.168.10.x

Notem que poderíamos ter usado qualquer variação no último octeto, e esta condição seguiria verdadeira. Por exemplo:

  • 192.168.10.0 0.0.0.255
  • 192.168.10.200 0.0.0.255
  • 192.168.10.255 0.0.0.255

Etc…!

Todas dizem ao roteador a mesma coisa: “Haverá correspondência (match) em qualquer endereço IP que tiver o padrão 192.168.10.x”

Agora que sabemos como funcionam os wildcards, basta aplicarmos o conceito para conseguirmos outros resultados.

Eis um excelente exemplo do poder de um wildcard. Suponha que desejemos criar uma regra de lista de acesso que dê match apenas nos endereços IP ímpares. Para conseguirmos isso, apenas temos que entender o padrão destes endereços para traduzí-los para um wildcard.

Concordam que TODO endereço IP ímpar tem o último bit ativo? O último bit tem valor “1”, e sem ele, os endereços seriam pares. Observem:

  • x.x.x.11111111 = x.x.x.255 (ímpar)
  • x.x.x.01010101 = x.x.x.85 (ímpar)
  • x.x.x.10000001 = x.x.x.129 (ímpar)
  • x.x.x.00000001 = x.x.x.1 (ímpar)

Assim sendo, temos apenas de criar um wildcard que permita que todo o resto mude, MENOS O ÚLTIMO BIT, que sempre terá de ser SEMPRE 1 para que o match ocorra.

Eis o resultado:

255.255.255.254

em binário ficaria:

11111111.11111111.11111111.11111110

Note, então, que travamos apenas o último bit no wildcard. Mas para que isso funcione, o endereço que o precede na regra deve também terminar com um bit 1. Então, basta aplicar este wildcard em QUALQUER endereço com o último bit 1:

192.168.10.33 e wildcard 255.255.255.254 funcionaria. Mas também funcionaria até se você usasse um endereço inválido, como:

0.0.0.1 e wildcard 255.255.255.254

Gostaram? E se pegássemos um exemplo mais complexo… como:

Vamos criar uma regra (combinação IP + WILDCARD), de forma que somente endereços IP com o seguinte padrão sejam filtrados:

[ 10 . “qualquer coisa” . 11 . “qualquer coisa” ] E que sejam PARES, como nos exemplos abaixo:

10.120.11.10 ou 10.11.11.2 ou 10.19.11.180, etc

Como fazer isso?

Como já vimos, wildcards são diferentes de Máscaras de rede. Em um Wildcard, os ZEROS instruem o roteador a dar um match nos bits correspondentes do endereço IP, enquanto os UMs dizem ao roteador que qualquer combinação é válida (0 ou 1) no endereço IP.

Assim, em binário:

00001010.00000000.00001011.00000000 (10.0.11.0)
00000000.11111111.00000000.11111110 (0.255.0.254)

Como queremos que o 1o e o 3o octeto não mudem (10 e 11), zeramos os 2 no wildcard. Adicionalmente, como o exercício solicitou apenas IPs PARES (e para isso, o último bit deve SEMPRE ser ZERO), travamos também o último bit (por isso 254 e não 255 no último octeto). A resposta poderia ser também qualquer IP que seguisse o padrão, usando o wildcard que descobrimos. Ex: 10.123.11.126 0.255.0.254, ou 10.255.11.12 0.255.0.254, etc

Espero que tenham gostado!

Abraço

Marco.



Comente usando o Facebook!
0
0

9 comentários

Pular para o formulário de comentário

  1. Deco

    Mais bem explicado que isso impossível Marco, receita de bolo esse post.

    Mais uma vez tks por compartilhar conhecimento conosco Marco.

    0

    0
  2. William

    Excelente explicação, Marco!
    Com certeza vai “desmistificar” o assunto para muita gente! hahaha

    0

    0
  3. zekkerj

    Exemplo real.

    Aqui no serviço, usamos endereços padronizados pras máquinas em cada filial. Por exemplo, o servidor de arquivos sempre tem final “.2”, o proxy sempre tem final “.3”, o relógio de ponto sempre tem final “.4”, e assim por diante. No caso dos relógios de ponto, eles precisam se conectar ao servidor de aplicação pra fazer a descarga dos pontos do dia. Nossa ACL então fica assim:

    access-list 199 permit tcp 192.168.0.4 0.0.255.0 host 192.168.1.20 eq 3000

    A máscara “0.0.255.0” permite que qualquer estação “192.168.xxx.4” conecte-se ao host “192.168.1.20” na porta 3000.

    0

    0
  4. Marco Filippetti

    Zekkerj, excelente exemplo prático! Obrigado!

    0

    0
  5. Fabio Santos

    Não fazia a menor ideia de que se podia intercalar 0s e 1s no mesmo wildcard. Uma característica que as máscaras de rede não possuem. Saquei a diferença.

    0

    0
  6. noss

    Flexibilidade que não temos na tradicional MK que é intercalar 0s e 1s, muito bom mesmo. Excelente post Marco!

    0

    0
  7. JamersonChequer

    Fantástico Marco, parabéns por mais esse post.

    0

    0
  8. fabricioball

    Caros;

    Estou com um problema que é bem a realidade deste post..
    O problema é o seguinte:

    tenho uma ACL que tem que passar por um nat todas os IPs das rede 10.0.0.0/8 menos a rede 10.144.0.0/24
    inicialmente fiz a seguinte regra.

    80 permit 10.0.0.0, wildcard bits 0.143.255.255 (6314234 matches)
    90 permit 10.145.0.0, wildcard bits 0.110.255.255

    A acl 90 não houve nenhum match. com isso algumas redes eram bloqueadas pela a acl. uma rede de exemplo: 10.152.0.0, para resolver tive que criar outras regras.

    100 permit 10.95.0.0, wildcard bits 0.0.255.255 (3441 matches)
    120 permit 10.20.0.0, wildcard bits 0.0.255.255 (27129 matches)
    130 permit 10.152.0.0, wildcard bits 0.0.255.255 (515 matches)
    140 permit 10.150.0.0, wildcard bits 0.0.255.255 (1649 matches)

    Alguem poderia me explicar o que está acontecendo, pois as redes 10.95, 10.150. eram para está sendo contempladas em uma das regras feitas no inicio.

    0

    0
  9. zekkerj

    Três anos depois, mas ainda em tempo… resposta:
    “tenho uma ACL que tem que passar por um nat todas os IPs das rede 10.0.0.0/8 menos a rede 10.144.0.0/24”.

    deny 10.144.0.0 0.0.0.255
    permit 10.0.0.0 0.255.255.255

    0

    0

Deixe uma resposta