Hoje, continuaremos o tópico do tutorial em vídeo no 27º dia e faremos um estudo aprofundado das ACLs: falaremos um pouco sobre a máscara reversa da Wildcard Mask, lista estendida de ACL, configuração de uma lista estendida de ACL e comandos que ajudam a diagnosticar problemas de design de rede.
Na lição anterior, introduzimos um novo conceito de máscara inversa para nós, e agora vou falar sobre a máscara curinga com mais detalhes. Se você se lembra, a máscara de sub-rede nos ajuda a dividir visualmente a rede na parte do endereço da rede e na parte do endereço do host.
Se você for para o nível de bit, poderá ver que a máscara de sub-rede consiste em uma série de unidades que denotam a parte da rede e uma série de zeros que indicam parte do host. A máscara reversa é muito semelhante à máscara de sub-rede, somente na forma “invertida” - onde existem unidades na máscara de sub-rede, zeros estão na máscara de sub-rede e vice-versa. Esta não é uma regra obrigatória - em alguns casos, a máscara inversa é formada de acordo com um princípio diferente; ao aprender o CCNA, essa regra sempre se aplica.
A melhor maneira de calcular a máscara inversa é subtrair os octetos da máscara de sub-rede da máscara global, que sempre se parece com 255.255.255.255.
Portanto, para calcular a máscara inversa da máscara de sub-rede 255.255.255.0, simplesmente a subtraímos da máscara global e obtemos 0.0.0.255.
Neste exemplo, vimos a rede 192.168.100.255/24 e agora vamos ver a rede / 26. Se você tiver / 26, o último octeto da máscara de sub-rede será 192.
Se você observar a forma de bit desses endereços IP, verá que a máscara de sub-rede contém 26 bits únicos e 6 bits zero.
Nesse caso, a máscara reversa deve consistir em 26 zeros e 6 unidades. Como já dissemos, os locais onde 0 está localizado mostram os parâmetros de endereço correspondentes e os locais onde as unidades estão localizadas, você pode ignorar.
Para tornar mais claro, escreverei o endereço IP na forma decimal na parte superior. O último octeto da máscara inversa corresponde ao número 63, e eu posso exibi-lo como 0.0.0.63. Simplificando, / 26 significa que os 26 zeros ou os 3 primeiros octetos do endereço IP são iguais e os últimos 6 bits podem ser qualquer coisa - zeros ou uns.
Veja - se substituirmos esses últimos 6 bits do endereço IP por zeros, obteremos o número 192 e, se conseguirmos o número 255. Portanto, a máscara reversa mostra que a sub-rede com endereços IP cujo último octeto está no intervalo de 192 a 255 , ou seja, parte da rede 192.168.100.225/26, está sujeita à condição ACL especificada.
Você pode perguntar por que duas máscaras são necessárias: uma máscara de sub-rede e uma máscara curinga. Eu mesmo fiz essa pergunta quando era estudante, e ainda muitas pessoas, mesmo trabalhando na Cisco, fazem essa pergunta. Vou tentar responder. Em geral, a máscara de sub-rede e a máscara reversa mostram a mesma coisa quando se trata da sub-rede, ou seja, parte do endereço IP que indica a rede. Quando identificamos toda a rede, a máscara inversa é simplesmente uma versão "invertida" da máscara direta.
No entanto, a identificação do host é diferente. Se você deseja identificar toda a sub-rede com todos os endereços incluídos nela, pode usar a máscara de sub-rede. Mas se você precisar identificar apenas alguns hosts desta rede para aplicar seletivamente regras de ACL a eles, precisará de uma máscara reversa.
Você nunca verá uma máscara de sub-rede que consiste em zeros e zeros alternados - ela sempre possui unidades primeiro e zeros no final. O curinga é, portanto, chamado de "curinga" porque pode consistir em qualquer sequência de zeros e uns. Para deixar mais claro, vamos resolver o problema: "identifique hosts em uma determinada rede que tenham números pares no quarto octeto".
Isso é necessário para criar uma regra ACL desse tipo: permitir 192.168.100.0 <máscara reversa>, ou seja, o tráfego será permitido para os endereços IP desta sub-rede com apenas quatro quartos octetos. Isso pode ser feito usando uma máscara de sub-rede? Acho que não, porque o quarto octeto de uma máscara de sub-rede comum pode conter apenas um número específico. Vamos olhar para uma máscara inversa de 4 octetos.
No último octeto da máscara inversa, você pode colocar os seguintes bits: 11111110. Vou explicar o que é. Se o quarto octeto contiver números pares, o último bit do octeto será necessariamente 0 e, se o último bit for 1, o número será ímpar. Se estamos falando sobre a sub-rede / 24, somente o último octeto nela pode conter um número par.
No caso da máscara reversa, os três primeiros octetos são 0 e os primeiros sete bits do quarto octeto não nos incomodam, o principal é que o oitavo bit do octeto é zero, porque deve coincidir com o último octeto do endereço IP da rede, que é 0.
Se o último bit do endereço IP for 1, esse endereço será negado, agora adicionarei a condição à nossa ACL - Negar qualquer. Portanto, somente se o último octeto de qualquer endereço IP de nossa sub-rede terminar com 0, ou seja, será uniforme, cumpriremos a condição de correspondência com a máscara reversa, que também termina com 0, e a condição da ACL "permitir todos os endereços com um quarto octeto uniforme" ficará satisfeito. Caso contrário, ou seja, para todos os endereços IP ímpares, a negação de qualquer condição será aplicada.
Portanto, não nos importamos com o valor exato de um octeto uniforme - 2,4,6, 8 e assim por diante, o principal é que ele terá um bit zero no final. Se usássemos uma máscara de sub-rede comum, precisaríamos criar uma entrada separada para cada endereço IP com um quarto octeto uniforme. O uso da máscara inversa permite substituir todas essas entradas por uma.
Exatamente o mesmo princípio se aplica aos números ímpares do quarto octeto, neste caso, apenas o último bit da máscara reversa deve ser 1. Nesse caso, uma regra geral será estabelecida, permitida ou negada, para todos os endereços IP da sub-rede com um ímpar 4- octeto. Veja como é esse exemplo decimal.
Se eu usar a máscara reversa 0.0.0.254, nosso problema será resolvido: todos os hosts com um quarto octeto ainda são permitidos e todos os outros hosts são proibidos. A vantagem de uma máscara reversa é que, ao criar uma ACL, você pode configurá-la para atender às suas necessidades. Você não precisa se preocupar muito com máscaras reversas específicas, porque o CCNA não exige isso. Basta lembrar a regra: a máscara reversa é obtida quando a máscara de sub-rede é removida da máscara global 255.255.255.255. Observe que o curso CCNA se concentra mais em sub-redes do que em hosts.
Vamos voltar ao slide anterior e falarei sobre outra maneira de calcular a máscara curinga.
Se você se lembra da nossa tabela "mágica", / 26 significa o tamanho do bloco de bits igual a 64. Se esse bloco for 64, o último octeto da máscara inversa terá o valor (64-1) = 63. Se tivermos / 25, o tamanho do bloco será 128, o que significa que o último octeto da máscara inversa será (128-1) = 127. Essa é outra dica para facilitar o cálculo do valor da máscara inversa. Mas se você não quiser usá-lo, use o método usual, subtraindo a máscara de sub-rede da máscara global.
Agora vamos para a sintaxe dos comandos estendidos da ACL. Como na ACL padrão, existem dois tipos de gravação de comando: clássica e moderna.
O comando clássico é a lista de acesso à entrada <número da ACL> <desativar / permitir> <protocolo>. Portanto, o primeiro comando estendido da ACL difere do comando padrão da ACL especificando um protocolo, não um critério. Isso significa que aqui o tráfego é filtrado não pelo endereço IP da origem ou destino, mas pelo protocolo usado.
Em todos os casos, usamos o protocolo IP, que é de três tipos: ICMP, ou o ping conhecido por nós, TCP, que depende da porta específica 21,23 e assim por diante, e UDP. Deixe-me lembrá-lo de que a Wikipedia possui um artigo com uma lista de todos os protocolos e seus números de porta correspondentes.
A seguir está a linha de comando <IP de origem> <máscara reversa> [informações de protocolo]. Informações de protocolo significa especificar um número de porta. Ou seja, no comando anterior como <protocol>, você especifica ICMP, TCP ou UDP, e no segundo comando como parâmetro [informações do protocolo] especifica o número da porta 21.23, etc.
A terceira linha do comando é <IP de destino> <máscara reversa> [informações do protocolo], ou seja, os parâmetros referentes ao destino.
Se você se lembra das lições anteriores, o número da porta de origem é um número aleatório, porque o dispositivo que envia o tráfego cria uma porta de número aleatório para isso. Nesse sentido, na primeira linha referente à fonte de tráfego, você indica [informações de protocolo] do destino, por exemplo, FTP, ou seja, o protocolo do dispositivo cujo tráfego você deseja bloquear.
Deixe-me lembrá-lo de que, para fazer alterações na lista de ACLs estendidas do tipo clássico, você precisará reformular a lista inteira manualmente, como no caso das ACLs padrão do tipo clássico.
Uma equipe de aparência moderna começa com a expressão ip, que nada tem a ver com o protocolo IP, é apenas uma palavra-chave. Portanto, a primeira linha contém a palavra-chave ip, o parâmetro "lista de acesso estendida" e o número ou nome da ACL. Após executar o primeiro comando, você alterna para o modo de subcomando config-ext-nacl e insere <disable / allow> <protocol>, conforme discutimos acima.
A seguir estão os dois comandos <IP de origem> <máscara reversa> [informações do protocolo] e <IP de destino> <máscara reversa> [informações do protocolo], o primeiro geralmente ignorando o parâmetro [informações do protocolo de origem] e, em vez disso, o parâmetro [informações do protocolo] destino]. Às vezes, pode ser necessário especificar a porta de origem, mas no CCNA, na maioria dos casos, esse parâmetro pode ser ignorado.
O uso de uma ACL estendida é semelhante ao uso de uma ACL padrão. Aqui você também precisa especificar a interface do dispositivo ao qual a lista é aplicada e, em seguida, usar o parâmetro ip access-group, o número ou nome da lista ACL e a direção do fluxo de tráfego - entrada ou saída. No vídeo anterior, já discutimos como a direção do tráfego é determinada para uma porta específica.
Vamos seguir para o esquema e configurar a ACL avançada usando a topologia de rede da lição anterior. O problema número 1 é: "Os computadores da rede do departamento de gerenciamento e da rede do departamento financeiro podem acessar via protocolos HTTP (80) e FTP (21) apenas o servidor Server0 localizado na rede do servidor".
Ao mesmo tempo, nem todo o tráfego é permitido, mas somente o que vem das portas 80 e 21, ou seja, por exemplo, o tráfego via protocolo SSH deve ser bloqueado. Se você se lembra, a ACL estendida deve ser aplicada mais próxima da origem, portanto, para o departamento de gerenciamento, deve ser aplicada à porta G0 / 0 do roteador R1 e, para contabilidade, à porta G0 / 0 do roteador R2. Em relação ao roteador, bloqueamos o tráfego recebido e, portanto, usamos o parâmetro IN nos comandos da lista. Atribua a ACL ao número da lista 101 e faça uma lista de linhas que ele deve conter usando a abordagem clássica.
A primeira linha permite o TCP, porque a porta HTTP 80 significa TCP, então indicamos a rede do departamento de gerenciamento, 192.168.1.224/28. Neste exemplo, omito a máscara reversa, a usamos no Packet Tracer, até agora o princípio da formação da lista é importante para nós. A rede de gerenciamento é a fonte de tráfego, depois que o endereço IP de destino 192.168.1.194/32 é indicado, onde 194 é o último octeto do endereço Server0 e / 32 significa que a condição se aplica apenas a esse dispositivo específico localizado na sub-rede 192.168.1.192/27. No final da linha, indicamos a porta de destino permitida 80, destinada ao tráfego HTTP.
Da mesma maneira, uma entrada é criada para a porta 21 usada para transmitir o tráfego FTP. Não estou escrevendo uma terceira linha, que por padrão se parece com Negar e proíbe qualquer tráfego de saída de dispositivos que não pertencem a esta sub-rede. Em seguida, você deve especificar que a lista seja aplicada à porta G0 / 0 de R1 na direção IN, ou seja, para tráfego de entrada.
Fazemos o mesmo na compilação de entradas ACL Allow_Acc para o departamento financeiro, permitindo o tráfego TCP das portas 80 e 21 e aplicando essa lista à interface de entrada G0 / 0 do roteador R2.
O problema número 2 é: "Os computadores na rede do departamento de vendas podem usar todos os protocolos, exceto o PING (ICMP), apenas no Server1, localizado na rede do servidor". Isso significa que, para comunicação com o servidor, os computadores do departamento de vendas podem usar os protocolos HTTP, SSH, FTP - qualquer outro protocolo que não seja o ICMP. Nesse caso, a lista de condições da ACL ficará assim.
Na primeira linha, proibimos todo o tráfego via ICMP, colocando uma condição específica no topo da lista e geral no final da lista. Este registro mostra o identificador de sub-rede do departamento de vendas 192.168.1.0/25, o endereço IP de um servidor Server 1 específico é 192.168.1.195/32. O parâmetro echo significa que o tráfego na forma de ping, ou seja, um pacote enviado ao servidor para retornar ao computador deve ser negado.
A segunda linha permite todo o tráfego proveniente da sub-rede 192.168.1.0/25 para o endereço do servidor 192.168.1.195/32. Como de costume, no final da lista, a linha padrão é Negar, o que significa que, se os computadores do departamento de vendas tentarem entrar em contato com o departamento financeiro, esse tráfego será descartado. A seguir, indicamos em qual interface do roteador a ACL deve ser aplicada e o segundo problema é resolvido.
A tarefa 3 é: “Laptop2 de vendas Laptop2 e o departamento financeiro PC0 pode acessar o laptop0 management0 laptop0.” Suponha que esses dispositivos sejam gerenciados pelos chefes dos departamentos de vendas e contabilidade, que podem se comunicar com o CFO do CFO localizado no departamento de gerenciamento. No entanto, não há restrições nos protocolos utilizados, incluindo o ICMP.
Já temos três ACLs aplicadas às interfaces que circulei em vermelho no diagrama. O Laptop2 não pode entrar em contato com o Laptop0 no momento, porque isso contradiz as condições do Problema 3.
Para se comunicar entre esses dois dispositivos, você deve adicionar condições adicionais à ACL Allow_Sa.
Da mesma forma, você precisa adicionar condições à ACL Allow_Acc para que o PC0 possa entrar em contato livremente com o Laptop0.
Nas duas listas, adicionamos linhas com o parâmetro Permit IP, o que significa permitir tráfego por qualquer protocolo IP.
Como você sabe, o ICMP usa tráfego bidirecional: você envia ping e o eco retorna. Em nossa situação, se o Laptop2 resolver o ping do Laptop0, o tráfego fluirá livremente para a rede do departamento de gerenciamento. No entanto, quando o pacote retornar ao laptop do departamento de vendas, ele será direcionado para a interface G0 / 0 do roteador R1, onde o ACL 101 está ativo.Como o tráfego de retorno não corresponde a nenhuma das condições nesta lista, ele será bloqueado. Portanto, precisamos suplementar a lista ACL101 com as condições de resolução para executar ping no laptop Sales2 do departamento de vendas e executar ping no computador PC0 do departamento financeiro.
Resolvemos a tarefa nº 3 e agora prosseguimos para a solução do problema nº 4: “O laptop Sales3 Laptop3 pode acessar apenas sua própria rede de VENDAS e apenas o serviço da Web pela porta 80 no servidor 1”.
A primeira parte da tarefa significa que, assim que o Laptop3 tentar sair da rede SALES, seu tráfego será bloqueado pelo roteador R2. No entanto, de acordo com a segunda parte da tarefa, este computador deve ter acesso a um serviço da Web localizado fora da rede SALES. Isso significa que todo o tráfego, exceto o tráfego direcionado ao servidor, está bloqueado.
Nas tarefas anteriores, sabemos que o tráfego proveniente do departamento de vendas é regulado pela Allow_Sa ACL, que aplicamos à interface de entrada G0 / 1 do roteador R2. Portanto, precisamos alterar essa lista, primeiro adicionando a ela a linha “permitir TCP ao servidor 1 pela porta 80” do seguinte tipo: Permitir TCP 192.168.1.3/32 192.168.1.195/32 80
A primeira linha significa que qualquer tráfego HTTP chega ao servidor e a segunda Negar IP 192.168.1.3/32 significa que o restante do tráfego, por exemplo, FTP vindo do Laptop3, será descartado. Além disso, deixamos inalteradas as três linhas a seguir da ACL anterior, resolvendo o problema 4.
Eu já disse que recomendo que você anote as soluções para esses problemas em papel ou digite-as manualmente em um computador, pois elas mudam. No papel ou em um computador, você sempre pode adicionar, riscar ou excluir linhas. Chamo a atenção para o fato de que, se você simplesmente adicionar a solução ao quarto problema no final da ACL, adicionando duas linhas, o sistema as ignorará, porque as condições localizadas acima absorvem essas regras. Como a segunda linha da lista antiga permite todo o tráfego, a condição Negar IP 192.168.1.3/32, localizada no final da lista, simplesmente não será atendida.
Portanto, a sequência correta de entradas da ACL é de extrema importância. Primeiro, você deve desenvolver uma cadeia lógica de operações e organizar as linhas para que elas não se contradigam. Agora vamos seguir para o Packet Tracer e concluir todas as configurações de acordo com as soluções.
Vamos começar a configuração a partir do primeiro roteador, Roteador1. Eu uso o comando show access-list para mostrar que a ACL está ausente no momento. Em seguida, usando o comando show ip route, mostro que o RIP entre os dois roteadores já está configurado e funcionando.
Vamos para Laptop0 e executar ping no Server1 em 192.168.1.195. Como você pode ver, o ping foi bem-sucedido, pois não temos nenhuma ACL que proíba ou filtre o tráfego. Também estou livre para executar ping no Server0.
Agora vamos para o roteador Router1, entram no modo de configurações globais e criam a lista do ACL 101. Para fazer isso, digite o comando access-list 101 allow tcp. Observe que o sistema fornece uma dica de qual valor de parâmetro, além de tcp, pode ser usado neste comando.
esp, icmp, osfp . CCNA ip, ismp, tcp udp.
, access-list 101 permit tcp 192.168.1.224. /28 16 , 0.0.0.15.
28 4 , 1 , 128, 2 – 64, – 32, 4 16, , (16-1) =15. , . , host IP-, : access-list 101 permit tcp 192.168.1.224 0.0.0.15 host 192.168.1.194.
, , , .
dscp, , eq, , gt – , , lt – .. , eq. .
0 65535, , . FTP 21, SMTP – 25, www – HTTP- 80. 80.
do show run , , 80 www. , , 80 21: access-list 101 permit tcp 192.168.1.224 0.0.0.15 host 192.168.1.194 eq 21.
ICMP-, . access-list 101 permit icmp. host, , IP- 192.168.1.226 0.0.0.0, , . host IP- Laptop2 – 192.168.1.2. – , .
, echo-replay. , . : access-list 101 permit icmp192.168.1.226 0.0.0.0 host 192.168.1.2 echo-replay. : access-list 101 permit icmp 192.168.1.226 0.0.0.0 host 192.168.1.130 echo-replay.
, int g0/0 ip access-group, 101 , IN. Laptop0 192.168.1.194, ACL . , , . IP- 192.168.1.195, .
, Server0 Laptop0 . HTTP FTP- 80 21, ICMP-, . .
-, 192.168.1.194, - Server0.
192.168.1.195, , ACL .
№1 R2 ACL – Allow_Ac. , ACL , . ip access-list extended Allow_Ac .
permit tcp 192.168.1.128. /26, , , – 128, – 64, , 0.0.0.63. , 255.255.255.192 255.255.255.255. permit tcp 192.168.1.128 0.0.0.63 host 192.168.1.194 eq 80. : permit tcp 192.168.1.128 0.0.0.63 host 192.168.1.194 eq 21.
№1 – PC0 Laptop0 . permit ip host 192.168.1.130 host 192.168.1.226 , .
ACL g0/0, ip access-group Allow_Ac IN. , PC0 Server 0, - . PC0 192.168.1.194, Packet Tracer, , R2 .
ACL , ip access-list extended Allow_Sa permit tcp host 192.168.1.3 host 192.168.1.195 eq 80. , HTTP- , , deny ip host 192.168.1.3 any.
, , . deny icmp 192.168.1.0. /25, 1 , 128 , , 0.0.0.127. 192.168.1.195, Server2. ACL : deny icmp 192.168.1.0 0.0.0.127 host 192.168.1.195 echo.
4- , , : permit ip 192.168.1.0 0.0.0.127 host 192.168.1.195.
, Laptop2 Laptop0. permit host 192.168.1.2 host 192.168.1.226, g0/1 ip access-group Allow_Sa IN.
, ACL Laptop3, , - . 192.168.1.195 , PC 192.168.1.130 192.168.1.226. , – - Server1.
Laptop2 Laptop0, . , , 192.168.1.226. Laptop1 , ACL , Laptop0. Laptop2 Server1 192.168.1.195, - . , 4- , ACL.
, , . ACL – , . , , , .
CCNA , . , . , .
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um
desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd 2 vezes mais barato? Somente temos
2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?