|
|
| Linha 33: |
Linha 33: |
| | = Atividade = | | = Atividade = |
| | | | |
| − | Vamos realizar um experimento para entender melhor como funciona o STP. Isso nos dará base para aplicá-lo no caso da rede da escola (o que faremos na pŕoxima aula).
| + | Realize as [[PJI11103:_Lab_7#Parte_2:_O_protocolo_STP_como_poss.C3.ADvel_solu.C3.A7.C3.A3o|partes 2 e 3]] dos experimentos de hoje. |
| − | | |
| − | Usem este arquivo de configuração do Netkit para o experimento:
| |
| − | | |
| − | {{collapse top|Configuração do netkit}}
| |
| − | <syntaxhighlight lang=text>
| |
| − | sw1[type]=switch
| |
| − | sw2[type]=switch
| |
| − | sw3[type]=switch
| |
| − | sw4[type]=switch
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − | pc4[type]=generic
| |
| − |
| |
| − | # Ativação do STP nos switches | |
| − | sw1[stp]=on
| |
| − | sw2[stp]=on
| |
| − | sw3[stp]=on
| |
| − | sw4[stp]=on
| |
| − |
| |
| − | sw1[eth0]=sw1-sw2
| |
| − | sw1[eth1]=sw1-port1
| |
| − | sw1[eth2]=sw1-sw3
| |
| − | sw1[eth3]=sw1-sw4
| |
| − |
| |
| − | sw2[eth0]=sw1-sw2
| |
| − | sw2[eth1]=sw2-port1
| |
| − | sw2[eth2]=sw2-sw3
| |
| − | sw2[eth3]=sw2-sw4
| |
| − |
| |
| − | sw3[eth0]=sw1-sw3
| |
| − | sw3[eth1]=sw3-port1
| |
| − | sw3[eth2]=sw2-sw3
| |
| − | sw3[eth3]=sw3-sw4
| |
| − |
| |
| − | sw4[eth0]=sw1-sw4
| |
| − | sw4[eth1]=sw2-sw4
| |
| − | sw4[eth2]=sw3-sw4
| |
| − | sw4[eth3]=sw4-port4
| |
| − | | |
| − | pc1[eth0]=sw1-port1:ip=192.168.0.1/24
| |
| − | pc2[eth0]=sw2-port1:ip=192.168.0.2/24
| |
| − | pc3[eth0]=sw3-port1:ip=192.168.0.3/24
| |
| − | pc4[eth0]=sw4-port4:ip=192.168.0.4/24
| |
| − | </syntaxhighlight>
| |
| − | {{collapse bottom}}
| |
| − | | |
| − | [[Netkit#STP_.28Spanning_Tree_Protocol.29|Switches e STP (Spanning Tree Protocol) no Netkit]]
| |
| − | | |
| − | ... ver também:
| |
| − | * timers do STP (hello e max-age), que influenciam o tempo de convergência do protocolo
| |
| − | | |
| − | <!-- = 24/04: Acrescentando enlaces redundantes na rede da escola =
| |
| − | | |
| − | Voltando à segmentação da rede do campus São José, vamos acrescentar alguns enlaces para conferir um grau de tolerância a falhas:
| |
| − | | |
| − | | |
| − | {| border="0" cellpadding="2"
| |
| − | |-
| |
| − | |[[imagem:Ifsc-sj-simples.png|400px]] || [[imagem:Ier-seta.png]]|| [[imagem:Nova-rede-ifsc-sj.png|400px]]
| |
| − | |}
| |
| − | | |
| − | | |
| − | Dada a dimensão da rede, isso será realizado usando o [[Netkit]]. Sendo assim, implante a rede acima e ative o STP para tratar os caminhos fechados. Em seguida, experimente modificar alguns links para verificar se a rede continua funcionando.
| |
| − | | |
| − | {{collapse top|Modelo da rede do IFSC-SJ para o Netkit}}
| |
| − | <syntaxhighlight lang=text>
| |
| − | # switches
| |
| − | sw-rnp[type]=switch
| |
| − | sw-redes1[type]=switch
| |
| − | sw-redes2[type]=switch
| |
| − | sw-coinf[type]=switch
| |
| − | sw-labdes[type]=switch
| |
| − |
| |
| − | # gateways
| |
| − | asa5510[type]=gateway
| |
| − | gw-redes1[type]=gateway
| |
| − | gw-redes2[type]=gateway
| |
| − |
| |
| − | # computadores e servidores
| |
| − | bd[type]=generic
| |
| − | dmz1[type]=generic
| |
| − | dmz2[type]=generic
| |
| − | adm1[type]=generic
| |
| − | adm2[type]=generic
| |
| − | adm3[type]=generic
| |
| − | pedag1[type]=generic
| |
| − | pedag2[type]=generic
| |
| − | pc-redes1[type]=generic
| |
| − | pc-redes2[type]=generic
| |
| − |
| |
| − | # Portas dos switches
| |
| − | sw-rnp[eth0]=rnp-port0
| |
| − | sw-rnp[eth1]=rnp-port1
| |
| − | sw-rnp[eth2]=rnp-port2
| |
| − | sw-rnp[eth3]=rnp-port3
| |
| − | sw-rnp[eth4]=rnp-port4
| |
| − | sw-rnp[eth5]=rnp-port5
| |
| − |
| |
| − | sw-redes1[eth0]=redes1-port0
| |
| − | sw-redes1[eth1]=redes1-port1
| |
| − |
| |
| − | sw-redes2[eth0]=redes2-port0
| |
| − | sw-redes2[eth1]=redes2-port1
| |
| − |
| |
| − | sw-coinf[eth0]=coinf-port0
| |
| − | sw-coinf[eth1]=coinf-port1
| |
| − | sw-coinf[eth2]=coinf-port2
| |
| − | # Ligações entre switches
| |
| − | sw-coinf[eth3]=rnp-port5
| |
| − | sw-coinf[eth4]=labdes-port3
| |
| − |
| |
| − | sw-labdes[eth0]=labdes-port0
| |
| − | sw-labdes[eth1]=labdes-port1
| |
| − | sw-labdes[eth2]=labdes-port2
| |
| − | sw-labdes[eth3]=labdes-port3
| |
| − |
| |
| − | # Ligações dos computadores aos switches
| |
| − | asa5510[eth0]=rnp-port0:ip=172.18.0.254/16
| |
| − | bd[eth0]=rnp-port1:ip=172.18.0.10/16
| |
| − | dmz1[eth0]=rnp-port2:ip=172.18.0.11/16
| |
| − | adm1[eth0]=rnp-port3:ip=dhcp
| |
| − | gw-redes1[eth1]=rnp-port4:ip=172.18.0.100/16
| |
| − |
| |
| − | pc-redes1[eth0]=redes1-port1:ip=192.168.1.2/24
| |
| − | gw-redes1[eth0]=redes1-port0:ip=192.168.1.1/24
| |
| − |
| |
| − | pc-redes2[eth0]=redes2-port1:ip=192.168.2.2/24
| |
| − | gw-redes2[eth0]=redes2-port0:ip=192.168.2.1/24
| |
| − |
| |
| − | dmz2[eth0]=coinf-port0:ip=172.18.0.13/16
| |
| − | adm2[eth0]=coinf-port1:ip=dhcp
| |
| − | pedag1[eth0]=coinf-port2:ip=dhcp
| |
| − |
| |
| − | adm3[eth0]=labdes-port0:ip=dhcp
| |
| − | pedag2[eth0]=labdes-port1:ip=dhcp
| |
| − | gw-redes2[eth1]=labdes-port2:ip=172.18.0.101/16
| |
| − |
| |
| − | # ASA 5510 é servidor dhcp da LAN ...
| |
| − | asa5510[dhcp]=eth0:range=172.18.100.1,172.18.100.250:gateway=172.18.0.254
| |
| − |
| |
| − | # Gateways default dos computadores que usam IP fixo
| |
| − | gw-redes1[default_gateway]=172.18.0.254
| |
| − | gw-redes2[default_gateway]=172.18.0.254
| |
| − | pc-redes1[default_gateway]=192.168.1.1
| |
| − | pc-redes2[default_gateway]=192.168.2.1
| |
| − | bd[default_gateway]=172.18.0.254
| |
| − | dmz1[default_gateway]=172.18.0.254
| |
| − | dmz2[default_gateway]=172.18.0.254
| |
| − | </syntaxhighlight>
| |
| − | {{collapse bottom}}
| |
| − | -->
| |
| − | | |
| − | <!-- = 07/11: Fazendo controle de acesso em redes locais =
| |
| − | | |
| − | * [http://tele.sj.ifsc.edu.br/~msobral/RCO2/listas/2012-1/lista3.pdf 3a lista de exercícios]
| |
| − | * [http://www.sj.ifsc.edu.br/~msobral/RCO2/avaliacoes/2010-1/prova3-2010-1.pdf Prova de 2010-1]
| |
| − | | |
| − | | |
| − | | |
| − | == Controlando o acesso à rede da escola ==
| |
| − | | |
| − | A gerência de rede concluiu que deve-se controlar os acessos aos pontos da rede da escola. Com isso, somente usuários devidamente autenticados e autorizados poderão se comunicar usando os pontos de rede. A forma com que isso deve ser feito deve impedir inclusive que uma pessoa conecte um laptop a uma tomada de rede, e consiga acessar a rede. Além disso, o acesso pode ser negado ou concedido dependendo do tipo de usuário (aluno, funcionário, professor, visitante) e da localização do ponto de rede. O mecanismo de segurança capaz de fazer isso deve agir portanto diretamente nas portas de switches, habilitando-as ou bloqueando-as dependendo do usuário que tentar usar o equipamento nela conectado.
| |
| − | | |
| − | === Padrão IEEE 802.1x ===
| |
| − | | |
| − | * Ver [http://www.sj.ifsc.edu.br/~msobral/RCO2/slides/aula12.pdf transparências]
| |
| − | * [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/802.1x_book_c2.pdf Capítulo de um livro sobre IEEE 802.1x]
| |
| − | * [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/lab10.pdf Roteiro da experiência]
| |
| − | ** [http://www.sj.ifsc.edu.br/~msobral/RCO2/roteiros/rco2.conf Arquivo de configuração do wpa_supplicant (rco2.conf)]
| |
| − | | |
| − | | |
| − | O padrão [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/ieee/802.1X-2004.pdf IEEE 802.1x] define um framework para controle de acesso a redes locais IEEE 802, sendo usado tanto em redes cabeadas quanto sem-fio. O propósito dessa norma é criar mecanismos para identificar e autorizar ou não o acesso de um usuário à infraestrutura da rede. Esses mecanismos são implementados em três componentes que forma a estrutura de controle de acesso IEEE 802.1x, mostrada na figura abaixo:
| |
| − | | |
| − | [[imagem:Ieee-8021x.png]]
| |
| − | | |
| − | * '''Supplicant:''' o cliente que deseja se autenticar. Implementado com um software (ex: [http://hostap.epitest.fi/wpa_supplicant/ wpa_supplicant], [http://open1x.sourceforge.net/ xsupplicant]).
| |
| − | * '''Autenticador:''' o equipamento que dá acesso à rede para o cliente, e onde é feito o bloqueio ou liberação do uso da rede. Implementado em switches e Access Points (no caso de redes sem-fio).
| |
| − | * '''Servidor de Autenticação:''' o equipamento que verifica as credenciais fornecidas pelo ''supplicant'', e informa ao ''autenticador'' se ele pode ou não acessar a rede. Implementado comumente em um servidor [http://en.wikipedia.org/wiki/RADIUS Radius].
| |
| − | | |
| − | A autenticação se faz com protocolos específicos definidos na norma IEEE 802.1x:
| |
| − | | |
| − | * '''EAP (Extensible Authentication Protocol):''' protocolo para intercâmbio de informações de autenticação entre supplicant e servidor de autenticação.
| |
| − | * '''EAPOL (EAP over LAN):''' protocolo para transportar as PDUs EAP entre supplicant e autenticador.
| |
| − | | |
| − | [[imagem:Ieee-802x-eap.png]]
| |
| − | | |
| − | Existem vários métodos EAP, que correspondem a diferentes mecanismos de autenticação. Assim, o método de autenticação pode ser escolhido de acordo com as necessidades de uma rede.
| |
| − | | |
| − | * '''EAP-MD5:''' baseado em login e senha, usa um desafio MD5 para autenticar o usuário.
| |
| − | * '''EAP-TLS:''' baseado em certificados digitais X.509, usados para autenticar a rede para o supplicant, e o supplicant para a rede.
| |
| − | * '''EAP-TTLS:''' também baseado em certificados digitais, mas somente para autenticar a rede pro supplicant. O supplicant se autentica com algum outro método EAP mais simples, como EAP-MD5.
| |
| − | * ... [http://freeradius.org/features/eap.html e muitos outros !]
| |
| − | -->
| |
| − | <!-- === TRABALHO SOBRE LANS === -->
| |
- Capítulo 16 do livro "Comunicação de Dados e Redes de Computadores, 3a ed.", de Behrouz Forouzan.
- Capítulo 5 do livro "Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição, de James Kurose.
- Capítulo 4 do livro "Redes de Computadores, 4a ed.", de Andrew Tanenbaum.
No laboratório de Redes 2, um certo dia um aluno acidentalmente pegou um cabo e ligou em duas tomadas de rede. Quer dizer, ele fez algo assim com um dos switches da rede:
Para ver a consequência dessa ação aparentemente inocente, experimente reproduzi-la no laboratório, e analise o que aocnteceu.
Atividade
Realize este experimento sobre caminho fechado na LAN.
O problema dos ciclos (caminhos fechados) em uma rede local ethernet
A interligação acidental de duas portas de um switch cria um ciclo na rede local (loop). Mas isso pode ser feito também de forma intencional, pois em LANs grandes pode ser desejável ter enlaces redundantes, para evitar que a interrupção de um enlace isole parte da rede. A existência de interligações alternativas portanto é algo que pode ocorrer em uma rede local, seja por acidente ou com a finalidade de conferir algum grau de tolerância a falhas na infraestrutura da rede. Um caso em que uma rede possui um ciclo intencionalmente colocado pode ser visto na LAN abaixo:
Apesar de desejável em algumas situações, uma topologia de rede com caminhos fechados, como visto na figura acima, não pode ser instalada sem alguns cuidados. Uma rede como essa trancaria devido a um efeito chamado de tempestade de broadcasts (broadcast storm). Isso acontece porque, ao receber um quadro em broadcast, um switch sempre o retransmite por todas as demais portas. Para que a rede acima funcione como esperado, uma ou mais portas de switches precisarão ser desativadas de forma que o caminho fechado seja removido. Ter que fazer isso manualmente tira o sentido de ter tal configuração para tolerância a falhas (e não impede um "acidente" como aquele descrito no início desta secão), por isso foi criado o protocolo STP (Spanning Tree Protocol, definido na norma IEEE 802.1d) para realizar automaticamente essa tarefa.
Atividade
Realize as partes 2 e 3 dos experimentos de hoje.
