Exemplos de ACL no Packet Tracer: laboratório padrão e estendido

Planeje a política ACL e a topologia antes dos comandos

Coloque Client-A em 192.168.10.0/24, Client-B em 192.168.20.0/24 e Server-1 em 192.168.30.10/24. Ligue as três redes ao R1, configure 192.168.10.1, 192.168.20.1 e 192.168.30.1 nas interfaces e confirme a conectividade completa antes do filtro. Uma base funcional separa erros de ACL de problemas de cabo, interface, endereço ou rota.

Escreva a política em linguagem direta: Client-A pode alcançar a rede do servidor, Client-B não pode alcançar Server-1 e o restante continua disponível salvo regra contrária. Para cada teste, anote origem, destino, protocolo, porta, interface, direção e resultado esperado.

1. 1

   Montar e endereçar

   Crie as três redes e ative as interfaces.

2. 2

   Comprovar a base

   Teste a comunicação antes do filtro.

3. 3

   Definir resultados

   Liste casos permitidos e negados.

4. 4

   Salvar uma cópia

   Guarde um PKT anterior à ACL.

Compare ACL padrão e ACL estendida

Uma ACL IPv4 padrão compara apenas o endereço de origem. Ela serve para permitir ou bloquear uma rede de origem completa. Como não diferencia destino nem serviço, costuma ficar perto do destino para não impedir que a origem alcance outras redes.

Uma ACL estendida compara protocolo, origem, destino e portas TCP ou UDP. Ela permite liberar HTTP e negar ICMP ou bloquear um cliente diante de um servidor específico. Coloque-a perto da origem para descartar o tráfego indesejado cedo.

Exemplo de ACL padrão: bloqueie uma rede de origem

Para impedir 192.168.20.0/24 de chegar à LAN do servidor, use access-list 10 deny 192.168.20.0 0.0.0.255 e depois access-list 10 permit any. A permissão explícita é indispensável porque a regra final invisível nega tudo o que não correspondeu antes.

Aplique a lista 10 na saída da interface voltada para 192.168.30.0/24 com interface g0/2 e ip access-group 10 out. Assim Client-B continua acessando outras redes e é filtrado apenas ao sair para a LAN protegida.

1. 1

   Criar a negação

   Negue 192.168.20.0 com 0.0.0.255.

2. 2

   Permitir outras origens

   Adicione permit any antes da negação implícita.

3. 3

   Aplicar perto do destino

   Vincule a ACL na saída para a rede do servidor.

4. 4

   Testar os clientes

   Client-B falha e Client-A continua funcionando.

Se os dois falharem, revise primeiro a permissão, a interface e a direção.

Exemplo de ACL estendida: permita web e negue ping

Para permitir HTTP de 192.168.10.0/24 ao Server-1, configure access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 80. Depois negue eco ICMP com access-list 110 deny icmp 192.168.10.0 0.0.0.255 host 192.168.30.10 echo. Acrescente permit ip any any apenas quando a política liberar o restante.

Aplique a ACL 110 na entrada da interface do R1 ligada a 192.168.10.0/24. As linhas são lidas de cima para baixo e a primeira correspondência encerra a decisão. Para HTTPS, coloque uma regra para a porta 443 antes de uma negação ampla.

1. 1

   Permitir o serviço

   Coloque primeiro a regra TCP específica.

2. 2

   Negar o tráfego

   Compare ICMP ou o serviço proibido.

3. 3

   Decidir o restante

   Use permissão final somente se necessário.

4. 4

   Aplicar perto da origem

   Vincule na entrada e repita os testes.

Calcule a máscara curinga e escolha a direção

Em sub-redes contíguas, subtraia cada octeto da máscara de 255. Assim, 255.255.255.0 vira 0.0.0.255 e 255.255.255.192 vira 0.0.0.63. Um bit zero precisa coincidir e um bit um pode variar. Use host 192.168.30.10 para um endereço e any apenas quando todos forem intencionais.

A direção é vista pelo roteador: entrada é o pacote chegando pela interface; saída é o pacote deixando-a. Siga um pacote da origem ao destino para marcar onde ele entra e sai do R1.

Verifique tráfego permitido e negado

Faça pelo menos um teste positivo e outro negativo para cada condição. Um ping com falha apenas prova que algo falhou. Teste Client-A e Client-B até Server-1 e também até um destino não relacionado. Para regras por serviço, ative HTTP no servidor e não dependa apenas de ping.

Use show access-lists para ordem e contadores, show ip interface para ACL e direção aplicadas e show running-config para a sintaxe. No modo Simulation, filtre ARP, ICMP, TCP e HTTP e veja onde o pacote para.

• Confirme a conectividade básica do tráfego permitido.
• Faça o teste negado corresponder à origem, destino, protocolo e porta.
• Confira contadores depois de cada teste.
• Salve somente quando a evidência corresponder à política.

Corrija ordem, posicionamento e negação implícita

Verifique primeiro cabos, interfaces, endereços, máscaras, gateways e rotas. Depois confirme a ACL, leia de cima para baixo e revise interface e direção. Procure uma regra ampla antes de uma específica, curinga incorreta, porta no lado errado ou permissão ausente.

Mude uma condição por vez e repita os mesmos testes. Se o contador ficar em zero, o tráfego não chega à linha ou já correspondeu antes. Se o contador errado aumentar, corrija ordem ou critérios em vez de empilhar comandos aleatórios.