|
|
| (188 revisões intermediárias por 3 usuários não estão sendo mostradas) |
| Linha 1: |
Linha 1: |
| − | __NOTOC__
| + | {{DivulgueEngtelecom}} |
| | | | |
| − | {{DivulgueEngtelecom}}
| |
| | ==[[RED1-EngTel|Carga horária, Ementas, Bibliografia]]== | | ==[[RED1-EngTel|Carga horária, Ementas, Bibliografia]]== |
| | ==[[Cronograma de atividades (RED1-EngTel) | Cronograma de atividades ]]== | | ==[[Cronograma de atividades (RED1-EngTel) | Cronograma de atividades ]]== |
| | ==[[RED1-EngTel (Plano de Ensino) | Plano de Ensino]]== | | ==[[RED1-EngTel (Plano de Ensino) | Plano de Ensino]]== |
| | | | |
| − | ==Edições==
| + | =Edições= |
| | + | *[[RED29004-Laboratórios_com_Imunes|RED29004 2020 em diante - Prof. Odilson T. Valle]] |
| | + | *[[RED29004-Laboratórios|RED29004 2020-1 - Prof. Odilson T. Valle]] |
| | + | *[[RED29004-Laboratórios|RED29004 2019-1 - Prof. Tiago Semprebom]] |
| | + | *[[RED29004-Laboratórios|RED29004 2018-2 - Prof. Odilson T. Valle]] |
| | + | *[[RED29004-Laboratórios|RED29004 2018-1 - Prof. Odilson T. Valle]] |
| | *[[RED29004-2017-2|RED29004 2017-2 - Prof. Odilson T. Valle]] | | *[[RED29004-2017-2|RED29004 2017-2 - Prof. Odilson T. Valle]] |
| | *[[RED29004-2017-1|RED29004 2017-1 - Prof. Odilson T. Valle]] | | *[[RED29004-2017-1|RED29004 2017-1 - Prof. Odilson T. Valle]] |
| Linha 18: |
Linha 22: |
| | | | |
| | = Material de apoio = | | = Material de apoio = |
| − | | + | <!-- |
| − | ==''Applets'' do Kurose== | + | ==Roteiros de laboratório== |
| − | Vários [http://wps.pearsoned.com/ecs_kurose_compnetw_6/216/55463/14198700.cw/ aplicativos] com representação dinâmica de características das redes de computadores.
| + | #[[RED29004-Laboratórios com Imunes#Ferramentas_b.C3.A1sicas:_Ping_e_Traceroute | Ferramentas Básicas: Ping e Traceroute]] |
| | + | #[[RED29004-Laboratórios com Imunes#Ferramentas_b.C3.A1sicas:_WireShark_e_tcpdump | Ferramentas básicas: WireShark e tcpdump]] |
| | + | #[[RED29004-Laboratórios com Imunes#Desvendando_o_HTTP_com_Wireshark | Desvendando o HTTP com Wireshark]] |
| | + | #[[RED29004-Laboratórios com Imunes#Desvendando_o_HTTP_com_Wireshark.2C_parte_2 | Desvendando o HTTP com Wireshark - Parte 2]] |
| | + | #[[RED29004-Laboratórios com Imunes#Servi.C3.A7o_de_Nomes_.28DNS.29 | Serviço de Nomes (DNS)]] |
| | + | #[[RED29004-Laboratórios com Imunes#Comparando_sockets_UDP_e_TCP | Comparando sockets UDP e TCP]] |
| | + | #[[RED29004-Laboratórios com Imunes#TCP_x_UDP | TCP x UDP]] |
| | + | #[[RED29004-Laboratórios com Imunes#Desvendando_o_TCP_-_N.C3.BAmero_de_Sequ.C3.AAncia.2C_Controle_de_Erros.2C_transmiss.C3.A3o_duplex | Desvendando o TCP - Número de Sequência, Controle de Erros, transmissão ''duplex'']] |
| | + | #[[RED29004-Laboratórios com Imunes#TCP:_Controle_de_congestionamento_e_equidade | TCP: Controle de congestionamento e equidade]] |
| | + | #[[RED29004-Laboratórios com Imunes#Interliga.C3.A7.C3.A3o_de_duas_redes_atrav.C3.A9s_de_um_roteador | Interligação de duas redes através de um roteador]] |
| | + | #[[RED29004-Laboratórios com Imunes#Tabelas_Est.C3.A1ticas_de_Roteamento | Tabelas Estáticas de Roteamento]] |
| | + | #[[RED29004-Laboratórios com Imunes#Protocolos_de_roteamento_din.C3.A2micos_-_RIP_e_OSPF | Protocolos de roteamento dinâmicos - RIP e OSPF]] |
| | + | #[[RED29004-Laboratórios com Imunes#Neighbor_Discovery_e_roteamento_est.C3.A1tico_no_IPv6 | ''Neighbor Discovery'' e roteamento estático no IPv6]] |
| | + | --> |
| | | | |
| | == Listas de exercícios== | | == Listas de exercícios== |
| Linha 262: |
Linha 279: |
| | #Se as redes Ethernet atualmente podem operar com switches (Ethernet comutada), e em modo fullduplex, porque ainda existe o protocolo MAC CSMA/CD? | | #Se as redes Ethernet atualmente podem operar com switches (Ethernet comutada), e em modo fullduplex, porque ainda existe o protocolo MAC CSMA/CD? |
| | #Switches Ethernet Gerenciáveis são equipamentos de comutação de pacotes que podem ser configurados e observados pelos administradores de redes. Entre as informações que um administrador de rede tem acesso em um switch destes está a relação de endereços MAC conectados em cada porta do equipamento. Um administrador de rede detectou que existe um computador inundando a rede com tráfego intenso (o que pode ser causado por um virus). No entanto, ao capturar alguns dos datagramas IP desse fluxo intenso, o administrador não conseguiu reconhecer o endereço IP do computador, uma vez que ele varia entre diferentes datagramas (uma técnica para camuflar sua origem). Porém ele notou que o endereço MAC de origem, contido nos respectivos quadros Ethernet, é sempre o mesmo, o que identifica o computador que emite este tráfego. Sabendo que a rede é composta de vários switches Ethernet gerenciáveis, como o administrador poderia, sem sair de sua sala, localizar rapidamente esse computador? | | #Switches Ethernet Gerenciáveis são equipamentos de comutação de pacotes que podem ser configurados e observados pelos administradores de redes. Entre as informações que um administrador de rede tem acesso em um switch destes está a relação de endereços MAC conectados em cada porta do equipamento. Um administrador de rede detectou que existe um computador inundando a rede com tráfego intenso (o que pode ser causado por um virus). No entanto, ao capturar alguns dos datagramas IP desse fluxo intenso, o administrador não conseguiu reconhecer o endereço IP do computador, uma vez que ele varia entre diferentes datagramas (uma técnica para camuflar sua origem). Porém ele notou que o endereço MAC de origem, contido nos respectivos quadros Ethernet, é sempre o mesmo, o que identifica o computador que emite este tráfego. Sabendo que a rede é composta de vários switches Ethernet gerenciáveis, como o administrador poderia, sem sair de sua sala, localizar rapidamente esse computador? |
| − | #Um pacote de uma camada superior de redes é dividido em 10 quadros, e cada quadro tem 80% de chances de chegar sem danos. Se o protocolo de enlace de dados não fizer qualquer controle de erros, quantas vezes em média a mensagem deverá ser enviada para que o processo inteiro seja concluído?
| |
| | #Explique o que é colisão e como estas impactam o tráfego de uma rede Ethernet. Explique como a mesma é evitada em redes comutadas, explicando como o uso de switches limitam as colisões quando comparados com hubs ou barramentos. | | #Explique o que é colisão e como estas impactam o tráfego de uma rede Ethernet. Explique como a mesma é evitada em redes comutadas, explicando como o uso de switches limitam as colisões quando comparados com hubs ou barramentos. |
| | #Por que uma pesquisa ARP é enviada dentro de um quadro ''broadcast''? Por que uma resposta ARP é enviada dentro de um quadro com endereço MAC específico? Qual é a diferença entre esses dois quadros? | | #Por que uma pesquisa ARP é enviada dentro de um quadro ''broadcast''? Por que uma resposta ARP é enviada dentro de um quadro com endereço MAC específico? Qual é a diferença entre esses dois quadros? |
| Linha 292: |
Linha 308: |
| | | | |
| | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] | | [http://docente.ifsc.edu.br/odilson/RED29004/PPTs%20-%20Cap%C3%ADtulo%205%20Camada%20de%20enlace.pdf Slides do Kurose referentes ao capítulo 5] |
| − |
| |
| − | == Roteiros para laboratório ==
| |
| − | {{Collapse top |Laboratório 1 - Ping, Traceroute e Wireshark}}
| |
| − | ===Objetivos===
| |
| − | *Familiarização com a infraestrutura dos laboratórios de redes
| |
| − | *Conhecer aplicativos para verificar os parâmetros do TCP/IP
| |
| − | *Diagnosticar o atraso dos pacotes
| |
| − | *Traçar rotas em redes TCP/IP
| |
| − | *Familiarização com o ''sniffer'' de rede WireShark
| |
| − |
| |
| − | ===Conceitos introdutórios para uso do laboratório===
| |
| − | A rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1.
| |
| − |
| |
| − | [[Arquivo:Diagrama_rede_IFSC_lab_redes_I.jpeg |thumb | 400px| Figura 1 - Diagrama da rede do laboratório]]
| |
| − |
| |
| − | ====Máquinas virtuais====
| |
| − | Eventualmente serão utilizadas nessa disciplina.
| |
| − |
| |
| − | Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede '''/24''' indica que o último ''byte'' do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc.
| |
| − | O sistema operacional hospedeiro é o '''Linux Ubuntu'''. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de ''root'' (administrador).
| |
| − | Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo '''VirtualBox'''. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o ''byte'' que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101.
| |
| − |
| |
| − | ===Roteiro de atividades===
| |
| − | ====ifconfig====
| |
| − | O aplicativo '''ifconfig''' pode ser utilizado para visualizar a configuração ou configurar uma interface de host em redes TCP/IP. Se nenhum argumento for passado na chamada do '''ifconfig''', o comando mostra a configuração atual de cada interface de rede.
| |
| − |
| |
| − | Consultar as páginas ''man ifconfig'' do Linux para maiores detalhes sobre o funcionamento deste aplicativo, o qual permite ativar/desativar a interface, configurar o endereço IP, definir o tamanho da MTU, redefinir o endereço de hardware se a interface suporta, redefinir a interrupção utilizada pelo dispositivo, entre outros.
| |
| − |
| |
| − |
| |
| − | #Analisando os dados obtidos do seguinte exemplo <code>ifconfig
| |
| − | eth0 Link encap:Ethernet Endereço de HW 64:51:06:1a:f3:da
| |
| − | inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0
| |
| − | endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link
| |
| − | UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1
| |
| − | pacotes RX:415237 erros:0 descartados:0 excesso:0 quadro:0
| |
| − | Pacotes TX:118109 erros:0 descartados:0 excesso:0 portadora:0
| |
| − | colisões:0 txqueuelen:1000
| |
| − | RX bytes:364658695 (364.6 MB) TX bytes:18315199 (18.3 MB)
| |
| − | IRQ:18
| |
| − |
| |
| − | lo Link encap:Loopback Local
| |
| − | inet end.: 127.0.0.1 Masc:255.0.0.0
| |
| − | endereço inet6: ::1/128 Escopo:Máquina
| |
| − | UP LOOPBACK RUNNING MTU:65536 Métrica:1
| |
| − | pacotes RX:6688 erros:0 descartados:0 excesso:0 quadro:0
| |
| − | Pacotes TX:6688 erros:0 descartados:0 excesso:0 portadora:0
| |
| − | colisões:0 txqueuelen:0
| |
| − | RX bytes:1057934 (1.0 MB) TX bytes:1057934 (1.0 MB) </syntaxhighlight>
| |
| − | ##O sistema em questão possui duas interfaces de rede: '''eth0''' e '''lo'''
| |
| − | ##'''Link encap:Ethernet''': Configuração da interface '''Eth'''ernet 0 (primeira)
| |
| − | ##'''Endereço de HW 64:51:06:1a:f3:da''': É o endereço da placa de rede, camada 2
| |
| − | ##'''inet end.: 172.18.18.14 Bcast:172.18.63.255 Masc:255.255.192.0''': Endereço IPv4 associado a interface, seu respectivo endereço de ''broadcast'' e mascara de rede
| |
| − | ##endereço inet6: fe80::6651:6ff:fe1a:f3da/64 Escopo:Link: Endereço IPv6 de escopo local gerado por autoconfiguração
| |
| − | ##'''UP BROADCAST RUNNING MULTICAST''': Significa que a interface está ativa (UP), responde a requisições de broadcast (pode ser desabilitado no kernel) e também pode ser associada a tráfegos ''multicast''
| |
| − | ##'''MTU: 1500''': ''Maximum Transfer Unit'' – Tamanho máximo do pacote suportado pelo enlace que é do tipo Ethernet
| |
| − | ##Os demais parâmetros são estatísticas da respectiva interface, como por exemplo, pacotes transmitidos, recebidos etc
| |
| − | ##A interface '''lo''': Qualquer tráfego que um computador envie em uma rede ''loopback'' é endereçada ao mesmo computador. O endereço IP mais usado para tal finalidade é 127.0.0.1 no IPv4 e ::1 no IPv6. O nome de domínio padrão para tal endereço é ''localhost''. Em sistemas Unix, a interface loopback é geralmente chamada de lo ou lo0.
| |
| − | #Agora utilize o comando '''ifconfig''' para verificar o estado de suas interfaces e responda:
| |
| − | ##Quantas e quais interfaces de rede sua máquina possui? Liste.
| |
| − | ##Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços?
| |
| − | ##Quais são os endereços IPv4? De onde o sistema obteve esses endereços?
| |
| − | ##Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo?
| |
| − |
| |
| − | ====ping====
| |
| − | Aplicativo '''ping''' permite a um usuário verificar se um ''host'' remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede.
| |
| − | O '''ping''' está baseado no envio de mensagens de solicitação de eco (''echo request'') e de resposta de eco (''echo reply''). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP.
| |
| − |
| |
| − | O '''ping''' é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP.
| |
| − |
| |
| − | Consultar as páginas ''man'' do ping para verificar as possibilidades de uso deste aplicativo.
| |
| − |
| |
| − | #Exemplo 1: <code>
| |
| − | PING 200.135.37.65 (200.135.37.65) 56(84) bytes of data.
| |
| − | 64 bytes from 200.135.37.65: icmp_seq=1 ttl=62 time=0.925 ms
| |
| − | 64 bytes from 200.135.37.65: icmp_seq=2 ttl=62 time=0.743 ms
| |
| − | 64 bytes from 200.135.37.65: icmp_seq=3 ttl=62 time=0.687 ms
| |
| − | 64 bytes from 200.135.37.65: icmp_seq=4 ttl=62 time=0.689 ms
| |
| − | ^C
| |
| − | --- 200.135.37.65 ping statistics ---
| |
| − | 4 packets transmitted, 4 received, 0% packet loss, time 2999ms
| |
| − | rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms </syntaxhighlight>
| |
| − | ##No exemplo foram enviados quatro pacotes ICMP, cada um com um número de seqüência (''icmp_seq''), os quais foram recebidos com sucesso com o tempo de viagem assinalado (''time'')
| |
| − | ##Cada pacote tem ainda um tempo de vida (''ttl'' – ''time to live''), o qual é decrementado em cada roteador, sendo o pacote descartado quando chegar a zero; isto evita pacotes perdidos na rede
| |
| − | ##Quando o ping é interrompido ('''CRTL-C'''), uma estatística é apresentada indicando o percentual de pacotes transmitidos, recebidos e perdidos
| |
| − | ##O tempo de viagem (''rtt'' – ''round trip time'') mínimo (''min''), médio (''avg'') e máximo (''max'') é calculado, assim como o desvio padrão (''mdev'')
| |
| − | #Como exercício envie '''ping''' para diferentes ''hosts'' e compare os tempos de resposta:
| |
| − | ##no endereço local de loopback;
| |
| − | ##máquina de um colega do laboratório;
| |
| − | ##servidor e roteador da rede da escola;
| |
| − | ##servidores externos: <code>
| |
| − | www.ifsc.edu.br
| |
| − | www.uol.com.br
| |
| − | www.nasa.com
| |
| − | www.polito.it </syntaxhighlight>
| |
| − | #Explique as diferenças entre os tempos de resposta dos ping realizados:
| |
| − | ##Entre ping para diferentes destinos.
| |
| − | ##Entre respostas recebidas de um mesmo destino.
| |
| − | #Consulte as páginas ''man'' e teste o '''ping''' com os parâmetros abaixo e descreva suas funcionalidades:
| |
| − | ##-c count
| |
| − | ##-i intervalo
| |
| − | ##-s packetsize
| |
| − | ##-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens)
| |
| − | ##-b (Se desejarmos descobrir o endereço IP de vários ''hosts'' em uma rede local, poderemos utilizar o '''ping''' no endereço de ''broadcast'')
| |
| − | #*No Ubuntu a resposta a um ping no endereço de broadcast é desabilitada por padrão e somente o administrador pode habilitar esta funcionalidade. Quem desejar testar esse tipo de ping deverá utilizar uma máquina virtual qualquer (VirtualBox) e habilitar a resposta a um '''ping''' no endereço de ''broadcast''. Para tal, primeiro iniciamos uma máquina virtual, logamos como aluno/aluno e depois executamos em um terminal os comandos abaixo<code>
| |
| − | sudo su
| |
| − | echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts </syntaxhighlight> em seguida esta máquina responderá a '''ping''' no ''broadcast''.
| |
| − | ##Execute um ping ''broadcast'' e explique porque aparece o termo ''(DUP!)'' após cada resposta. Dica: observe o número de sequência.
| |
| − |
| |
| − | ====traceroute====
| |
| − | O '''traceroute''' é capaz de traçar uma rota aproximada entre dois ''hosts''. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (''time to live'' – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores.
| |
| − |
| |
| − | O '''traceroute''' envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída.
| |
| − |
| |
| − | #Exemplo: <code>
| |
| − | traceroute 200.135.37.65
| |
| − | traceroute to 200.135.37.65 (200.135.37.65), 30 hops max, 60 byte packets
| |
| − | 1 192.168.1.1 (192.168.1.1) 0.225 ms 0.216 ms 0.368 ms
| |
| − | 2 172.18.0.254 (172.18.0.254) 1.236 ms 1.235 ms 1.343 ms
| |
| − | 3 hendrix.sj.ifsc.edu.br (200.135.37.65) 1.331 ms 1.313 ms 1.414 ms </syntaxhighlight> O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (192.168.2.1) e o servidor ''hendrix'' (200.135.37.65). Observe que para cada roteador são realizados três amostras de tempo de ida e volta. Veja pelo mapa da rede do Campus São José que entre estes dois computadores, sistemas finais, existem dois roteadores intermediários, máquina do professor e Switch camada 3 (VLANs).
| |
| − | #Traçar a rota dos pacotes entre seu computador e diferentes hosts:
| |
| − | ##máquina de um colega do laboratório
| |
| − | ##servidor e roteador da rede da escola
| |
| − | ##servidores externos.
| |
| − | #Explique as diferenças entre os tempos de resposta:
| |
| − | ##Entre traceroutes para diferentes destinos.
| |
| − | ##Entre as três medidas apresentadas para cada salto.
| |
| − | ##O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 13 um tempo de 289.207 ms e no salto 14 um tempo de 277.115 ms.
| |
| − | #Explique as linhas com o caracter *.
| |
| − |
| |
| − | ====WireShark====
| |
| − | 2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados
| |
| − |
| |
| − | *Introdução
| |
| − | O entendimento de protocolos de redes pode ser bastante aprofundado através da “observação de protocolos funcionando” e “da manipulação de protocolos” - observando a sequência de mensagens trocadas entre duas entidades, entrando nos detalhes da operação do protocolo, e fazendo com que os protocolos realizem certas ações e então observando estas ações e as consequências.
| |
| − |
| |
| − | A ferramenta básica para observar as mensagens trocadas entre as entidades em execução é chamada de ''sniffer''. Como o nome sugere, um ''sniffer'' captura mensagens sendo enviadas/recebidas pelo seu computador; ele também tipicamente armazena e/ou apresenta os conteúdos dos vários campos dos protocolos nestas mensagens capturadas. Um ''sniffer'' isoladamente é um elemento passivo. Ele observa as mensagens sendo enviadas e recebidas pelas aplicações e protocolos executando no seu computador, mas jamais envia pacotes. Similarmente, os pacotes recebidos nunca são explicitamente endereçados ao ''sniffer''. Ao invés disso, um ''sniffer'' recebe uma cópia de pacotes que são enviados/recebidos para/de aplicações e protocolos executando no seu computador.
| |
| − |
| |
| − | A Figura 2 mostra a estrutura de um ''sniffer''. À direita da Figura 2 estão os protocolos (neste caso, protocolos da Internet) e aplicações (tais como navegador web ou cliente FTP) que normalmente executam no seu computador. O ''sniffer'', exibido dentro do retângulo tracejado na Figura 2 é uma adição aos softwares usuais no seu computador, e consiste de duas partes: a biblioteca de captura de pacotes e o analisador de pacotes. A biblioteca de captura de pacotes recebe uma cópia de cada quadro da camada de enlace que é enviado do ou recebido pelo seu computador. Lembre que mensagens trocadas por protocolos das camadas mais altas tais como HTTP, FTP, TCP, UDP, DNS ou IP, são todos eventualmente encapsulados em quadros que são transmitidos para o meio físico como um cabo Ethernet. Na Figura 2, assume-se que o meio físico é uma Ethernet, e desta forma, os protocolos das camadas superiores são eventualmente encapsulados em um quadro Ethernet. Capturar todos os quadros fornece todas as mensagens enviadas/recebidas de/por todos os protocolos e aplicações executando em seu computador.
| |
| − |
| |
| − | [[Arquivo:Sniffer_estrutura.png |thumb | 500px| Figura 2 - Estrutura de um ''sniffer'']]
| |
| − |
| |
| − | O analisador de pacotes exibe os conteúdos de todos os campos dentro de uma mensagem de protocolo. Para que isso seja feito, o analisador de pacotes deve “entender” a estrutura de todas as mensagens trocadas pelos protocolos. Por exemplo, suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP na Figura 5. O analisador de pacotes entende o formato dos quadros Ethernet, e desta forma pode identificar o datagrama IP dentro de um quadro. Ele também entende o formato do datagrama IP, para que ele possa extrair o segmento TCP dentro do datagrama IP. Ele entende a estrutura do segmento TCP, para que possa extrair a mensagem HTTP contida no segmento. Finalmente, ele entende o protocolo HTTP e então, por exemplo, sabe que os primeiros bytes de uma mensagem HTTP contém a cadeia “GET”, “POST” ou “HEAD”. Nós utilizaremos o ''sniffer'' Wireshark (http://www.wireshark.org) para estes laboratórios, o que nos permite exibir os conteúdos das mensagens sendo enviadas/recebidas de/por protocolos em diferentes camadas da pilha de protocolos. Tecnicamente falando, Wireshark é um analisador de pacotes que pode ser executado em computadores com Windows, Linux/UNIX e MAC.
| |
| − |
| |
| − | É um analisador de pacotes ideal para nossos laboratórios, pois é estável, tem uma grande base de usuários e é bem documentado incluindo um guia de usuário (http://www.wireshark.org/docs/wsug_html/), páginas de manual (http://www.wireshark.org/docs/man-pages/), e uma seção de FAQ detalhada (http://www.wireshark.org/faq.html), funcionalidade rica que inclui a capacidade de analisar mais que 500 protocolos, e uma interface com o usuário bem projetada. Ele funciona em computadores ligados a uma Ethernet para conectar-se à Internet, bem como protocolos ponto a ponto, tal como PPP.
| |
| − |
| |
| − | *Analisando os campos da interface do Wireshark
| |
| − | Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura 3 aparecerá. Inicialmente, nenhum dado será apresentado nas janelas. A interface do Wireshark tem seis componentes principais:
| |
| − | #Os menus de comandos são localizados no topo da janela. Por enquanto, interessam apenas os menus ''File'' e ''Capture''. O menu ''File'' permite salvar dados de capturas de pacotes ou abrir um arquivo contendo dados de capturas de pacotes previamente realizadas, e sair da aplicação. O menu ''Capture'' permite iniciar uma captura de pacotes;
| |
| − | #A barra de ferramentas contém os comandos de menu que são mais frequentemente utilizados. Há atalhos para abrir ou salvar dados de captura de pacotes e para iniciar ou parar uma captura de pacotes;
| |
| − | #Abaixo da barra de ferramentas, está o campo de filtragem de pacotes exibidos. Nele podem ser digitados nome de protocolo ou outra informação apresentada na janela de listagem de pacotes. Apenas os pacotes que correspondem ao filtro são exibidos;
| |
| − | #A janela de listagem de pacotes apresenta um resumo de uma linha para cada pacote capturado, incluindo o número do pacote (atribuído pelo Wireshark; este não é o número do pacote contido no cabeçalho de qualquer protocolo), o tempo que o pacote foi capturado, os endereços fonte e destino do pacote, o tipo de protocolo, e informação específica do protocolo contida no pacote. A lista de pacotes pode ser ordenada conforme qualquer uma destas categorias clicando no nome de uma coluna correspondente. O campo tipo do protocolo lista o protocolo de mais alto nível que enviou ou recebeu este pacote, i.e., o protocolo que é a fonte ou o último sorvedouro para este pacote;
| |
| − | #A janela de detalhes de cabeçalho de pacotes fornece detalhes sobre o pacote selecionado na janela de listagem de pacotes. Para selecionar um pacote, basta clicar sobre ele com o botão esquerdo do mouse na janela de listagem de pacotes. Os detalhes apresentados incluem informações sobre o quadro Ethernet e o datagrama IP que contém o pacote. A quantidade de detalhes exibida pode ser expandida ou contraída. Se o pacote foi carregado sobre TCP ou UDP, detalhes correspondentes também são apresentados, os quais também podem ser contraídos ou expandidos. Finalmente, detalhes sobre o protocolo de mais alto nível que enviou ou recebeu este pacote também são apresentados;
| |
| − | #A janela de conteúdo de pacotes mostra o conteúdo inteiro do quadro capturado, nos formatos ASCII e hexadecimal.
| |
| − |
| |
| − | [[Arquivo:Wireshark_interface_usuario.png |thumb | 700px| Figura 3 - Interface com o usuário do Wireshark]]
| |
| − |
| |
| − | *Roteiro de atividades
| |
| − | #Inicie o navegador web;
| |
| − | #Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso;
| |
| − | #Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces.
| |
| − | #Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4); [[Arquivo:Wireshark_interfaces_rede.png |thumb | 400px| Figura 4 - Interfaces de rede no Wireshark]]
| |
| − | #Basta clicar no botão ''Start'' da interface desejada para iniciar a captura de pacotes. Na Figura 4, como o Wireshark está sendo executado no Linux, o botão Start da interface eth0 deve ser selecionado;
| |
| − | #Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio;
| |
| − | #No navegador, acesse o site http://www.ifsc.edu.br;
| |
| − | #Ao voltar para a janela do Wireshark, houve a captura de todos os pacotes envolvidos na conexão;
| |
| − | #Antes de continuar, vamos parar a captura de pacotes e trabalhar com o que temos. Basta clicar em ''Capture'' e depois em ''Stop'';
| |
| − | #Para testar as capacidades de filtragem, vamos inserir a cadeia “http” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar ''Apply'' (ou Aplicar). Um resultado similar é exibido na figura 5; [[Arquivo:Wireshark_filtro_HTTP.png |thumb | 600px| Figura 5 - Janela após a aplicação do filtro http]]
| |
| − | #Selecione a primeira mensagem HTTP exibida na janela de listagem de pacotes. Ela deve ser a mensagem HTTP GET que foi enviada do seu computador ao servidor HTTP em www.ifsc.edu.br. Quando você seleciona a mensagem HTTP GET, as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do segmento TCP e da mensagem HTTP aparecem na janela de cabeçalhos de pacotes. É possível ver os detalhes, expandido ou comprimindo os itens com um clique na seta ao lado deles.
| |
| − | #Se desejar acesse novos sítios e faça novas capturas e tente entender o que ocorre;
| |
| − | #Saia do Wireshark.
| |
| − | #Com Wireshark ativo (Abra-o novamente) acesse um sítio e responda às seguintes questões:
| |
| − | ##Teste outros filtros, por exemplo, mostre somente pacotes originados e/ou destinados a um determinado ''host'' ('''ip.addr == 192.168...'''). Anote o filtro utilizado e salve a janela do mesmo.
| |
| − | ##Elimine o filtro e anote os diferentes protocolos que aparecem na coluna ''Protocol'' na janela de listagem de pacotes;
| |
| − | ##Quanto tempo passa entre o envio de uma mensagem HTTP GET até o recebimento de uma resposta OK? (por padrão, o valor da coluna Time na janela de listagem de pacotes é a quantidade de tempo, em segundos, desde que a captura iniciou). Para exibir o campo Time no formato hora do dia, selecione o menu ''View'', depois ''Time Display Format'', então selecione ''Time of day''.
| |
| − | ##Qual é o endereço IP do sítio navegado? Qual é o endereço IP da interface de rede do seu computador? Qual o endereço MAC de sua máquina?
| |
| − |
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratório Extra - Conceituando protocolos}}
| |
| − | ===Objetivos===
| |
| − | *Conceber um protocolo/serviço de calculadora pela rede
| |
| − | *Entender o conceito de clientes e servidores de serviço.
| |
| − |
| |
| − | ===Protocolo de rede===
| |
| − | *Protocolo é o conjunto de regras sobre o modo como se dará a comunicação entre as partes envolvidas. Protocolo é a "língua" dos computadores, ou seja, uma espécie de idioma que segue normas e padrões determinados. É através dos protocolos que é possível a comunicação entre um ou mais computadores.
| |
| − |
| |
| − | ===Atividades===
| |
| − | #Desative todas as atividades de rede de seu computador.
| |
| − | #Abra o wireshark e deixe capturando mensagens com o filtro '''icmp''' ativo.
| |
| − | #A estrutura básica de um pacote que flui do cliente para o servidor e vice-versa é: [[Arquivo:Exemplo_protocolo.svg | 400px | Estrutura do Pacote'']]
| |
| − | ##'''Dst''' e '''Src''' são utilizados para identificar o nome do emissor e destinatário: as iniciais dos nomes.
| |
| − | #Cada estudante vai construir uma mensagem, respeitando o formato estabelecido, de solicitação (lado cliente). Essa mensagem deverá conter uma questão matemática, por exemplo: 2+2. Para construir a mensagem utilize o código ASCII: [http://www.theasciicode.com.ar/ Tabela ASCII]
| |
| − | #Envie essa mensagem através do comando '''ping''' com a ''flag'' ''pattern''. Ex: <code> ping -p FF0200416C6C4F6469362D3103FF 192.168.1.1 </syntaxhighlight>
| |
| − | #Ao receber uma mensagem no wireshark, interprete-a, ([http://www.rapidtables.com/convert/number/hex-to-ascii.htm Ferramenta para conversão ASCII ==> Hexadecimal]) verificando quem é o emitente e realizando a operação aritmética solicita. Monte uma resposta e utilize o comando '''ping''' para responder ao emitente.
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratório 2 - Desvendando o HTTP com Wireshark}}
| |
| − |
| |
| − | Fonte base: [http://www.ebah.com.br/content/ABAAABZ6QAD/wireshark-http Wireshark - HTTP]
| |
| − |
| |
| − | ===Objetivos===
| |
| − | *Baseado na pequena introdução ao Wireshark apresentada no '''Laboratório 1''', agora estamos prontos para utilizar o Wireshark para investigar protocolos em operação.
| |
| − | *Explorar vários aspectos do protocolo HTTP:
| |
| − | *#a interação básica GET/resposta do HTTP,
| |
| − | *#formatos de mensagens HTTP,
| |
| − | *#baixando arquivos grandes em HTML,
| |
| − | *#baixando arquivos em HTML com objetos incluídos, e
| |
| − | *#segurança HTTP.
| |
| − |
| |
| − | ===A Interação Básica GET/Resposta do HTTP===
| |
| − |
| |
| − | Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
| |
| − | #inicie o navegador;
| |
| − | #limpe o cache do mesmo (teclas de atalho para o Firefox: '''Ctrl + Shift + Del''');
| |
| − | #inicie o Wireshark, como descrito no '''Laboratório 1''';
| |
| − | #inicie a captura de pacotes;
| |
| − | #digite o seguinte URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html;
| |
| − | #pare a captura de pacotes;
| |
| − | #digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados).
| |
| − |
| |
| − | [[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta HTTP]]
| |
| − |
| |
| − | O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
| |
| − | #A mensagem GET (do seu navegador para o servidor web www.sj.ifsc.edu.br) e a mensagem de resposta do servidor para o seu navegador.
| |
| − | #A janela de conteúdos de pacotes mostra detalhes da mensagem selecionada (neste caso a mensagem HTTP GET /~odilson/RED29004//RED29004.html, que está em destaque na janela de listagem de pacotes).
| |
| − | #A mensagem HTTP transportada em um segmento TCP, que é carregado em um datagrama IP, que é levado em um quadro Ethernet com 5728 bits no fio. Isso é observado de baixo para cima na janela de detalhes do cabeçalho do pacote selecionado. O Wireshark exibe informações sobre o quadro, IP, TCP e HTTP. Você deve expandir as informações, por exemplo, do HTTP clicando na seta ao lado esquerdo de “Hypertext Transfer Protocol”. Observando as informações das mensagens HTTP GET e de resposta. Você consegue inclusive enxergar a mensagem mostrada no navegador: '''RED29004! Página de teste.'''
| |
| − |
| |
| − | Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
| |
| − | #O seu navegador executa HTTP 1.0 ou 1.1?
| |
| − | #Qual a versão de HTTP do servidor?
| |
| − | #Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar?
| |
| − | #Qual o endereço IP do seu computador?
| |
| − | #E do servidor tele.sj.ifsc.edu.br?
| |
| − | #Qual o número da porta utilizada no seu computador?
| |
| − | #E do servidor tele.sj.ifsc.edu.br?
| |
| − | #Qual o código de status retornado do servidor para o seu navegador?
| |
| − | #Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
| |
| − | #Quantos bytes de conteúdo são baixados pelo seu navegador?
| |
| − | #Encontre a mensagem '''RED29004! Página de teste'''. Onde (em qual campo) encontra-se?
| |
| − | #Qual a diferença entre os endereços IP e porta de origem e destino entre a mensagem GET e a de resposta do HTTP?
| |
| − |
| |
| − | ===Interação Básica GET/Resposta do HTTP usando TELNET e REQUISIÇÃO MANUAL===
| |
| − |
| |
| − | # Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos:
| |
| − | ## Coloque o Wireshark para capturar pacotes
| |
| − | ## Abra um terminal de texto no Linux (menu ''Aplicativos->Acessórios->Terminal'').
| |
| − | ## Execute este comando: <syntaxhighlight lang=bash>
| |
| − | telnet tele.sj.ifsc.edu.br 80
| |
| − | </syntaxhighlight>
| |
| − | ## Após aparecer esta linha: <syntaxhighlight lang=text>
| |
| − | Trying 200.135.37.75...
| |
| − | Connected to integrado.sj.ifsc.edu.br.
| |
| − | Escape character is '^]'.
| |
| − | </syntaxhighlight>digite o seguinte:<syntaxhighlight lang=text>
| |
| − | GET /~odilson/RED29004//RED29004.html HTTP/1.0
| |
| − | </syntaxhighlight> e em seguida tecle ENTER duas vezes.
| |
| − | ## Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP?
| |
| − | ## Compare o resultado das execuções desses comandos com o que se viu no navegador. Qual a diferença em cada caso?
| |
| − | ##Quanto tempo levou para fechar a conexão?
| |
| − | ## Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome inexistente). Observe a resposta. Qual é o código da mensagem recebida?
| |
| − | # Refaça a conexão com o servidor:<syntaxhighlight lang=bash>
| |
| − | telnet tele.sj.ifsc.edu.br 80
| |
| − | </syntaxhighlight>
| |
| − | ## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash>
| |
| − | GET /~odilson/RED29004//RED29004.html HTTP/1.1
| |
| − | Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
| |
| − | ##Quanto tempo levou para fechar a conexão?
| |
| − | # Refaça a conexão com o servidor:<syntaxhighlight lang=bash>
| |
| − | telnet tele.sj.ifsc.edu.br 80
| |
| − | </syntaxhighlight>
| |
| − | ## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash>
| |
| − | GET /~odilson/RED29004//RED29004.html HTTP/1.1
| |
| − | Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
| |
| − | ## Faça um novo pedido na conexão já aberta:<syntaxhighlight lang=bash>
| |
| − | GET /~odilson/RED29004/RED29004_arq3.html HTTP/1.1
| |
| − | Host: tele.sj.ifsc.edu.br</syntaxhighlight><code> <Enter>/<Enter></syntaxhighlight>
| |
| − | #O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1? Descreva o processo de download dos objetos em ambos os casos.
| |
| − |
| |
| − | ===A Interação HTTP GET Condicional/Resposta===
| |
| − |
| |
| − | A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
| |
| − | #inicie o navegador web;
| |
| − | #limpe o cache do seu navegador('''Ctrl + Shift + Del''');
| |
| − | #inicie o Wireshark;
| |
| − | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004.html seu navegador deve exibir um arquivo em HTML muito simples com duas linhas;
| |
| − | #pressione o botão “refresh” no navegador (ou digite o URL novamente);
| |
| − | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP sejam apresentadas na janela de listagem de pacotes.
| |
| − |
| |
| − | Responda às seguintes questões:
| |
| − | #Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor tele.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”?
| |
| − | #Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
| |
| − | #Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha “If-Modified-Since”? Caso a resposta seja afirmativa, qual informação segue o cabeçalho “If-Modified-Since”?
| |
| − | #Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem?
| |
| − | #O servidor retornou explicitamente o conteúdo do arquivo? Explique.
| |
| − | #Qual o tamanho da primeira e segunda mensagem de retorno do servidor?
| |
| − |
| |
| − | ===Baixando Documentos Longos===
| |
| − | <span style="color: red;">Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a '''eth0''' adapte o comando, caso reiniciar a máquina repita-o:</span>
| |
| − | <code>sudo ethtool --offload eth0 gso off tso off sg off gro off </syntaxhighlight>
| |
| − |
| |
| − | Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
| |
| − | #inicie o navegador web;
| |
| − | #limpe o cache do seu navegador;
| |
| − | #inicie o Wireshark;
| |
| − | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004//RED29004_arq2.html seu navegador deve exibir um documento bastante longo e criativo :) ;
| |
| − | #Faça um atualização da página (F5);
| |
| − | #pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
| |
| − |
| |
| − | Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de '''11747 bytes''' é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark.
| |
| − |
| |
| − | Responda às seguintes questões:
| |
| − | #Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
| |
| − | #Quantos segmentos TCP foram necessários para carregar a resposta?
| |
| − | #Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET?
| |
| − | #No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
| |
| − | #O que explica a diferença entre a primeira e segunda requisições?
| |
| − |
| |
| − | ===Documentos HTML com Objetos Incluídos===
| |
| − |
| |
| − | Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
| |
| − | #inicie o navegador web;
| |
| − | #limpe o cache do seu navegador;
| |
| − | #inicie o Wireshark;
| |
| − | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br;
| |
| − | #digite o URL no navegador http://tele.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq4.html seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio do professor;
| |
| − | #pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
| |
| − |
| |
| − | Responda às seguintes questões:
| |
| − | #Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso?
| |
| − | #Para quais endereços na Internet estas mensagens foram enviadas em cada acesso?
| |
| − | #Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos.
| |
| − |
| |
| − | ===HTTPS===
| |
| − | Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
| |
| − | #inicie o navegador web;
| |
| − | #limpe o cache do seu navegador;
| |
| − | #inicie o Wireshark;
| |
| − | #digite o seguinte URL no navegador https://www.ssllabs.com/ssltest/;
| |
| − | #pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas.
| |
| − |
| |
| − | Responda:
| |
| − | #Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade?
| |
| − | #Que tipos de campos são mais presentes nesse tipo de mensagens?
| |
| − | #Você consegue identificar o conteúdo de alguma nas mensagens ssl, como no caso das mensagens http?
| |
| − |
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratório 3 - Serviço de Nomes (DNS)}}
| |
| − |
| |
| − | ===Objetivos===
| |
| − | O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
| |
| − | #o lado cliente do DNS,
| |
| − | #uma pequena análise do protocolo e
| |
| − | #consultas AAAA
| |
| − |
| |
| − | Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor.
| |
| − |
| |
| − | ===Consulta simples ao DNS gerada a partir de um comando ping===
| |
| − |
| |
| − | O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS.
| |
| − |
| |
| − | #Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:<br />
| |
| − | #: nm-tool | tail -n 8 <br />
| |
| − | #: cat /etc/resolv.conf
| |
| − | #Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo.
| |
| − | #Execute o ping para um endereço de host conhecido
| |
| − | #: ping www.ifsc.edu.br
| |
| − | #Pare a captura e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP
| |
| − | #: dns || icmp
| |
| − | #Observe os pacotes capturados. Em particular foque no pacote de pergunta que deve ser similar ao mostrado abaixo e deve estar direcionado a um dos servidores DNS. Nos flags do header do pacote DNS é possível observar que é um QUERY (pergunta) a ser resolvido de forma recursiva. A pergunta propriamente dita está no campo QUERIES, onde é colocado o nome a ser resolvido e o tipo do registro solicitado (tipo A) que indica resolução de nome).
| |
| − | #:
| |
| − | #:[[Arquivo:DNS-Tela1-Wireshark.jpg | 900px| Estrutura de uma pergunta simples DNS]]
| |
| − | #:
| |
| − | #:
| |
| − | #Foque agora um pacote de resposta do servidor para o cliente. Deve ter uma estrutura similar ao mostrado abaixo. Nos flags do header do pacote DNS é possível observar que é uma resposta. A resposta propriamente dita está no campo ANSWERS (ele também repete a pergunta no campo QUERIES). Note que podem haver vários registros (RR) retornados, cada um com um tipo. No exemplo abaixo também é retornada uma lista de servidores autorizados (RR tipo NS). Também é retornado o endereço IP destes servidores através de RRs adicionais do tipo A (inclusive endereços IPv6).
| |
| − | #:
| |
| − | #:
| |
| − | #:[[Arquivo:DNS-Tela2-Wireshark.jpg | 900px| Estrutura de uma resposta simples DNS]]
| |
| − | #Perguntas a serem respondidas, baseado nos pacotes "''Standard query''" e "''Standard query responde''":
| |
| − | ##Quem são os servidores DNS da sua máquina?
| |
| − | ##O ping gerou uma pergunta para cada um deles?
| |
| − | ##Qual o tipo da RR (Registro) associada a pergunta (''Queries''). O que significa?
| |
| − | ##Qual endereço IP retornado para o www.ifsc.edu.br?
| |
| − | ##Qual endereço IP usado no ping (ver pacote REQUEST ICMP)?
| |
| − | ##No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor)
| |
| − | ##Quais os endereços IPv4 dos servidores autorizados repassados?
| |
| − | #Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo '''PTR'''. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, onde se fornece um IP e o servidor devolve o nome da máquina.
| |
| − | #Perguntas a serem respondidas:
| |
| − | ##Qual o IP que se pretende resolver?
| |
| − | ##Qual o nome retornado?
| |
| − |
| |
| − | ===Consultas DNS por meio de ferramentas especializadas===
| |
| − | # Usando o programa [http://manpages.ubuntu.com/manpages/precise/man5/hosts.5.html host], [http://manpages.ubuntu.com/manpages/trusty/en/man1/nslookup.1.html Nslookup] ou [http://manpages.ubuntu.com/manpages/precise/man1/dig.1.html dig], que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas):
| |
| − | #* mail.ifsc.edu.br
| |
| − | #* www.google.com
| |
| − | #* www.gmail.com
| |
| − | # Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa ''host'' ou ''dig'' isso pode ser feito assim: <syntaxhighlight lang=bash>
| |
| − | host -t ns ifsc.edu.br
| |
| − | dig -t ns ifsc.edu.br
| |
| − | </syntaxhighlight>
| |
| − | # Descubra e anote no relatório: qual o servidor DNS usado pelo seu computador? Num terminal digite: <syntaxhighlight lang=bash>
| |
| − | cat /etc/resolv.conf
| |
| − | caso a resposta seja "nameserver 127.0.1.1" (endereço de loopback), provavelmente o sistema gráfico está controlando sua interface, nesse caso execute:
| |
| − | nm-tool | tail -n 8
| |
| − | </syntaxhighlight>
| |
| − | # O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio e/ou máquina. Por exemplo, como ele pode-se descobrir que ''host'' recebe emails em um determinado domínio. Isso é utilizado pelos MTA (''Mail Transfer Agent'') mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX (''Mail eXchange'') de um domínio. Novamente as ferramentas a ser utilizada nesse caso podem ser ''host'' ou ''dig''. Por exemplo: <syntaxhighlight lang=bash>
| |
| − | host -t mx ifsc.edu.br
| |
| − | dig -t mx ifsc.edu.br
| |
| − | </syntaxhighlight>Descubra e anote no relatório quem é o servidor de emails nos seguintes domínios:
| |
| − | #* gmail.com
| |
| − | #* hotmail.com
| |
| − | #* ifsc.edu.br
| |
| − | # Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: <syntaxhighlight lang=bash>
| |
| − | dig -x 200.135.37.65
| |
| − | </syntaxhighlight> ... o ''dig'' tem um resultado um pouco mais carregado que os outros utilitários (''host'' e ''nslookup''), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha '';; ANSWER SECTION:''. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Pode-se também usar a variante do ''dig'' para respostas curtas: <code>
| |
| − | dig -x 200.135.37.65 +short
| |
| − | </syntaxhighlight>
| |
| − | #Faça uma consulta recursiva com dig e responda:<syntaxhighlight lang=bash>
| |
| − | dig +trace mail.ru. </syntaxhighlight>
| |
| − | ##Qual foi o RLD (''Root Level Domain'') consultado?
| |
| − | ##Qual o TLD (''Top Level Domain'') consultado?
| |
| − | ##Qual o SLD (''Second Level Domain'') consultado?
| |
| − | ##Como você sabe que foram esses os LDs consultados?
| |
| − | # Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o ''Root Level Domain'', o ''Top Level Domain'' e o ''Second Level Domain''. Anote no relatório.
| |
| − | ## Descubra quem são os servidores raiz (topo de hierarquia DNS): <syntaxhighlight lang=bash>
| |
| − | host -t ns .
| |
| − | dig -t ns .
| |
| − | </syntaxhighlight>
| |
| − | ## Escolha um dos servidores RLD listados, e use-o para fazer as consultas. Por exemplo: <syntaxhighlight lang=bash>
| |
| − | host -v -t a www.sj.ifsc.edu.br. j.root-servers.net.
| |
| − | </syntaxhighlight>... e observe a seção '';; AUTHORITY SECTION:''. Ele contém a listagem de servidores DNS que podem atender sua consulta.
| |
| − | ## Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: <code>
| |
| − | host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight>
| |
| − | ## Quantos servidores DNS foram necessários consultar no total?
| |
| − | #Consultando um servidor explícito(@)<syntaxhighlight lang=bash>
| |
| − | dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. </syntaxhighlight>
| |
| − | ##Explique a diferença na consulta realizada por esse comando para o comando ''dig +trace www.sj.ifsc.edu.br''. Em algum caso a consulta poderia ser exatamente a mesma? Qual?
| |
| − |
| |
| − | ===Algumas consultas AAAA===
| |
| − | Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6.
| |
| − | #No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo: <code>
| |
| − | dig AAAA google.com
| |
| − | host -t AAAA google.com </syntaxhighlight>
| |
| − | ##webmail.ufsc.br
| |
| − | ##www.sj.ifsc.edu.br
| |
| − | ##www.nyt.com
| |
| − | ##ipv6.br
| |
| − | ##www.microsoft.com
| |
| − | #Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <code>
| |
| − | dig -x 2001:12ff::10
| |
| − | dig -x 2001:12ff::10 +short
| |
| − | host 2001:12ff::10 </syntaxhighlight>
| |
| − | ##2801:84:0:2::10
| |
| − | ##2001:12d0:0:126::183:244
| |
| − | ##2001:12ff::10
| |
| − | ##2804:1454:1004:100::2
| |
| − |
| |
| − | ===Analisando o protocolo via Wireshark===
| |
| − | Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS.
| |
| − | #abra o navegador web e limpe o cache do mesmo;
| |
| − | #abra o Wireshark e escolha a interface e inicie a captura de pacotes;
| |
| − | #inicie a captura de pacotes no Wireshark;
| |
| − | #no terminal digite '''dig +trace canon.jp''' (isso vai provocar a consulta DNS);
| |
| − | #pare a captura de pacotes;
| |
| − | #No Wireshark digite “dns” no filtro (sem as aspas);
| |
| − | Com base nisso identifique o seguinte:
| |
| − | #quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta?
| |
| − | #que protocolo de transporte é usado?
| |
| − | #que portas de origem e destino são utilizadas?
| |
| − | #qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP?
| |
| − | #qual o tipo de registro DNS acessado em cada consulta?
| |
| − | #que informações estão contidas nas respostas DNS? Há algo além do que foi pedido?
| |
| − | #qual o tamanho das mensagens DNS?
| |
| − | #qual endereço IP a mensagem de consulta DNS é enviada? Foi o mesmo ip obtido na seção anterior: seu servidor DNS?
| |
| − | #examine a mensagem de consulta DNS. Qual o campo “type” desta mensagem?
| |
| − | #a mensagem de consulta contém algum campo “answer”?
| |
| − | #examine a mensagem de resposta DNS. Quantos campos com “answer” existem?
| |
| − | #quais são os benefícios de usar o UDP ao invés do TCP como protocolo de transporte para o DNS?
| |
| − |
| |
| − | ===Exemplos de arquivos de um ''Second Level Domain'' fictício===
| |
| − | *Exemplo de arquivos de configuração de um servidor [https://www.isc.org/downloads/bind/ BIND]
| |
| − | /etc/bind/db.redes <code>
| |
| − | $TTL 86400
| |
| − | @ IN SOA ns.redes.edu.br. root (
| |
| − | 2016090900 ; Serial
| |
| − | 604800 ; Refresh
| |
| − | 86400 ; Retry
| |
| − | 2419200 ; Expire
| |
| − | 86400 ) ; Negative Cache TTL
| |
| − | ;
| |
| − | @ IN NS ns.redes.edu.br.
| |
| − | @ IN MX 10 mail.redes.edu.br.
| |
| − | $ORIGIN redes.edu.br.
| |
| − | ns A 192.168.1.101
| |
| − | www A 192.168.1.102
| |
| − | www A 192.168.1.103
| |
| − | www A 192.168.1.104
| |
| − | www A 192.168.1.105
| |
| − | www A 192.168.1.106
| |
| − | www A 192.168.1.107
| |
| − | ftp A 192.168.1.108
| |
| − | mail A 192.168.1.109 </syntaxhighlight>
| |
| − |
| |
| − | /etc/bind/db.2.168.192 (Zona reversa) <code>
| |
| − | $TTL 86400
| |
| − | @ IN SOA ns.redes.edu.br. root (
| |
| − | 2016090900 ; Serial
| |
| − | 604800 ; Refresh
| |
| − | 86400 ; Retry
| |
| − | 2419200 ; Expire
| |
| − | 86400 ) ; Negative Cache TTL
| |
| − | ;
| |
| − | IN NS ns.redes.edu.br.
| |
| − | 101 IN PTR ns.redes.edu.br.
| |
| − | 102 IN PTR www.redes.edu.br.
| |
| − | 108 IN PTR ftp.redes.edu.br.
| |
| − | 109 IN PTR mail.redes.edu.br. </syntaxhighlight>
| |
| − | {{Collapse bottom}}
| |
| − | {{Collapse top |Laboratório 4 - Entendendo ''sockets'', UDP e TCP}}
| |
| − |
| |
| − | ===Objetivos===
| |
| − | Entender o conceito de ''sockets'' relacionados aos protocolos UDP e TCP.
| |
| − |
| |
| − | Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para ''sockets''. Um processo é semelhante a uma casa e o ''socket'' do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior.
| |
| − |
| |
| − | Simultaneamente explora-se os conceitos relativos aos protocolos UDP e TCP, observando-se a quantidade de mensagens necessárias para a troca de uma simples frase textual. Observa-se a "agilidade" do UDP e a robustez do TCP.
| |
| − |
| |
| − | ===Descrição da aplicação a ser desenvolvida em UDP e TCP===
| |
| − |
| |
| − | *Usaremos a aplicação cliente-servidor simples a seguir para demonstrar a programação de ''socket'':
| |
| − | #Um cliente lê uma linha de caracteres (dados) do teclado e a envia para o servidor.
| |
| − | #O servidor recebe os dados e converte os caracteres para maiúsculas.
| |
| − | #O servidor envia os dados modificados ao cliente.
| |
| − | #O cliente recebe os dados modificados e apresenta a linha em sua tela.
| |
| − |
| |
| − | ===Programação de ''sockets'' com UDP===
| |
| − |
| |
| − | A aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de ''sockets''. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de ''sockets'' utilizando a API Posix encontra-se [[RED29004-2014-1#03.2F04.2F14:_Camada_de_Aplica.C3.A7.C3.A3o:_programando_sockets_TCP | aqui]].
| |
| − |
| |
| − | [[imagem:Programacao_socket_UDP.png|500px]]
| |
| − |
| |
| − | Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens via ''sockets'', que abstrai qualquer necessidade de conhecimento das camadas subjacentes.
| |
| − |
| |
| − | =====Roteiro=====
| |
| − | #Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.
| |
| − | #Escreva o programa UDPServer.py <code>
| |
| − | #Esta linha define que pode-se utilizar sockets dentro do programa
| |
| − | from socket import *
| |
| − | #Define explicitamente a porta aberta servidor
| |
| − | serverPort = 22222
| |
| − | #Cria o socket do servidor, denominado serverSocket. O primeiro parametro indica a familia do endereco,
| |
| − | #em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que
| |
| − | #o socket eh do tipo SOCK_DGRAM, ou seja, eh um socket UDP.
| |
| − | serverSocket = socket(AF_INET, SOCK_DGRAM)
| |
| − | #Vincula o numero da porta, nesse caso 22222, ao socket do servidor e "abre a porta".
| |
| − | serverSocket.bind(('', serverPort))
| |
| − | print "O servidor esta pronto para recepcao"
| |
| − | #Aguarda indefinidamente por contatos (mensagens) de clientes
| |
| − | while 1:
| |
| − |
| |
| − | message, clientAddress = serverSocket.recvfrom(2048)
| |
| − | print message
| |
| − | #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas.
| |
| − | modifiedMessage = message.upper()
| |
| − | serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight>
| |
| − | #No terminal da máquina execute o programa: <code>
| |
| − | python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal.
| |
| − | #Abra um '''novo terminal''' e escreva o programa cliente. UDPClient.py. Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho. <code>
| |
| − | #Esta linha define que pode-se utilizar sockets dentro do programa
| |
| − | from socket import *
| |
| − | #Define o endereco ip do servidor ao qual o cliente contactara.
| |
| − | #Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho.
| |
| − | serverName = 'ip_do_servidor'
| |
| − | #Define a porta de acesso ao servidor
| |
| − | serverPort = 22222
| |
| − | #Cria o socket do cliente, denominado clientSocket. O primeiro parametro indica a familia do endereco,
| |
| − | #em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que
| |
| − | #o socket eh do tipo SOCK_DGRAM, o que significa que eh um socket UDP.
| |
| − | clientSocket = socket(AF_INET, SOCK_DGRAM)
| |
| − | #raw_input eh uma funcao interna da linguagem Python que permite a solicitacao de entrada de dados que
| |
| − | #sera armazenada em message.
| |
| − | message = raw_input('Entre com a sentanca em minuculas: ')
| |
| − | #O metodo sendto() acrescenta o endereco (e porta) de destino a mensagem e envia o pacote resultante
| |
| − | #pelo socket aberto.
| |
| − | clientSocket.sendto(message,(serverName, serverPort))
| |
| − | #Apos o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variavel
| |
| − | #modifiedMessage e o endereco de origem eh armazenado em serverAddress. 2048 representa o tamanho do buffer.
| |
| − | modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
| |
| − | #Imprime a mensagem recebida na tela.
| |
| − | print modifiedMessage
| |
| − | #Fecha o socket.
| |
| − | clientSocket.close() </syntaxhighlight>
| |
| − | #No terminal da máquina execute o programa: <code>
| |
| − | python UDPClient.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
| |
| − | #O cliente pode também ser substituído pelo comando de terminal: <code> netcat -u ip_do_servidor 22222</syntaxhighlight>
| |
| − | #Rode o WireShark. Configure a captura na interface '''''any''''', com o filtro: '''udp.port == 22222'''.
| |
| − | #Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
| |
| − | #Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando o cliente.
| |
| − | PERGUNTAS baseadas na captura:
| |
| − | #Em algum momento foi identificado algum procedimento para estabelecimento de conexão?
| |
| − | #Em algum campo do UDP existe numeração de mensagens?
| |
| − | #Qual o número identificador de protocolo UDP no pacote IP?
| |
| − | #Qual é o ''checksum'' no pacote (datagrama) UDP?
| |
| − | #É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
| |
| − | #Se a mensagem digitada for '''teste''', do cliente para o servidor deve aparacer o campo '''Data:7465737465''' e a resposta do servidor deve aparecer '''Data: 5445535445'''. O que significa isso? Dica, olhe na internet o código ASCII.
| |
| − | #Qual foi a sequência numérica do campo Data em seu teste? Qual o significado?
| |
| − | #Qual é o protocolo da camada de transporte nessa troca de mensagens?
| |
| − | #Qual são os dois números de porta e os dois IPs utilizados?
| |
| − | #Quem definiu o número de porta do cliente?
| |
| − | #Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
| |
| − | #Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
| |
| − | #Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais? Explique.
| |
| − |
| |
| − | ===Programação de ''sockets'' com TCP===
| |
| − |
| |
| − | Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, primeiramente eles devem se apresentar, o primeiro ''socket'' da Figura abaixo, e estabelecer uma conexão TCP, o segundo ''socket'' da Figura abaixo. Todos os dados trafegarão pelo segundo ''socket''.
| |
| − |
| |
| − | O processo TCPServer tem dois sockets:
| |
| − |
| |
| − | [[imagem:Programacao_socket_TCP_1.png|400px]]
| |
| − |
| |
| − | A aplicação cliente-servidor usando TCP:
| |
| − |
| |
| − | [[imagem:Programacao_socket_TCP_2.png|500px]]
| |
| − |
| |
| − | =====Roteiro=====
| |
| − | #Escreva o código do programa servidor. TCPServer.py <code>
| |
| − | from socket import *
| |
| − | serverPort = 33333
| |
| − | serverSocket = socket(AF_INET, SOCK_STREAM)
| |
| − | serverSocket.bind(('',serverPort))
| |
| − | #Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1
| |
| − | serverSocket.listen(1)
| |
| − | print 'O servidor esta pronto'
| |
| − | while 1:
| |
| − | #Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket,
| |
| − | #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente
| |
| − | #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP
| |
| − | #entre o clientSocket do cliente e o connectionSocket do servidor.
| |
| − | connectionSocket, addr = serverSocket.accept()
| |
| − | message = connectionSocket.recv(1024)
| |
| − | print message
| |
| − | messageMaiuscula = message.upper()
| |
| − | connectionSocket.send(messageMaiuscula)
| |
| − | connectionSocket.close() </syntaxhighlight>
| |
| − | #No terminal da máquina execute o programa: <code>
| |
| − | python TCPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
| |
| − | #Pode-se testar se a porta está aberta: <code>
| |
| − | nmap -p33333 ip_do_servidor </syntaxhighlight>
| |
| − | #Qual o estado dessa porta? Cite e justifique o tipo de serviço.
| |
| − | #Abra um '''novo terminal''' e escreva o programa cliente. TCPClient.py <code>
| |
| − | from socket import *
| |
| − | serverName = 'ip_do_servidor'
| |
| − | serverPort = 33333
| |
| − | #SOCK_STREAM habilita uso do TCP
| |
| − | clientSocket = socket(AF_INET, SOCK_STREAM)
| |
| − | #Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam
| |
| − | #informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito
| |
| − | clientSocket.connect((serverName,serverPort))
| |
| − | message = raw_input('Entre com a sentanca em minuculas: ')
| |
| − | #Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket
| |
| − | #eh uma "tubulacao" direta entre ambos, basta empurrar dados
| |
| − | clientSocket.send(message)
| |
| − | modifiedMessage = clientSocket.recv(1024)
| |
| − | print 'Mensagem do servidor: ', modifiedMessage
| |
| − | clientSocket.close() </syntaxhighlight>
| |
| − | #Rode o WireShark. Configure a captura na interface '''''any''''', use o filtro do tipo: '''tcp.port==33333'''.
| |
| − | #Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
| |
| − | #Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando o cliente.
| |
| − | Perguntas
| |
| − | #As três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam?
| |
| − | #Em qual mensagem (número) é que a frase é enviada ao servidor?
| |
| − | #A mensagem seguinte (quinta) apresenta camada de aplicação? Clique na camada TCP no Wireshark e observe o campo '''Flags: 0x010 (ACK)'''. O que você acha que isso significa?
| |
| − | #Qual o conteúdo da mensagem seguinte (sexta)? E da sétima? Explique.
| |
| − | #Explique as três últimas mensagens. Dica: olhe as figuras 3.39 e 3.40 do Kurose versão 6.
| |
| − | #Qual é o protocolo da camada de transporte nessa troca de mensagens?
| |
| − | #Qual são os números de porta e os IPs utilizados?
| |
| − | #Quem definiu o número de porta do cliente?
| |
| − | #Quais foram os números de sequência utilizados em todas as mensagens?
| |
| − | #Qual o número identificador de protocolo TCP no pacote IP?
| |
| − | #Quantos ''socktes'' foram abertos no servidor com um cliente "conectado"? E com dois clientes?
| |
| − | #Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
| |
| − | #Capture todos os pacotes trocados, entre você e seu vizinho. Os números de portas e IPs são ou não iguais?
| |
| − | Comparativo.
| |
| − | #Quantas mensagens foram trocadas entre o servidor e cliente em cada um dos protocolos, UDP e TCP, para atingir o mesmo objetivo?
| |
| − | #Discuta outras diferenças observadas entre os protocolos UDP e TCP.
| |
| − |
| |
| − | ===Desafios para casa===
| |
| − |
| |
| − | #Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente.
| |
| − | #Faça a "Tarefa 1: Servidor Web" do livro do Kurose, página 131, 6a ed.
| |
| − |
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratório 5 - TCP x UDP}}
| |
| − |
| |
| − | ===Objetivos===
| |
| − | O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.
| |
| − |
| |
| − | Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser realizada baseada no tipo de comunicação a ser feita pela aplicação.
| |
| − |
| |
| − | ==== Experimento 1 ====
| |
| − | <span style="color: red;">Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria. Caso sua interface de rede não seja a '''eth0''' adapte o comando, caso reiniciar a máquina repita-o:</span>
| |
| − | <code>sudo ethtool --offload eth0 gso off tso off sg off gro off </syntaxhighlight>
| |
| − |
| |
| − | O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?
| |
| − |
| |
| − | # Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento: <syntaxhighlight lang=bash>
| |
| − | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/jogo.exe
| |
| − | </syntaxhighlight>
| |
| − | # Observe o tamanho do arquivo transferido ... ele deve ter exatamente 332831416 bytes (cerca de 318 MB). Você pode fazer isso com o comando '''ls -l jogo.exe''', ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo.
| |
| − | # Escolha um colega para fazer o experimento em que o arquivo será transferido de um computador para o outro. NÃO pode ser na própria máquina. Um será o '''receptor''' e outro o '''transmissor'''.
| |
| − | # A primeira transferência será feita usando o protocolo TCP da seguinte forma:
| |
| − | #* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo. Como o o comportamento padrão do wireshark é redefinir o número de sequência para sempre iniciar em um e isso pode atrapalhar nossos experimentos, vamos desabilitar essa funcionalidade: <code>
| |
| − | Edit >> Preferences >> Protocols >> TCP >> Desabilite Relative sequence numbers </syntaxhighlight>
| |
| − | #* No computador '''receptor''' execute o '''netcat''' ('''nc''') (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em '''arquivo''': <syntaxhighlight lang=bash>
| |
| − | nc -vvnl 5555 > arquivoTCP
| |
| − | </syntaxhighlight>
| |
| − | #* No computador '''transmissor''' execute, após o processo do '''receptor''' estar executando: <syntaxhighlight lang=bash>
| |
| − | time nc -vvn ip_do_receptor 5555 < jogo.exe
| |
| − | </syntaxhighlight>
| |
| − | #* Quando completar a transferência, pare o Wireshark.
| |
| − | #* Verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
| |
| − | #* Analisando a captura de pacotes do WireShark responda:
| |
| − | ## Quais as portas origem e destino escolhidas pelo cliente e servidor?
| |
| − | ## Qual é o identificador do primeiro e do último pacote?
| |
| − | ## Qual é o identificador do primeiro e do último ACK?
| |
| − | ## Qual o Tamanho Máximo de Segmento (MSS) escolhidos pelo cliente e servidor na conexão.
| |
| − | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor.
| |
| − | ## Qual é o tamanho do último segmento de dados recebido?
| |
| − | ## Todos os segmentos trocados entre as máquinas contém dados ou alguns são somente de controle? Qual o percentual aproximado de segmentos de controle?
| |
| − | ## Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
| |
| − | ## Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada em sala de aula?
| |
| − | # A segunda transferência será feita usando o protocolo UDP:
| |
| − | #* Execute o WireShark e deixe-o capturando pacotes '''somente''' durante a transferência do arquivo.
| |
| − | #* No computador '''receptor''' baixe o programa '''receptor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash>
| |
| − | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor
| |
| − | chmod +x receptor
| |
| − | ./receptor 5555 > arquivoUDP
| |
| − | </syntaxhighlight>
| |
| − | #* No computador '''transmissor''' baixe o programa '''transmissor''', acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo: <syntaxhighlight lang=bash>
| |
| − | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor
| |
| − | chmod +x transmissor </syntaxhighlight>
| |
| − | #* Inicie a transferência do arquivo: <code>
| |
| − | ./transmissor ip_do_receptor 5555 < jogo.exe
| |
| − | </syntaxhighlight>
| |
| − | #* Quando completar a transferência (vai aparecer a mensagem no '''transmissor''' "Levou XXXXX segundos para transmitir XXXXX bytes), no '''receptor''' digite <CTRL + C>, verifique o tamanho do arquivo recebido.
| |
| − | #* Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
| |
| − | #* Analisando a captura de pacotes do WireShark responda:
| |
| − | ## Qual é o identificar do primeiro e do último pacote? Existe?
| |
| − | ## É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
| |
| − | ## Há segmentos de controle ou somente segmentos de dados?
| |
| − | ## Qual é o tamanho do último segmento de dados recebido?
| |
| − | # Compare as transferências feitas com os protocolos TCP e UDP.
| |
| − | ## O que eles têm em comum?
| |
| − | ## Que diferenças lhe pareceram mais pronunciadas?
| |
| − | ## Como isso deve afetar as aplicações que usam esses protocolos?
| |
| − |
| |
| − | ==== Experimento 2 ====
| |
| − | *Tem como objetivo gerar um gráfico para facilitar a visualização do '''controle de congestionamento''' e a consequente equidade do protocolo TCP.
| |
| − | *Utilizar o software [https://iperf.fr/ Iperf] (iperf –h para help) para gerar tráfego entre duas máquinas, '''cliente''' e '''servidor'''.
| |
| − | *Utilizar o software [[netkit2]].
| |
| − | *O roteiro será executado sobre máquinas virtuais, através do uso do [[Netkit2 | Netkit2]].
| |
| − | *Para realização dos ensaios será montada a rede virtual apresentada na Figura 1.
| |
| − |
| |
| − | [[Arquivo:TCP_Rede_Controle_de_Fluxo.png |thumb | 200px| Figura 1 - Rede ara testes]]
| |
| − |
| |
| − | #Copie o texto abaixo e crie um arquivo, salve-o como /home/aluno/TCP.conf.
| |
| − | <code>
| |
| − | # Definição das máquinas
| |
| − | R1[type]=router
| |
| − | PC1[type]=generic
| |
| − | PC2[type]=generic
| |
| − | PC3[type]=generic
| |
| − |
| |
| − | # Definição dos roteadores padrão
| |
| − | PC1[default_gateway]=10.0.0.254
| |
| − | PC2[default_gateway]=10.0.1.254
| |
| − | PC3[default_gateway]=10.0.1.254
| |
| − |
| |
| − | # Definição das interfaces do roteador
| |
| − | R1[eth0]=lan0:ip=10.0.0.254/24:rate=10000
| |
| − | R1[eth1]=lan1:ip=10.0.1.254/24:rate=10000
| |
| − |
| |
| − | # Definição das interfaces dos PCs
| |
| − | PC1[eth0]=lan0:ip=10.0.0.1/24:rate=10000
| |
| − | PC2[eth0]=lan1:ip=10.0.1.2/24:rate=10000
| |
| − | PC3[eth0]=lan1:ip=10.0.1.3/24:rate=10000
| |
| − | </syntaxhighlight>
| |
| − | #Abra o NetKit2.
| |
| − | #Abra o arquivo de configuração: <code>
| |
| − | File > Load and Run </syntaxhighlight>
| |
| − | #*Perceba que abrirá uma janela com quatro abas inferiores, representando um roteador e três máquina virtuais criadas pelo Netkit, denominadas: R1, PC1, PC2 e PC3. Cada uma dessas abas é o terminal de configuração do respectivo equipamento.
| |
| − | #*Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
| |
| − | #Execute no PC3 o tcpdump para salvar a troca de dados entre o PC1 e o PC2 num arquivo: <code>
| |
| − | tcpdump -i eth0 -w /hostlab/shared/pc3.cap </syntaxhighlight>
| |
| − | #*Copie o texto acima e, no Netkit, selecione o R1 e clique sobre a "rodinha" do mouse que o texto será colado.
| |
| − | #No PC1 (servidor) execute: <code>
| |
| − | iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 & </syntaxhighlight>
| |
| − | #No PC2 (cliente) execute: <code>
| |
| − | iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & (sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & (sleep 30; iperf -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) & </syntaxhighlight>
| |
| − | #Fique monitorando o PC2 até a tela parar de ser atualizada, aproximadamente 90 s. Pare os processos nos três PCs utilizando CTRL-C.
| |
| − | #Abra o Wireshark.
| |
| − | #Abra o arquivo <code>
| |
| − | File > Open > /home/aluno/lab/shared/pc3.cap </syntaxhighlight>
| |
| − | #No wireshark acesse '''Statistics''' >> '''IO Graph''' e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 2.
| |
| − | #*Perceba que todos os botões '''Graph 1...4''' devem ser clicados, e os filtros aplicados (tcp.port==2000; tcp.port==2001; tcp.port==2002) isso fará com que o Wireshark mostre as respectivas curvas.
| |
| − |
| |
| − | [[Arquivo:TCP_Wireshark.png |thumb | 400px| Figura 2 - Captura de 3 fluxos de dados]]
| |
| − |
| |
| − | Responda:
| |
| − | #Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
| |
| − | #Explique os filtros aplicados no gráfico do Wireshark.
| |
| − | ##Quais são os 4 gráficos apresentados?
| |
| − | ##Há uma relação de valor entre as curvas?
| |
| − | ##Qual é esta relação?
| |
| − | #Por que a curva vermelha se sobrepõe a curva preta nos primeiros 20 segundos? Considere o início do tempo onde há início de tráfego!
| |
| − | #Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 20 e 30 segundos?
| |
| − | #Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 20 e 40 segundos.
| |
| − | #Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 20 e 30 segundos?
| |
| − |
| |
| − | =====Incluindo UDP=====
| |
| − | Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados.
| |
| − | #No PC3 execute: <code>
| |
| − | tcpdump -i eth0 -w /hostlab/shared/pc3.cap </syntaxhighlight>
| |
| − | #No PC1 execute: <code>
| |
| − | iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -u -p 2002 & </syntaxhighlight>
| |
| − | #No PC2 execute: <code>
| |
| − | iperf -c 10.0.0.1 -f m -i 1 -t 90 -p 2000 -l 1300 & (sleep 20; iperf -c 10.0.0.1 -f m -i 1 -t 70 -p 2001 -l 1300) & (sleep 30; iperf -u -c 10.0.0.1 -f m -i 1 -t 60 -p 2002 -l 1300) & </syntaxhighlight>
| |
| − | #Fique monitorando o PC2 a tela parar de ser atualizada, aproximadamente 90 s. Pare os processos nos três PCs utilizando CTRL-C.
| |
| − | #Baseado na Figura 2, no '''Graph 4''' altere o filtro para '''udp.port==2002'''. Salve o gráfico gerado.
| |
| − | #Responda as mesmas questões do item anterior, '''todas'''.
| |
| − | #Compare o comportamento dos vários fluxos de dados com e sem o UDP.
| |
| − |
| |
| − | ==== Experimento 3 (opcional) ====
| |
| − |
| |
| − | Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste terceiro experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório.
| |
| − |
| |
| − | # Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando, '''só tecle <Enter> quando o professor determinar''': <syntaxhighlight lang=bash>
| |
| − | wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso
| |
| − | </syntaxhighlight>
| |
| − | # Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta? Quanto tempo levou para o arquivo ser transferido?
| |
| − | # Após todos terem copiado o arquivo, o professor irá repetir a transferência, porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou?
| |
| − | # O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos?
| |
| − | # Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos:
| |
| − | ## Abra dois terminais. No '''terminal 1''' execute este comando: <syntaxhighlight lang=bash>
| |
| − | watch -n 1 ls -l arquivo
| |
| − | </syntaxhighlight> ... e no '''terminal 2''': <syntaxhighlight lang=bash>
| |
| − | ./receptor 5555 > arquivo
| |
| − | </syntaxhighlight>
| |
| − | ## Fique observando o '''terminal 1'''.
| |
| − | ## O professor irá transmitir o arquivo, um processo para cada aluno.
| |
| − | ##*konsole
| |
| − | ##*abrir várias abas
| |
| − | ##*n vezes ./transmissor ip_do_receptor 5555 < jogo.exe
| |
| − | ## No '''terminal 1''' observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos até o tamanho do arquivo parar de crescer (relógio, celular ou relógio do computador).
| |
| − | ## Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? O tamanho do arquivo recebido é o mesmo do arquivo original?
| |
| − | ## Faça um comparativo das transferências usando TCP e UDP.
| |
| − |
| |
| − | ==== Tarefa extra (pode ser em casa)====
| |
| − |
| |
| − | Use o aplicativo '''NetCat''' (nc) para fazer transferências UDP e responda (utilize o '''man''' para os comandos, boa parte da respostas estão lá):
| |
| − | #Qual o procedimento no lado transmissor e receptor?
| |
| − | #Consegue-se medir o tempo de maneira automática? Por que sim ou por que não?
| |
| − | #Por que os processos não param ao final da transferência como no '''experimento 1'''?
| |
| − |
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratórios 6 e 7 - Protocolos de roteamento}}
| |
| − |
| |
| − | ===Objetivos===
| |
| − | *Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet a partir de uma estrutura física formada por roteadores e redes locais:
| |
| − | **tabelas estáticas de roteamento
| |
| − | **os protocolo RIP e OSPF.
| |
| − |
| |
| − | Para atingir tais objetivos utilizaremos o [[netkit2]]. Leia o [http://wiki.sj.ifsc.edu.br/index.php/Netkit2#Roteadores tutorial] de como o '''netkit2''' trabalha com roteadores.
| |
| − |
| |
| − | Em todos os experimentos será utilizado como base a seguinte arquitetura de rede:
| |
| − |
| |
| − | [[Arquivo:DynamicRoutingTriangle.png]]
| |
| − |
| |
| − | ==Experimento 1: tabelas estáticas de roteamento==
| |
| − |
| |
| − | #Crie em seu computador um arquivo com nome '''/home/aluno/exp1.conf''', com o seguinte conteúdo: <code> # Hosts definitions
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − |
| |
| − | # Routers definitions
| |
| − | r1[type]=gateway
| |
| − | r2[type]=gateway
| |
| − | r3[type]=gateway
| |
| − |
| |
| − | # Hosts' interfaces to local routers
| |
| − | pc1[eth0]=link0:ip=192.168.0.1/24
| |
| − | pc2[eth0]=link1:ip=192.168.1.1/24
| |
| − | pc3[eth0]=link2:ip=192.168.2.1/24
| |
| − |
| |
| − | # Routers' interfaces to local networks
| |
| − | r1[eth0]=link0:ip=192.168.0.254/24
| |
| − | r2[eth0]=link1:ip=192.168.1.254/24
| |
| − | r3[eth0]=link2:ip=192.168.2.254/24
| |
| − |
| |
| − | # Network "backbone" links
| |
| − | r1[eth1]=backbone0:ip=10.0.0.1/30
| |
| − | r1[eth2]=backbone1:ip=10.0.1.1/30
| |
| − |
| |
| − | r2[eth1]=backbone0:ip=10.0.0.2/30
| |
| − | r2[eth2]=backbone2:ip=10.0.2.1/30
| |
| − |
| |
| − | r3[eth1]=backbone1:ip=10.0.1.2/30
| |
| − | r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
| |
| − | #Rode o '''netKit''' em seu computador. Em um terminal digite: <code> netkit2 & </syntaxhighlight>
| |
| − | #No menu '''File - Load and Run''', procure o arquivo '''/home/aluno/exp1.conf''' e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3.
| |
| − | #Ao clicar no menu '''File - Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
| |
| − | #Testes de conectividade de enlace e configuração do ''default gateway''.
| |
| − | ##Por exemplo, no '''pc1''' execute o comando: <code> ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
| |
| − | ##Teste a conectividade do '''pc1''' executando o comando: <code> ping 10.0.0.1 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
| |
| − | ##Por exemplo, no '''pc1''' execute o comando: <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
| |
| − | ##Configure o roteador padrão em todos os PCs, por exemplo no '''pc1''': <code> route add -net default gw 192.168.0.254 </syntaxhighlight>
| |
| − | ##Teste novamente a conectividade, no '''pc1''' execute o comando: <code> ping 10.0.0.1 </syntaxhighlight> e <code> ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo dos iten 5.2 e 5.3? Sim ou não e por quê?
| |
| − | ##Com os ping do item anterior ativos (um a cada tempo) rode o '''wireshark''' no '''r1''' (clique na aba '''r1''' e em seguida no menu '''wireshark any'''. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (''reload'' <CTRL>+<R>) a captura de pacotes).
| |
| − | ###Qual a origem e destino dos pacotes? Por quê?
| |
| − | ###Qual a diferença no ping entre os dois itens?
| |
| − | ##*Obs: Uma opção ao '''wireshark''' é o [http://www.tcpdump.org/ tcpdump] que permite que se grave todo o tráfego de pacotes para posterior análise, sem influenciar no funcionamento dos experimentos. O arquivo gravado é compatível com o '''wireshark''', ou seja, pode-se abrir um arquivo gravado com o '''tcpdump''' no '''wireshark'''. Por exemplo, para iniciar a captura de pacotes em todas as interfaces de '''r1''', utilize o seguinte comando (atenção ao "&" no final que envia o '''tcpdump''' para ''background'', permitindo o uso normal do terminal): <code> tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight> '''Ao final do experimento''', antes de fechar o Netkit, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''. Os arquivos '''.pcaps''' gerados ficam na pasta /home/aluno/lab, no exemplo '''r1.pcap'''. Ao clicar sobre o mesmo, automaticamente será aberto o '''wireshark'''.
| |
| − | #Iniciando o roteamento
| |
| − | ##Deixe o '''ping''' do item 5.3 e o '''wireshark''' (ou '''tcpdump''') do item 5.6 rodando e estabeleça uma rota no roteador '''r2''' com o comando: <code> route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê?
| |
| − | ##* Interpretando o comando: route add (adiciona rota) -net 192.168.0.0/24 (para a rede 192.168.0.0/24) gw 10.0.0.1 (utilizando a interface 10.0.0.1, enlace direto, do roteador r1).
| |
| − | ##Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes, diretamente conectadas ao equipamento. Se tudo estiver correto, '''todos''' os PCs devem pingar entre si. Teste!
| |
| − | #Testando a queda de enlace.
| |
| − | ##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc1''' para o '''pc3''' e execute '''wireshark any''' no '''r1''' , em seguida "derrube" o enlace entre o '''r1''' e '''r3'''. Por exemplo, no '''r3''' execute o comando: <code> ifconfig eth1 down </syntaxhighlight> O que ocorreu com o '''ping''' e o '''wireshark'''? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede?
| |
| − | #No arquivo abaixo as tabelas de roteamento geram um ''loop''. <code>
| |
| − | # Hosts definitions
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − |
| |
| − | # Default gateways definitions
| |
| − | pc1[default_gateway]=192.168.0.254
| |
| − | pc2[default_gateway]=192.168.1.254
| |
| − | pc3[default_gateway]=192.168.2.254
| |
| − |
| |
| − | # Routers definitions
| |
| − | r1[type]=gateway
| |
| − | r2[type]=gateway
| |
| − | r3[type]=gateway
| |
| − |
| |
| − | # Hosts' interfaces to local routers
| |
| − | pc1[eth0]=link0:ip=192.168.0.1/24
| |
| − | pc2[eth0]=link1:ip=192.168.1.1/24
| |
| − | pc3[eth0]=link2:ip=192.168.2.1/24
| |
| − |
| |
| − | # Routers' interfaces to local networks
| |
| − | r1[eth0]=link0:ip=192.168.0.254/24
| |
| − | r2[eth0]=link1:ip=192.168.1.254/24
| |
| − | r3[eth0]=link2:ip=192.168.2.254/24
| |
| − |
| |
| − | # Network "backbone" links
| |
| − | r1[eth1]=backbone0:ip=10.0.0.1/30
| |
| − | r1[eth2]=backbone1:ip=10.0.1.1/30
| |
| − |
| |
| − | r2[eth1]=backbone0:ip=10.0.0.2/30
| |
| − | r2[eth2]=backbone2:ip=10.0.2.1/30
| |
| − |
| |
| − | r3[eth1]=backbone1:ip=10.0.1.2/30
| |
| − | r3[eth2]=backbone2:ip=10.0.2.2/30
| |
| − |
| |
| − | # Routes definition
| |
| − | r1[route]=192.168.2.0/24:gateway=10.0.0.2
| |
| − | r2[route]=192.168.2.0/24:gateway=10.0.2.2
| |
| − | r3[route]=192.168.2.0/24:gateway=10.0.1.1 </syntaxhighlight>
| |
| − | #*Em todos os roteadores (r1, r2 e r3) rode os seguintes comandos para que os roteadores não filtrem os pacotes: <code>
| |
| − | echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
| |
| − | echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
| |
| − | echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
| |
| − | echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter </syntaxhighlight>
| |
| − | ##Prove que um ping do '''pc1''' ao '''pc3''' (pc1: '''ping -c1 192.168.2.1''') é descartado.
| |
| − | ##Qual foi o roteador que o descartou? Como você conclui isso?
| |
| − |
| |
| − | ==O Pacote Quagga -- Breve introdução ==
| |
| − |
| |
| − | O pacote [http://www.nongnu.org/quagga/ Quagga] fornece um conjunto de processos (''daemons'') com
| |
| − | facilidades para a construção da tabela de roteamento de um sistema. O projeto
| |
| − | Quagga é derivado do pacote Zebra. O esquema abaixo mostra a
| |
| − | estrutura do Quagga.
| |
| − |
| |
| − | [[imagem:EstruturaZebra.png|300px]]
| |
| − |
| |
| − | Acima do kernel se executam processos especializados para a configuração da
| |
| − | tabela de roteamento. Note que a tabela de roteamento é mantida pelo kernel do
| |
| − | Sistema Operacional Linux/Unix e qualquer modificação será realizada a partir
| |
| − | da API (''Application Programming Interface'') do sistema. O processo Zebra
| |
| − | centraliza todo o gerenciamento da tabela recebendo e repassando informações
| |
| − | para outros processos que executam um determinado protocolo de roteamento. Por
| |
| − | exemplo, no esquema mostrado existem 3 processos responsáveis pela execução dos
| |
| − | protocolos BGP, RIP e OSPF. É possível executar
| |
| − | vários protocolos de roteamento dinâmico simultaneamente.
| |
| − |
| |
| − | Cada processo do Quagga possui o seu próprio arquivo de configuração e um
| |
| − | terminal para receber comandos (um processo ''shell'' chamado ''vtysh''). Cada terminal
| |
| − | se comunica com seu ''deamon'' por uma porta específica.
| |
| − | No arquivo do Zebra deverão constar as configurações estáticas.
| |
| − |
| |
| − | Os deamons do sistema são chamados pelos seguintes nomes:
| |
| − | * zebra (acesso pela porta 2601 no vty);
| |
| − | * ripd (acesso pela porta 2602 no vty);
| |
| − | * ospfd (acesso pela porta 2604 no vty);
| |
| − | * bgpd (acesso pela porta 2605 no vty);
| |
| − |
| |
| − | Os ''deamons'' possuem arquivos de configuração por ''default''
| |
| − | localizados normalmente no diretório ''/etc/quagga'' e possuindo a terminação
| |
| − | ''conf'': por exemplo: ''zebra.conf'' para o processo ''zebra''.
| |
| − | Entretanto, em nossos laboratórios, fazendo uso do Netkit, será comum usarmos arquivos de configuração fornecidos na linha de
| |
| − | comando:
| |
| − |
| |
| − | #zebra -d -f /hostlab/r1/zebra.conf.
| |
| − |
| |
| − | Nos arquivos de configuração podemos colocar informações tais como senhas para
| |
| − | o terminal ''vty'', configurações de depuração, de roteamento e de ''log''. O que segue
| |
| − | aos pontos de exclamação (vale também \#) são comentários.
| |
| − |
| |
| − | Através do Zebra (e seu arquivo de configuração) é possível ligar/desligar
| |
| − | interfaces e atribuir endereços as mesmas. Também pode-se acrescentar rotas.
| |
| − |
| |
| − | ==Experimento 2: protocolo de roteamento RIP==
| |
| − |
| |
| − | Tempo aproximado para execução e conferência: 40 min
| |
| − |
| |
| − | Baseado no mesmo diagrama do experimento anterior, usaremos serviços para rodar os protocolos de roteamento RIP e OSPF a partir do Quagga, de tal modo que as tabelas estáticas de roteamento não mais serão necessárias e o sistema se auto recuperará da queda de um único enlace (nesse caso).
| |
| − | #Reinicie o NetKit2 para limpar todas as configurações.
| |
| − | #Crie em seu computador um arquivo com nome '''/home/aluno/exp2.conf'''. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte: <code>
| |
| − | # Hosts definitions
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − |
| |
| − | # Default gateways definitions
| |
| − | pc1[default_gateway]=192.168.0.254
| |
| − | pc2[default_gateway]=192.168.1.254
| |
| − | pc3[default_gateway]=192.168.2.254
| |
| − |
| |
| − | # Routers definitions
| |
| − | r1[type]=gateway
| |
| − | r2[type]=gateway
| |
| − | r3[type]=gateway
| |
| − |
| |
| − | # Hosts' interfaces to local routers
| |
| − | pc1[eth0]=link0:ip=192.168.0.1/24
| |
| − | pc2[eth0]=link1:ip=192.168.1.1/24
| |
| − | pc3[eth0]=link2:ip=192.168.2.1/24
| |
| − |
| |
| − | # Routers' interfaces to local networks
| |
| − | r1[eth0]=link0:ip=192.168.0.254/24
| |
| − | r2[eth0]=link1:ip=192.168.1.254/24
| |
| − | r3[eth0]=link2:ip=192.168.2.254/24
| |
| − |
| |
| − | # Network "backbone" links
| |
| − | r1[eth1]=backbone0:ip=10.0.0.1/30
| |
| − | r1[eth2]=backbone1:ip=10.0.1.1/30
| |
| − |
| |
| − | r2[eth1]=backbone0:ip=10.0.0.2/30
| |
| − | r2[eth2]=backbone2:ip=10.0.2.1/30
| |
| − |
| |
| − | r3[eth1]=backbone1:ip=10.0.1.2/30
| |
| − | r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
| |
| − | #Em cada roteador, configure o serviço RIP para que que os testes da próxima etapa possam ser executados. O Netkit cria no home do usuário uma pasta chamada "lab". Nesta pasta, há uma pasta para cada equipamento da rede em teste. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e BGP. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador '''r1'''. Salve este arquivo com o nome '''zebra.conf''' no diretório '''/home/aluno/lab/r1/'''. Em seguida, adapte o arquivo para os roteadores '''r2''' e '''r3''' observando a figura do diagrama da rede para não errar os IPs.<syntaxhighlight lang=text>
| |
| − | hostname r1
| |
| − |
| |
| − | interface eth0
| |
| − | ip address 192.168.0.254/24
| |
| − | interface eth1
| |
| − | ip address 10.0.0.1/30
| |
| − | interface eth2
| |
| − | ip address 10.0.1.1/30
| |
| − |
| |
| − | log stdout
| |
| − | </syntaxhighlight>
| |
| − | #Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos, por exemplo, para '''r1''' no diretório '''/home/aluno/lab/r1/'''. O nome destes arquivos deve ser '''ripd.conf''' e o conteúdo deve ser o abaixo.<syntaxhighlight lang=text>
| |
| − | router rip
| |
| − | redistribute connected
| |
| − | redistribute static
| |
| − | network eth1
| |
| − | network eth2
| |
| − | </syntaxhighlight>
| |
| − | #No '''pc1''' execute: <code> ping 192.168.2.1 </syntaxhighlight> O ping está funcionando? Por quê?
| |
| − | #Deixe o ping rodando!
| |
| − | #Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight>
| |
| − | #Execute o Quagga e o RIP a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do Netkit, ou seja, "/home/aluno/lab" na máquina rela é a mesmoa pasta que "/hostlab/" nas máquinas virtuais do Netkit. Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos.<syntaxhighlight lang=bash>
| |
| − | zebra -d -f /hostlab/r1/zebra.conf
| |
| − | ripd -d -f /hostlab/r1/ripd.conf
| |
| − | </syntaxhighlight>
| |
| − | #Olhe o terminal do pc1, o que ocorreu com o ping? Por quê?
| |
| − | #Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores.
| |
| − | ##Solicitar uma sessão com o vtysh no ''zebrad'': <code> vtysh </syntaxhighlight>
| |
| − | ##Verifique o estado das interfaces usando o comando: <code> show interface </syntaxhighlight>
| |
| − | ##Verifique se o roteador está habilitado para roteamento: <code> show ip forwarding </syntaxhighlight>
| |
| − | ##Verifique o estado da '''tabela de roteamento''' usando o comando: <code> show ip route </syntaxhighlight> '''Interprete detalhadamente essa tabela'''! Você consegue visualizar o mapa da rede a partir dessa tabela?
| |
| − | ##Verifique a configuração atual do roteador: <code> show run </syntaxhighlight>
| |
| − | ##Sair do vtysh: <code>exit </syntaxhighlight>
| |
| − | #Teste as demais conectividades entre os PCs com ping mútuos. Tudo funcionando?
| |
| − | #A partir de cada PC trace a rota ('''traceroute''') para os demais PC e anote-as.
| |
| − | # Com o '''route -n''' e/ou '''netstat -r''' verifique a anote as rotas de cada roteador.
| |
| − | #Pare todos os pings.
| |
| − | #Execute '''tcpdump -i any -w /hostlab/ripr1.pcap &''' no '''r1'''
| |
| − | #Com o navegador de arquivos entre na pasta '''/home/aluno/lab/''' e dê um duplo click no arquivo '''ripr1.pcap''' e tente compreender as mensagens RIPv2 (UDP 17) trocadas. As mensagens são trocadas aproximadamente a cada minuto, se não aparecer nenhuma no Wireshark faça um ''reload'': <Ctrl+r> até susrgir alguma mensagem. Olhe com atenção os IPs e as métricas apresentadas.
| |
| − | ##O que dizem essas mensagens?
| |
| − | ##Pesquise o significado do endereço 224.0.0.9.
| |
| − | #A partir do r1 deixe rodando o ping <code> ping 192.168.2.1</syntaxhighlight>
| |
| − | #Com o tcpdump rodando em '''r1''', desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens no Wireshark (dê um ''reload''). Por questões de compatibilidade vamos desativar uma interface de um modo especial. Por exemplo, para "derrubar" o enlace r1-r3, execute no '''r1''': <code>
| |
| − | vtysh 2061 entra no zebrad
| |
| − | conf t entra no mode de configuração
| |
| − | interface eth2 entra na referida interface a ser operada
| |
| − | shutdown desativa a interface, se desejado
| |
| − | no shutdown restaura a interface, se desejado </syntaxhighlight>
| |
| − | #Permaneça monitorando o ping e o Wireshark (''reload'': <Ctrl+r>), a recuperação das rotas leva em torno de 1-3 min:
| |
| − | ##Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark? Observe o trecho de mensagens onde não houve respostas ao ping.
| |
| − | ##Qual o tempo aproximado para a total recuperação das rotas? (Isso seja observável pela diferença de tempos (''timestamp'') na sequência de mensagens observadas no Wireshark).
| |
| − | #Teste as conectividades. O que aconteceu?
| |
| − | #Retrace as rotas com nos roteadores <code> vtysh 2061
| |
| − | show ip route </syntaxhighlight> e com o <code> traceroute </syntaxhighlight> a partir dos PCs.
| |
| − | ##São diferentes do caso original (todos enlaces ativos)? Por quê?
| |
| − | ##Quais os caminhos/rotas que foram reescritos? Por quê?
| |
| − |
| |
| − | ==Experimento 3: protocolos e roteamento OSPF==
| |
| − |
| |
| − | Tempo aproximado para execução e conferência: 30 min
| |
| − |
| |
| − | #Reinicie o NetKit2 para limpar todas as configurações.
| |
| − | #Crie em seu computador um arquivo com nome '''/home/aluno/exp2.conf'''. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte: <code>
| |
| − | # Hosts definitions
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − |
| |
| − | # Default gateways definitions
| |
| − | pc1[default_gateway]=192.168.0.254
| |
| − | pc2[default_gateway]=192.168.1.254
| |
| − | pc3[default_gateway]=192.168.2.254
| |
| − |
| |
| − | # Routers definitions
| |
| − | r1[type]=gateway
| |
| − | r2[type]=gateway
| |
| − | r3[type]=gateway
| |
| − |
| |
| − | # Hosts' interfaces to local routers
| |
| − | pc1[eth0]=link0:ip=192.168.0.1/24
| |
| − | pc2[eth0]=link1:ip=192.168.1.1/24
| |
| − | pc3[eth0]=link2:ip=192.168.2.1/24
| |
| − |
| |
| − | # Routers' interfaces to local networks
| |
| − | r1[eth0]=link0:ip=192.168.0.254/24
| |
| − | r2[eth0]=link1:ip=192.168.1.254/24
| |
| − | r3[eth0]=link2:ip=192.168.2.254/24
| |
| − |
| |
| − | # Network "backbone" links
| |
| − | r1[eth1]=backbone0:ip=10.0.0.1/30
| |
| − | r1[eth2]=backbone1:ip=10.0.1.1/30
| |
| − |
| |
| − | r2[eth1]=backbone0:ip=10.0.0.2/30
| |
| − | r2[eth2]=backbone2:ip=10.0.2.1/30
| |
| − |
| |
| − | r3[eth1]=backbone1:ip=10.0.1.2/30
| |
| − | r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
| |
| − | #Crie os arquivos de configuração para o OSPF em cada roteador, colocando-os dentro dos diretórios dos mesmos (p. ex: /home/aluno/lab/r1). O nome destes arquivos deve ser '''ospfd.conf''' e o conteúdo deve ser conforme o modelo abaixo para o '''r1'''. Para o '''r2''' e '''r3''' faça as adaptações necessárias.<syntaxhighlight lang=text>
| |
| − | #Router r1
| |
| − | #
| |
| − | hostname r1
| |
| − | password r1
| |
| − | enable password r1
| |
| − | #
| |
| − | interface eth0
| |
| − | interface eth1
| |
| − | interface eth2
| |
| − | !ip ospf network point-to-point
| |
| − | router ospf
| |
| − | passive-interface eth0
| |
| − | network 192.168.0.0/24 area 0
| |
| − | network 10.0.0.0/30 area 0
| |
| − | network 10.0.1.0/30 area 0
| |
| − | #
| |
| − | log stdout
| |
| − | </syntaxhighlight>
| |
| − | #Os arquivos '''zebra.conf''' são os mesmos utilizados no experimento 2.
| |
| − | #Inicie o ''daemon'' ''quagga'' em todos os roteadores (r1, r2 e r3). <code> service quagga start </syntaxhighlight>
| |
| − | #Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do NetKit. Para iniciar os serviços no '''r1''', faça algo como o que está no exemplo abaixo. Repita o procedimento para '''r2''' e '''r3''' utilizando os arquivos corretos.<code>
| |
| − | zebra -d -f /hostlab/r1/zebra.conf
| |
| − | ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight>
| |
| − | #Repita, na medida do possível e fazendo os devidos ajustes, as atividades 11 a 21 do experimento anterior e responda, além das respectivas questões desses itens:
| |
| − | ##As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP?
| |
| − | ##Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê?
| |
| − | {{Collapse bottom}}
| |
| − |
| |
| − | {{Collapse top |Laboratório 8 - ''Neighbor Discovery'' no IPv6}}
| |
| − | Este roteiro foi baseado no material disponível em [http://www.paulogurgel.com.br/].
| |
| − |
| |
| − | Slides de [http://docente.ifsc.edu.br/odilson/RED29004/IPv6_e_MIPv6.pdf endereçamento IPv6].
| |
| − |
| |
| − | [http://docente.ifsc.edu.br/odilson/RED29004/enderec-v6.pdf Guia didático de endereçamento IPv6] obtido de http://ipv6.br/.
| |
| − |
| |
| − | ===Objetivos do laboratório:===
| |
| − | *Um primeiro contato com o protocolo [https://pt.wikipedia.org/wiki/IPv6 IPv6]
| |
| − | *Compreender o funcionando do ''Neighbor Discovery'', o equivalente ao ARP (''Address Resolution Protocol'') do IPv4, que em resumo é uma tabela contendo a relação ente IPs e MACs.
| |
| − | *Aprender configurações básicas de interfaces IPv6 no Linux
| |
| − | *Aprender configurações básicas de rotas IPv6
| |
| − |
| |
| − | ===Introdução teórica===
| |
| − | Obs.: texto copiado literalmente de: [http://ipv6.br/lab/ Laboratório de IPv6].
| |
| − |
| |
| − | A '''descoberta de vizinhança''' por meio do protocolo ''Neighbor Discovery'' no
| |
| − | IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4.
| |
| − | *O procedimento é iniciado quando um dispositivo tenta enviar um pacote cujo endereço físico de destino é desconhecido. O nó solicitante envia uma mensagem ''Neighbor Solicitation'' (NS) para todos os nós do enlace pertencentes ao grupo ''multicast solicited-node'' (ff02::1:ffXX:XXXX), de modo que XX:XXXX são os últimos 24 bits do endereço IPv6 em que está interessado.
| |
| − | *É possível notar que, por uma coincidência dos últimos 24 bits, é bastante provável que apenas o nó de destino faça realmente parte deste grupo. Isto é um ''truque'' interessante do IPv6 para diminuir o tráfego deste tipo de pacote na rede.
| |
| − | *Na mensagem NS, o endereço IPv6 a ser resolvido é informado no campo ''Target''. O campo ''Source link-layer address'' informa ao nó de destino o endereço MAC do nó de origem, poupando-o de ter que fazer o mesmo procedimento no sentido inverso.
| |
| − | *O nó de destino, dono do IPv6 requisitado, ao receber este pacote, envia uma mensagem ''Neighbor Advertisement'' (NA) como resposta diretamente ao nó requisitante. O seu endereço físico será informado no campo ''Target link-layer address''.
| |
| − | *A informação de mapeamento entre endereços IP e endereços físicos é armazenada em uma tabela chamada ''neighbor cache''. Nela também fica registrado o ''status'' de cada destino, informando se o mesmo é alcançável ou não.
| |
| − |
| |
| − | ===Roteiro de atividades:===
| |
| − | A figura abaixo apresenta o diagrama esquemático da rede a ser montada/analisada. Observe que todos os IPv6 ''Global Unicast'' já estão definidos na mesma, são esses IP que utilizaremos em nosso experimento.
| |
| − |
| |
| − | [[Arquivo:Diagrama_rede_IPv6.jpg]]
| |
| − |
| |
| − | #Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo: <code>
| |
| − | #Ligacao das maquinas nos dominios de colisao
| |
| − | #Duas pequenas redes interligadas pelo backbone
| |
| − |
| |
| − | # Hosts definitions
| |
| − | pc1[type]=generic
| |
| − | pc2[type]=generic
| |
| − | pc3[type]=generic
| |
| − | pc4[type]=generic
| |
| − |
| |
| − | # Routers definitions
| |
| − | r1[type]=gateway
| |
| − | r2[type]=gateway
| |
| − |
| |
| − | # Hosts' interfaces to local routers
| |
| − | pc1[eth0]=link0
| |
| − | pc2[eth0]=link1
| |
| − |
| |
| − |
| |
| − | r1[eth0]=backbone0
| |
| − | r1[eth1]=link0
| |
| − | r1[eth2]=link1
| |
| − |
| |
| − | r2[eth0]=backbone0
| |
| − | r2[eth1]=HUB1
| |
| − |
| |
| − |
| |
| − | pc3[eth0]=HUB1
| |
| − | pc4[eth0]=HUB1
| |
| − |
| |
| − |
| |
| − | #Definicao da quantidade de memoria disponivel para cada pc.
| |
| − | pc1[mem]=32
| |
| − | pc2[mem]=32
| |
| − | pc3[mem]=32
| |
| − | pc4[mem]=32
| |
| − | r1[mem]=64
| |
| − | r2[mem]=64 </syntaxhighlight>
| |
| − | #Rode o NetKit em seu computador. Em um terminal digite: <code>
| |
| − | netkit2 & </syntaxhighlight>
| |
| − | #No menu '''File''' - '''Load and Run''', procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: '''pc1-4''' ou '''r1-2'''.
| |
| − | #Ao clicar no menu '''File''' - '''Graph''', pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
| |
| − | #Em todos os equipamentos, iremos iniciar a captura de pacotes em uma das interfaces que será gravado em um arquivo para estudo posterior. Utilize os seguintes comandos (atenção ao "&" no final que envia o tcpdump para background):
| |
| − | ##'''pc1''': tcpdump -i eth0 -w /hostlab/ipv6_pc1.pcap &
| |
| − | ##'''pc2''': tcpdump -i eth0 -w /hostlab/ipv6_pc2.pcap &
| |
| − | ##'''pc3''': tcpdump -i eth0 -w /hostlab/ipv6_pc3.pcap &
| |
| − | ##'''pc4''': tcpdump -i eth0 -w /hostlab/ipv6_pc4.pcap &
| |
| − | ##'''r1''': tcpdump -i eth0 -w /hostlab/ipv6_r1.pcap &
| |
| − | ##'''r2''': tcpdump -i eth0 -w /hostlab/ipv6_r2.pcap &
| |
| − | #No '''pc1''' use o seguinte comando para adicionar o endereço IPv6 à interface de rede: <code>
| |
| − | ip addr add 2001:bcc:faca:1::101/64 dev eth0 </syntaxhighlight>
| |
| − | #No '''pc1''' use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando '''ifconfig''': <code>
| |
| − | ip addr show dev eth0 </syntaxhighlight>
| |
| − | #Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede (adapte os números de IPs), seguindo o exemplo do item 6.
| |
| − | #Faça um '''ping6''' entre o '''pc3''' ao '''pc4'''. Por exemplo do '''pc3''' ao '''pc4''': <code>
| |
| − | ping6 -c4 2001:bcc:1f0:1::104 </syntaxhighlight>
| |
| − | #Se tudo estiver devidamente configurado, deve-se obter sucesso. Explique o por quê?
| |
| − | #Faça um '''ping6''' entre o '''pc1''' ao '''pc2'''.
| |
| − | #Obteve sucesso? Sim ou não e por quê?
| |
| − | #Nos computadores '''pc3''' e '''pc4''', acrescente o ''default gateway'' com o seguinte comando: <code>
| |
| − | ip -6 route add default via 2001:bcc:1f0:1::1 dev eth0 </syntaxhighlight>
| |
| − | #Nos computadores '''pc1''' e '''pc2''', acrescente o ''default gateway'' analisando o diagrama da rede e adaptando o comando acima.
| |
| − | #Faça novamente o '''ping6''' entre o '''pc1''' ao '''pc2'''.
| |
| − | #Obteve sucesso? Sim ou não e por quê?
| |
| − | #Faça um '''ping6''' entre o '''pc1''' ao '''pc4'''.
| |
| − | #Obteve sucesso? Sim ou não e por quê?
| |
| − | #Configure os roteadores para habilitar o repasse de pacotes entre as interfaces utilizando os seguintes comandos:
| |
| − | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
| |
| − | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
| |
| − | ##'''r1''': echo 1 > /proc/sys/net/ipv6/conf/eth2/forwarding
| |
| − | ##'''r2''': echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
| |
| − | ##'''r2''': echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
| |
| − | #No '''r1''', adicione uma rota estática para a rede dos '''pc3''' e '''pc4''' através do seguinte comando: <code>
| |
| − | ip -6 route add 2001:bcc:1f0:1::/64 via 2001:db8:dead:1::2 dev eth0 </syntaxhighlight>
| |
| − | #No '''r2''', adicione uma rota estática para a rede dos '''pc1''' e '''pc2''' através dos seguintes comandos: <code>
| |
| − | ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0
| |
| − | ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight>
| |
| − | #Faça novamente o '''ping6''' entre o '''pc1''' ao '''pc4'''.
| |
| − | #Obteve sucesso? Sim ou não e por quê?
| |
| − | #Use os comandos '''traceroute6 2001:bcc:1f0:1::103''' e '''traceroute6 2001:bcc:1f0:1::104''' a partir do computador '''pc1'''.
| |
| − | #Anote as rotas.
| |
| − | #Use o comando '''ip -6 route show''' para consultar a tabela de roteamento de cada um dos roteadores. São coerentes com os dados das rotas obtidas acima?
| |
| − | #Explique a tabela de roteamento do '''r1''', em especial os endereços de '''link local'''. Porque não há confusão dos prefixos?
| |
| − | #É possível utilizar os comandos '''route''' e '''ifconfig''' para configurar redes IPv6? Pesquise rapidamente no google e tente realizar a configuração do '''pc4''' utilizando estes comandos. Para isso, use o comando '''ip addr flush dev eth0''' no '''pc4''' para limpar toda a configuração de endereços e rotas da interface. Depois disso configure o endereço com '''ifconfig''' e as rotas com o comando '''route'''.
| |
| − | #Em cada uma das máquinas virtuais, use o comando '''fg tcpdump''' para trazer o '''tcpdump''' para o primeiro plano. Em seguida encerre a captura com '''Ctrl + C'''.
| |
| − | #Estude os '''.pcaps''' gerados utilizando o '''wireshark''': abra o '''wireshark''', '''File/Open''' e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise.
| |
| − | #Explique o processo de descoberta de vizinhança (''neighbor discovery'' / ''Neighbor Solicitation'' - '''NS''' e ''Neighbor Advertisement'' - '''NA'''), citando os endereços de '''multicast''' e '''link local''' utilizados.
| |
| − | #Alguns exemplos de campos visualizáveis para uma mensagem do tipo ''Neighbor Advertisement'':
| |
| − | ##Destination (camada Ethernet)
| |
| − | ##*O endereço MAC do nó requisitante que foi obtido por meio da mensagem NS enviada anteriormente.
| |
| − | ##Source (camada Ethernet)
| |
| − | ##*A origem é o endereço MAC da interface do dispositivo que enviou a resposta.
| |
| − | ##Type (camada Ethernet)
| |
| − | ##*Indica que a mensagem utiliza IPv6.
| |
| − | ##Next header (camada IPv6)
| |
| − | ##*Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6.
| |
| − | ##Source (camada IPv6)
| |
| − | ##*A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida.
| |
| − | ##Destination (camada IPv6)
| |
| − | ##*Diferentemente da mensagem NS, a mensagem NA possui como destino o endereço IPv6 global do nó requisitante.
| |
| − | ##Type (camada ICMPv6)
| |
| − | ##*Indica que a mensagem é do tipo 136 (Neighbor Advertisement).
| |
| − | ##Flags (camada ICMPv6)
| |
| − | ##*Uma mensagem NA possui três flags:
| |
| − | ###Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador.
| |
| − | ###Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta.
| |
| − | ###Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez.
| |
| − | ##Target Address (camada ICMPv6)
| |
| − | ##*Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão.
| |
| − | ##ICMPv6 option (camada ICMPv6)
| |
| − | ##*Indica as opções do pacote ICMPv6:
| |
| − | ###Target link-layer address
| |
| − | ##Type
| |
| − | ##*Indica o tipo de opção. Neste caso, Target link-layer address.
| |
| − | ##Link-layer address
| |
| − | ##*Indica o endereço MAC da interface do dispositivo em questão.
| |
| − | #Numa mensagem do tipo ''Neighbor Solicitation'' qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
| |
| − | #Analisando o tráfego gerado no '''pc1''', identifique aproximadamente quais os números (No.) de troca de pacotes nas ocorrência de '''ping6'''. Quais dais ocorrências obtiveram sucesso e quais não obtiveram? Quando não houve sucesso, qual é a causa listada no WireShark? Relacione esses dados com o itens do roteiro executado.
| |
| − | #Em todos os hosts rode o comando <code> ip -6 neighbor show </syntaxhighlight>.
| |
| − | ##Qual é a funcionalidade desse comando?
| |
| − | ##Qual é o significado do conteúdo dessa tabela?
| |
| − | ##A tabela mostrada em cada um dos casos é compatível com o diagrama da rede montado?
| |
| − | ##Por que, por exemplo, na tabela do '''pc3''' não há uma referência explícita ao '''pc1'''?
| |
| − | #Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.
| |
| − | {{Collapse bottom}}
| |
| | | | |
| | == Softwares == | | == Softwares == |
| − | | + | * [http://imunes.net/ Imunes] Simulador/Emulador de redes (''Integrated Multiprotocol Network Emulator/Simulator'') |
| | * [[Netkit2]]: possibilita criar experimentos com redes compostas por máquinas virtuais Linux. | | * [[Netkit2]]: possibilita criar experimentos com redes compostas por máquinas virtuais Linux. |
| | * Vários [http://wiki.netkit.org/index.php/Labs_Official laboratórios virtuais do NetKit], prontos para uso, que focam em serviços específicos de redes de computadores. | | * Vários [http://wiki.netkit.org/index.php/Labs_Official laboratórios virtuais do NetKit], prontos para uso, que focam em serviços específicos de redes de computadores. |
| − | * [http://www.brianlinkletter.com/core-network-emulator-test-drive/ ''CORE Network Emulator'']. | + | * [http://ipv6.br/pagina/livro-ipv6/ Laboratórios de IPv6 baseado no ''CORE''] |
| − | * [http://ipv6.br/pagina/livro-ipv6/ Laboratório de IPv6 baseado no ''CORE''] | + | * [http://www.davidc.net/sites/default/subnets/subnets.html Calculadora visual de sub-redes] |
| | | | |
| − | = Curiosidades = | + | =Curiosidades= |
| | | | |
| | * [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP - PoP-SC] | | * [http://www.pop-sc.rnp.br/publico/monitoramento.php Monitoramento do tráfego RNP - PoP-SC] |
| − | * [http://memoria.rnp.br/ceo/trafego/panorama.php Monitoramento do tráfego RNP - Nacional] | + | * [https://www.rnp.br/sistema-rnp/ferramentas/panorama-de-trafego Monitoramento do tráfego RNP - Nacional] |
| − | * [http://www.redclara.net/index.php/pt/red-y-conectividad/topologia Rede Clara Internacional] | + | * [http://www.redclara.net/index.php/pt/red/redclara/topologia-actual-de-la-red Rede Clara Internacional] |
| | + | * [https://eventos.rnp.br/sites/default/files/activity/activity-presentation/apresentacao_wrnp_2017_eduardo_grizenid_v_1.2.pdf Futura infraestrutura de rede da RNP] |
| | + | * [https://http2.akamai.com/demo Comparativo HTTP/1.1 vs HTTP/2] |
| | * [https://www.youtube.com/watch?v=IlAJJI-qG2k Animated map shows the undersea cables that power the internet] | | * [https://www.youtube.com/watch?v=IlAJJI-qG2k Animated map shows the undersea cables that power the internet] |
| − | * [http://submarine-cable-map-2017.telegeography.com/ Submarine Cable Map 2017] | + | * [https://submarine-cable-map-2019.telegeography.com/ Submarine Cable Map 2019] |
| − | * [https://wigle.net/ Redes WiFi no mundo] | + | * [https://www.bbc.com/portuguese/geral-50162526 A pré-história da internet] |
| | * [https://www.youtube.com/watch?v=9hIQjrMHTv4 ''History of the Internet''] | | * [https://www.youtube.com/watch?v=9hIQjrMHTv4 ''History of the Internet''] |
| | * [https://www.youtube.com/watch?v=A5dD2x2iQx8 ''History of the Internet'' - legendado] | | * [https://www.youtube.com/watch?v=A5dD2x2iQx8 ''History of the Internet'' - legendado] |
| Linha 1 663: |
Linha 335: |
| | * [https://db-ip.com/200.135.37.65 Localização geográfica de IPs] | | * [https://db-ip.com/200.135.37.65 Localização geográfica de IPs] |
| | * [http://ipv6.br/ '''IPv6 no Brasil'''] | | * [http://ipv6.br/ '''IPv6 no Brasil'''] |
| | + | * [https://www.youtube.com/watch?v=5OtebbSnwoM Fragmentação no IPv4 e IPv6] |
| | * [http://ipv6.br/lab/ Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6] | | * [http://ipv6.br/lab/ Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6] |
| | + | * [https://www.google.com/intl/pt-BR/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption Estatísticas Google sobre IPv6] |
| | * [https://http2.github.io/faq/#will-http2-replace-http1x HTTP/2 Frequently Asked Questions] | | * [https://http2.github.io/faq/#will-http2-replace-http1x HTTP/2 Frequently Asked Questions] |
| | * [https://www.youtube.com/watch?v=8XxeAw_d-BI Iniciação à máquinas de estados] | | * [https://www.youtube.com/watch?v=8XxeAw_d-BI Iniciação à máquinas de estados] |
| | | | |
| − | = Seminários = | + | =Seminários= |
| | | | |
| − | *Objetivos: | + | * Objetivos: |
| − | **Aprofundamento teórico em algum tema atual e relevante. | + | ** Aprofundamento teórico em algum tema atual e relevante. |
| − | **Confecção de um relatório de trabalho no estilo científico. | + | ** Confecção de um relatório de trabalho no estilo científico. |
| − | **Apresentação de um trabalho científico. | + | ** Apresentação de um trabalho científico. |
| | | | |
| − | * Avaliação | + | * Avaliação: |
| | ** Conceito: 0,5 x Nota atribuída ao relatório + 0,5 x Nota atribuída a apresentação do seminário | | ** Conceito: 0,5 x Nota atribuída ao relatório + 0,5 x Nota atribuída a apresentação do seminário |
| − | **[http://docente.ifsc.edu.br/odilson/RED29004/Criterios%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] | + | ** [http://docente.ifsc.edu.br/odilson/RED29004/Criterios%20de%20avaliacao%20dos%20relatorios%20e%20apresentacao.pdf Critérios de avaliação] |
| − | | |
| − | *Equipes 2017/2
| |
| − | **Suyan e Daniel: '''Protocolo ''BlockChain'''''.
| |
| − | **Yara e Gustavo Prin: '''Cabos submarinos'''.
| |
| − | **Marconi e Roque: '''VoIP'''.
| |
| − | **Gabriel Turnes e Thiago S. Ouriques: '''Criptografia'''.
| |
| − | **Ameliza e Yan: '''Li-Fi'''.
| |
| | | | |
| | * ''Instruções sobre o Seminário de Redes I'': | | * ''Instruções sobre o Seminário de Redes I'': |
| | ** 2 alunos por equipe. | | ** 2 alunos por equipe. |
| | ** Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem. | | ** Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem. |
| − | ** O relatório pode ser redigido como uma página da wiki ou em PDF gerado por editores/diagramadores de texto do tipo LaTeX ou outro editor qualquer. Detalhes e conteúdo mínimo baseado no [http://docente.ifsc.edu.br/odilson/RED29004/modelo_relatorio.odt modelo de relatório]. Um exemplo de bom relatório [http://docente.ifsc.edu.br/odilson/RED29004/IPv6_relatorio_modelo.pdf]. | + | ** O relatório pode ser redigido como uma página da wiki ou em PDF gerado por editores/diagramadores de texto do tipo LaTeX ([https://www.overleaf.com?r=f1c329a2&rm=d&rs=b Online LaTeX Editor Overleaf]) ou outro editor qualquer. |
| − | **Data de definição dos temas: 19/10/2017. | + | *** Detalhes e conteúdo mínimo exigido baseado no [http://docente.ifsc.edu.br/odilson/RED29004/modelo_relatorio.pdf modelo de relatório]. |
| − | **Data de entrega do relatório: 16/11/2017. | + | *** Se desejar fazer em LaTeX (<span style="color: red;"> RECOMENDADO<span style="color: black;">) inscreva-se em [https://www.overleaf.com?r=f1c329a2&rm=d&rs=b Overleaf] e siga (copie) o [https://github.com/emersonmello/modelos-latex].</span></span> |
| − | **Data das apresentações: a partir de 05/12/2017. | + | *** Um exemplo de bom relatório [http://docente.ifsc.edu.br/odilson/RED29004/IPv6_relatorio_modelo.pdf]. |
| | + | ** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas, [http://docente.ifsc.edu.br/odilson/RED29004/Exemplo_Apresentacao.pdf modelo de apresentação] |
| | + | ** As apresentações devem obrigatoriamente ser preparadas em formato de slides ou equivalente e podem conter demonstrações, filmes, acesso a sites etc. |
| | + | ** Existem vários modelos (templates) disponíveis de apresentações. |
| | + | *** Modelo disponibilizado no [https://github.com/emersonmello/modelos-latex]. |
| | + | *** Procure aqui um template que você goste [https://www.overleaf.com/latex/templates/tagged/beamer Overleaf Template - Beamer] |
| | + | |
| | + | <span style="font-size:180%">Semestre 2023/2 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: '''10/11/2023''' |
| | + | ## Equipe 1: '''Redes WiFi'''. Bryan Pacheco |
| | + | ## Equipe 2: '''IoT'''. Tiago Correa Damiani e Beatriz Abreu |
| | + | ## Equipe 3: '''IPv6'''. Luis Eduardo de Abreu e Gustavo Ferreira de Castro |
| | + | ## Equipe 4: '''Peer-to-peer'''. Júlia Espíndola Steinbach |
| | + | ## Equipe 5: '''RFID'''. Beatriz Paz Faria |
| | + | ## Equipe 6: '''Protocolos de roteamento: IGRP e EIGRP'''. Leonardo Tives Voltolini |
| | + | # Entrega do relatório: '''30/11''' |
| | + | # Apresentação dos seminários: '''12/12 a 14/12''' |
| | + | |
| | + | {{collapse top |Semestre 2023/1}} |
| | + | <span style="font-size:180%">Semestre 2023/1 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: 16/05/2023 |
| | + | ## Equipe 1: '''Protocolo WiFi'''. Rafael Mery e Sérgio Rohling |
| | + | ## Equipe 2: '''Redes 5G'''. Gian e Beatriz |
| | + | ## Equipe 3: '''Redes Mesh'''. Gabriel e Ricardo. |
| | + | # Entrega do relatório escrito: 09/06/2023 |
| | + | # Apresentação dos seminários: 23 e 27/06/2023 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top |Semestre 2022/2}} |
| | + | <span style="font-size:180%">Semestre 2022/2 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: 03/11/2022 |
| | + | ## '''Internet via satélite''': Ramon dos Santos Sobrinho e José Roberto Brincas Junior; |
| | + | ## '''RADIUS''': Arthur Cadore, Matheus Pires, Gabriel Luiz; |
| | + | ## '''VOIP''': Marcos Wagner e Julio César. |
| | + | ## '''RFID''': Faber Bernardo, Lucas Costa Fontes e Jamilly Da Silva Pinheiro; |
| | + | ## '''PPPoE''': Igor Silva Vieira e Rhenzo Hideki; |
| | + | ## '''P2P''': Jonathan Santos, Tiago Nelson e Rafael Ramos |
| | + | ## '''TR-069''': Bruno Hamon Porto, Joana da Silva e Igor Budag de Oliveira |
| | + | # Entrega do relatório escrito: 27/11/2022 |
| | + | # Apresentação dos seminários: 8, 12 e 15/12/2022 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top |Semestre 2022/1}} |
| | + | <span style="font-size:180%">Semestre 2022/1 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: 24/06/2022 |
| | + | ##Alisson e Gustavo: LoRaWAN |
| | + | ##Jailson e Lucas: Protocolos IoT |
| | + | # Entrega do relatório escrito: 10/07/2022 |
| | + | # Apresentação dos seminários: 20/07/2022 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top |Semestre 2021/1}} |
| | + | <span style="font-size:180%">Semestre 2021/2 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: 16/02/2022 |
| | + | ##Wagner e Lucas: '''IPTV''' |
| | + | ##Gabriela e Yago: '''5G''' |
| | + | ##Athos e Lucas May: '''Blockchain''' |
| | + | ##Ramon e José Roberto: '''Internet via satélite''' |
| | + | ##Natália e Pedro Henrique: '''NFC''' |
| | + | |
| | + | # Entrega do relatório escrito: 02/03/2022 |
| | + | # Apresentação dos seminários: 11/03/2022 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top |Semestre 2021/1}} |
| | + | * Organização: |
| | + | # Definição do temas e equipes: 30/07/2021 |
| | + | #*Mike - LiFi |
| | + | #*João Vitor - BLE (''Bluetooth Low Energy'') |
| | + | # Entrega do relatório escrito: 19/08/2021 |
| | + | # Apresentação dos seminários: 02/09/2021 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top | Semestre 2020/2}} |
| | + | <span style="font-size:180%">Semestre 2020/2 </span> |
| | + | * Organização |
| | + | # Definição do temas e equipes: 04/03/2021 |
| | + | ## Alana e Vinícius: '''Segurança em Wi-Fi'''. |
| | + | ## Filipi: '''Internet via satélite'''. |
| | + | # Entrega do relatório escrito: 25/03/2021 |
| | + | # Apresentação dos seminários: 15/04/2021 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top | Semestre 2020/1}} |
| | + | * Organização |
| | + | # Definição do temas: 18/06/2020 |
| | + | ## Arthur Anastopulos dos Santos: Segurança em Cloud Computing / Nuvens Computacionais. |
| | + | ## Deivid Fortunato Frederico: GPON. |
| | + | ## Isadora Schmidt de Souza: Segurança em Rede. |
| | + | ## Matheus Medeiros: Segurança em Redes Wireless IEEE 802.11. |
| | + | ## Jéssica Carrico e Pedro Pretto: 5G. |
| | + | # Entrega do relatório escrito: 21/08/2020 |
| | + | # Apresentação dos seminários: ??/08/2020 |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top | Semestre 2019/2}} |
| | + | * '''Entrega do documento escrito''': dia '''27/11/2019'''. |
| | + | * '''Realização dos Seminários''': dias '''04/12''' e '''06/12/2019'''. |
| | + | |
| | + | ** (04/12)-Jean e Jefferson Botitano: '''Padrão IEEE 802.15.4 / ZigBee'''. |
| | + | ** (04/12)-Pedro e Vinícius: '''Blockchain'''. |
| | + | ** (06/12)-Christian e Matheus: '''Padrão IEEE 802.11ac/ad'''. |
| | + | ** (04/12)-Alisson: '''BLE'''. |
| | + | ** (04/12)-Isadora: '''Segurança em Redes'''. |
| | + | ** (04/12)-Anderson: '''LoRaWAN'''. |
| | + | ** (06/12)-Leonardo e Jeferson Jair: '''Computação em Nuvem'''. |
| | + | ** (06/12)-Deivid: '''Indústria 4.0'''. |
| | + | ** (06/12)-Irla e Jhonatan '''Li-Fi'''. |
| | + | ** (04/12)-Amanda '''5G'''. |
| | + | * |
| | + | {{collapse bottom}} |
| | + | {{collapse top | Semestre 2019/1}}'''Entrega do documento escrito''': dia 23/06/2019.'''Realização dos Seminários''': dias 27/06 e 01/07/2019.Bruno e Gustavo: '''Segurança na Rede'''.Maria Gabriela: '''5G'''. |
| | + | * Amanda e Joseane: '''NFC'''. |
| | + | |
| | + | * Luan e Gabriel: '''Blockchaim'''. |
| | + | * Guilherme: '''Computação em Nuvem'''. |
| | + | |
| | + | |
| | + | {{collapse bottom}} |
| | + | |
| | + | {{collapse top | Semestre 2018/2}} |
| | + | |
| | + | * Datas Importantes |
| | + | # Definição do temas: 15/10/2018 |
| | + | ## Luiza Alves da Silva: '''Criptografia na Rede'''. Dia 10/12 |
| | + | ## Sarom e Marcelo: '''Evolução da tecnologia DOCSIS'''. Dia 13/12 |
| | + | ## André e Thiago: '''GPON'''. Dia 06/12 |
| | + | ## Eduarda e Guilherme: '''Deep Web'''. Dia 10/12 |
| | + | ## Stefanie e Camilla: '''Computação em nuvem'''. Dia 13/12 |
| | + | ## Elisa e Osvaldo: '''LoRaWAN'''. Dia 10/12 |
| | + | ## Daniel: '''Segurança em redes sem fio''' |
| | + | ## Gabriel Santos: '''VoIP'''. Dia 13/12 |
| | + | ## Matheus: '''Industria 4.0'''. Dia 06/12 |
| | + | ## Alexandre: '''BlockChain'''. Dia 13/12 |
| | + | ## Gabriel Turnes: '''5G'''. Dia 06/12 |
| | + | # Entrega do relatório escrito: 22/11/2018 |
| | + | # Apresentação dos seminários: 06-13/12/2018 |
| | + | |
| | + | {{collapse bottom}} |
| | | | |
| − | ** Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas. | + | {{collapse top | Semestre 2018/1}} |
| − | ** As apresentações devem obrigatoriamente ser preparadas em formato de slides ou equivalente e podem conter demonstrações, filmes, acesso a sites etc. | + | |
| | + | * Data de definição dos temas: 15/05/2018. |
| | + | * Data de entrega do relatório: 11/06/2018. |
| | + | * Data das apresentações: 25/06/2018 e 26/06/2018. |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/Tecnologia%20LoRaWAN_Victor_Augusto_Comentado.pdf Tecnologia LoRaWAN]''': Augusto da Silveira Willemann, Andre Luiz Faraco Mazucheli e Victor Cesconetto De Pieri |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/Proxy%20Reverso%20-%20Jeneffer%20e%20Jo%C3%A3o%20Pedro%20Comentado.pdf Proxy reverso]''': Jennifer e João |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/Felipe_Relatorio_IoT_e_6LoWPAN_Comentado.pdf 6LowPAN]''': Felipe Cardoso |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/Gabriel%20Santos%20de%20Souza%20-%20Relat%C3%B3rio%20Semin%C3%A1rio%20Comentado.pdf Li-Fi]''': Gabriel Santos de Souza |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/Alisson,%20Alexandre%20e%20Guilherme%20(SEMINARIO%20REDES)%20Comentado.pdf Internet via satélite]''': Guilherme, Alisson e Alexandre |
| | + | * '''[http://docente.ifsc.edu.br/odilson/RED29004/luiza%20alves%20da%20silva%20Comentado.pdf 5G]''': Luiza Alves da Silva |
| | + | {{collapse bottom}} |
