RED29004-2015-2

Diário de aula de RED - 2015-2 - Prof. Odilson T. Valle

Dados Importantes

Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª das 15h40 às 16h35 e 5ª das 9h40 às 10h35. Local: Lab. de Desenvolvimento.

• Avaliações
  • 3 avaliações (P1, P2 e P3) mais um seminário (S).
  • Cada uma das avaliações terá terá um conceito: A, B, C e D. Conceito mínimo para não necessitar reavaliação: C.
  • Reavaliação única a ser realizada no último dia de aula.

IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.

Cronograma de Atividades

RED29004 2015-2 - Prof. Odilson T. Valle

Material de apoio

Applets do Kurose

Vários aplicativos com representação dinâmica de características das redes de computadores.

Listas de exercícios

Lista de exercícios 1 - Introdução

Qual é a diferença entre um hospedeiro e um sistema final? Cite os tipos de sistemas finais. Um servidor web é um sistema final? O que caracteriza um protocolo? Dê um exemplo de um protocolo. Por que os padrões são importantes para os protocolos? O que é um programa cliente? O que é um programa servidor? Um programa servidor requisita e recebe serviços de um programa cliente? Quais são os dois tipos de serviços de transporte que a Internet provê às suas aplicações? Cite algumas características de cada um desses serviços. Quais são as vantagens de uma rede de comutação de circuitos em relação a uma rede de comutação de pacotes? Quais são os prós e contras da utilização de Circuitos Virtuais? Porque se afirma que a comutação de pacotes emprega multiplexação estatística? Compare a multiplexação estatística com a multiplexação que ocorre em TDM. A taxa de transmissão HFC é dedicada ou compartilhada entre os usuários? É possível haver colisões na direção do provedor – usuário de um canal HFC? Por quê? Cite cinco tecnologias de acesso. Classifique cada uma delas nas categorias acesso residencial, acesso corporativo ou acesso móvel. FTTH, HFC e ADSL são usados para acesso residencial. Para cada uma dessas tecnologias de acesso, cite uma faixa de taxas de transmissão e comente se a largura de banda é compartilhada ou dedicada. Considere o envio de um pacote de uma máquina de origem a uma de destino por uma rota fixa. Relacione os componentes do atraso que formam o atraso fim-a-fim. Quais deles são constantes e quais são variáveis? Porque dividimos a arquitetura da Internet em camadas? Quais são as cinco camadas da pilha de protocolo da Internet? Quais as principais responsabilidades de cada uma dessas camadas? O que é uma mensagem de camada de aplicação? Um segmento da camada de transporte? Um datagrama da camada de rede? Um quadro de camada de enlace? Qual a relação entre eles? Que camadas da pilha de protocolo da Internet um roteador implementa? Que camadas um comutador de enlace implementa? Que camadas um sistema final implementa?

Lista de exercícios 2 - Camada de Aplicação

Relacione cinco aplicações da Internet não proprietárias e os protocolos da camada de aplicação que elas usam. Qual é a diferença entre arquitetura de rede e arquitetura de aplicação? De que modo um mensageiro instantâneo é um híbrido das arquiteturas cliente-servidor e P2P? Para uma sessão de comunicação entre um par de processos, qual processo é o cliente e qual é o servidor? Que informação é usada por um processo que está rodando em um hospedeiro para identificar um processo que está rodando em outro hospedeiro? Porque o HTTP, FTP, SMTP, POP3 e IMAP rodam sobre TCP e não sobre UDP? Qual é a diferença entre HTTP persistente com paralelismo e HTTP persistente sem paralelismo. Qual dos dois é utilizado pelo HTTP/1.1? Descreva como o cache Web pode reduzir o atraso na recepção de um objeto desejado. O cachê Web reduzirá o atraso para todos os objetos requisitados por um usuário ou somente para alguns objetos? Por quê? Porque o DNS não é centralizado? O que são consultas recursivas e interativas em uma consulta DNS? Por que se diz que o FTP envia informações de controle “fora da banda”? Suponha que Aline envie uma mensagem a Eduardo por meio de uma conta de e-mail da web (como o gmail), e que Eduardo acesse seu e-mail por seu servidor utilizando POP3. Descreva como a mensagem vai do hospedeiro Aline até o hospedeiro de Eduardo. Não se esqueça de relacionar a série de protocolos de camada de aplicação usados para movimentar as mensagens entre os hospedeiros. Em uma aplicação de compartilhamento de arquivos P2P, você concorda com a afirmação: ”não existe nenhuma noção de lados cliente e servidor de uma sessão de comunicação”? Por que sim ou por que não? Relacione alguns agentes de usuário de aplicação de rede que você utiliza no dia-a-dia. O que significa o protocolo de apresentação (handshaking protocol)? Considere um site de comércio eletrônico que quer manter um registro de compras para cada um de seus clientes. Descreva como isso pode ser feito com cookies. Imagine uma aplicação que requeira “não perda de dados” e seja também altamente sensível ao atraso.

Lista de exercícios 3 - Camada de Transporte

Considere uma conexão TCP entre o hospedeiro A e o hospedeiro B. Suponha que os segmentos TCP que trafegam do hospedeiro A para o hospedeiro B tenham número de porta fonte x e número de porta destino y. Quais são os números de porta fonte e do destino para os segmentos que trafegam do hospedeiro B para o hospedeiro A? Descreva porque um desenvolvedor de aplicação pode escolher rodar uma aplicação sobre UDP em vez de sobre TCP. É possível que uma aplicação desfrute de transferência confiável de dados mesmo quando roda sobre UDP? Caso a resposta seja afirmativa, como isso acontece? Porque se diz que o TCP oferece comunicação lógica entre os processos de aplicação? Cite quais são os serviços oferecidos pelo protocolo TCP? O que são os serviços de multiplexação e demultiplexação implementados pela camada de transporte? Porque se diz que o UDP é um protocolo não orientado para conexão? Qual o papel das informações de porta origem e destino contidas nos segmentos TCP e UDP? Porque é dito que o TCP fornece transferência confiável de dados sobre um canal não confiável? Cite 3 diferenças entre os serviços oferecidos pelo TCP e UDP. O que é um timeout? Como é estabelecido o valor de timeout em uma conexão TCP? É um valor fixo? O que é um round trip time (RTT)? Escreva e descreva a equação. Para que serve um checksum em um segmento TCP ou UDP? Como ele é formado? Cite uma vantagem da abordagem Volta-N com relação à retransmissão seletiva. Cite uma vantagem da abordagem Retransmissão Seletiva com relação ao Volta-N. Qual é a grande desvantagem de uma transmissão do tipo “para e espera” com relação a uma do tipo “janelas deslizantes”? O que é um PDU (também chamado de Segmento)? O TCP oferece garantias de banda e de tempo real? Cite um motivo para um protocolo de transmissão confiável adicionar um número de seqüência em cada pacote transmitido. Justifique o uso dessa informação explicando o problema que ocorreria caso ela não fosse usada. Para que serve um relógio temporizador em um protocolo de transmissão confiável? Cite um problema que pode ocorrer caso o tempo de um relógio temporizador seja muito pequeno. Cite um problema que pode ocorrer caso o tempo de um relógio temporizador seja muito grande. Por quê os tempos dos relógios temporizadores não são estabelecidos de forma estática, e sim de forma dinâmica, calculados conforme os round-trip times medidos? O que é uma reconhecimento cumulativo? Explique o que faz um receptor caso receba um pacote fora de ordem em um protocolo do tipo: Volta-N e Retransmissão Seletiva. O que é um “Tamanho de Janela” em um protocolo do tipo Janela Deslizante? O que se leva em consideração para calcular seu valor? Em um protocolo de janela deslizante qual é um problema que pode acontecer quando o maior número de Seqüência é muito próximo do “Tamanho de Janela”? Responda verdadeiro e falso as seguintes perguntas e justifique resumidamente sua resposta: Com o protocolo SR, é possível o remetente receber um ACK para um pacote que caia fora de sua janela corrente. Com o protocolo GBN, é possível o remetente receber um ACK para um pacote que caia fora de sua janela corrente. O protocolo bit alternante é o mesmo que o protocolo SR com janela do remetente e destinatário de tamanho 1. O protocolo bit alternante é o mesmo que o protocolo GBN com janela do remetente e destinatário de tamanho 1. Considere a transferência de um arquivo enorme de L bytes do hospedeiro A para o hospedeiro B. Suponha um MSS de 536 bytes. Qual é o máximo valor de L tal que não sejam esgotados os números de sequência TCP? Lembre-se de que o campo de número de sequência TCP tem 4 bytes. Para o L que obtiver no item anterior, descubra quanto tempo demora para transmitir o arquivo. Admita que um total de 66 bytes de cabeçalho de transporte, de rede e de enlace de dados seja adicionado a cada segmento antes que o pacote resultante seja enviado por um enlace de 155 Mbits/s. Ignore controle de fluxo e controle de congestionamento de modo que A possa enviar segementos um atrás do outro e continuamente. Considere um canal que pode perder pacotes, mas cujo atraso máximo é conhecido. Modifique o protocolo rdt2.1 (livro ou transparências) para incluir esgotamento de temporização do remetente e retransmissão. Informalmente, argumente por que seu protocolo pode se comunicar de modo correto por esse canal. Dadas as máquinas de estado, figuras abaixo, de um transmissor e um receptor de um protocolo "qualquer". Faça um descrição do funcionamento de ambos. Monte pelo menos dois diagramas de mensagens, destacando e relacionando possíveis sequências temporais com as máquinas de estado dadas. Transmissor Receptor O UDP e TCP usam o complemento de 1 para suas somas de verificação. Suponha que você tenha as seguintes três palavras de 8 bits: 01010011, 01100110 e 01110100. Qual é o complemento de 1 para a soma dessas palavras? Mostre todo o trabalho. Por que o UDP toma o complemento de 1 da soma, isto é, por que não toma apenas a soma? Com o esquema de complemento de 1, como o destinatário detecta erros? É possível que o erro de 1 bit passe desapercebido? E um de 2 bits? Considere a figura abaixo (Variação do tamanho da janela). Admitindo-se que o TCP Reno é o protocolo que experimenta o comportamento mostrado no gráfico, responda às seguintes perguntas. Em todos os casos você deverá apresentar uma justificativa resumida para sua resposta. Quais os intervalos de tempo em que a partida lenta do TCP está em execução? Quais os intervalos de tempo em que a prevenção de congestionamento do TCP está em execução? Após a 16a rodada de transmissão, a perda de segmento será detectada por três ACKs duplicados ou por um esgotamento de temporização? Após a 22a rodada de transmissão, a perda de segmento será detectada por três ACKs duplicados ou por um esgotamento de temporização? Qual é o valor inicial de sstrhresh na primeira rodada de transmissão? Qual é o valor inicial de sstrhresh na 18a rodada de transmissão? Qual é o valor inicial de sstrhresh na 24a rodada de transmissão? Durante qual rodada de transmissão é enviado o 70o segmento? Admitindo-se que uma perda de pacote será detectada após 26a rodada pelo recebimento de três ACKs duplicados, quais serão os valores do tamanho da janela de congestionamento e de sstrhresh? Suponha que o TCP Tahoe seja usado (em vez do TCP Reno) e que ACKs duplicados triplos sejam recebidos na 16a rodada. Quais são o sstrhresh e o tamanho da janela de congestionamento na 19a rodada? Suponha novamente que o TCP Tahoe seja usado, e que exista um evento de esgotamento de temporização na 22a sessão. Quantos pacotes foram enviados da 17a sessão até a 22a, inclusive? Variação do tamanho da janela

Lista de exercícios 4 - Camada de Rede

Qual é o nome de um pacote da camada de rede? Os roteadores e comutadores da camada de enlace são denominados comutadores de pacotes. Qual é a diferença fundamental entre um roteador e um comutador de camada de enlace? Lembre-se de que usamos o termo roteadores tanto para redes de datagramas quanto para redes de circuitos virtuais. Quais são as principais características de uma rede de circuito virtual? Quais são as principais características de uma rede de datagramas? Porque os projetistas da Internet adoram este modelo de serviço em sua implementação? Porque se diz que a Internet implementa um serviço de melhor esforço? Que tipo de garantias são oferecidas neste modelo de serviço? Quais as principais diferenças entre os serviços oferecidos pelas redes de datagramas (Internet) e redes ATM? Quais são as funções mais importantes da camada de rede em uma rede de datagramas? Quais são as três funções mais importantes de rede em uma rede de circuitos virtuais? O que é um protocolo de roteamento? Como podem ser classificados os algoritmos de roteamento? Roteadores possuem endereços IP? Quantos endereços IP um roteador possui? Qual é a diferença básica entre protocolos de roteamento “Estado de Enlaces” e “Vetor de Distância”? Em uma rede largamente dispersa, com centenas de roteadores, você recomendaria a adoção de um protocolo de roteamento do tipo “Estado de Enlaces” ou “Vetor de Distâncias”? Justifique. Explique o funcionamento de um algoritmo de roteamento do tipo “Vetor de Distâncias”. A Internet usa o conceito de “roteamento hierárquico”. O que significa isso? Um roteador em uma rede de pacotes (como é o caso da Internet) pode eventualmente necessitar descartar um datagrama. Por que isso ocorre? Um roteador em uma rede de pacotes (como é o caso da Internet) pode eventualmente necessitar fragmentar um datagrama. Por que isso ocorre? O que é um Sistema Autônomo (AS)? Para que serve o protocolo ICMP? Para que serve o campo “Time to Live” (sobrevida) em um datagrama IP? Por que são usados protocolos inter-AS e intra-AS diferentes na Internet? Por que considerações políticas/econômicas não são tão importantes para protocolos intra-AS, como OSPF e RIP, quanto par um protocolo de roteamento inter-AS, como BGP? Quantos hosts podem ser endereçados com um bloco IP 200.23.16.0/20? Como podemos montar 8 sub-redes a partir deste bloco de endereços IP? Um provedor de serviços ISP possui cerca de 2000 clientes cadastrados atualmente. Porém um levantamento realizado recentemente pelo administrador da rede constatou que nunca mais do que 450 clientes estão on-line ao mesmo tempo. Qual o bloco de endereços IP na forma CIDR (a.b.c.d/x) deve ser contratado pelo ISP, considerando o estudo realizado pelo administrador da rede? Um administrador precisa montar uma rede experimental conforme mostrada na figura. Na sub-rede 1 ele precisará instalar cerca 25 hosts, e nas sub-redes 2 e 3 ele precisará instalar cerca de 12 hosts. O administrador dispõe do bloco de endereços IP 192.168.10.0/24 para ser utilizado no endereçamento da rede experimental. Faça uma proposta para alocação de endereços IP para cada sub-rede (rede 1, 2 e 3), incluindo também as sub-redes relativas aos enlaces ponto-a-ponto (rede AB, AC e BC). Responda ainda: Qual o endereço identificador de rede de cada sub-rede (1, 2 e 3)? Qual o a máscara de rede de cada sub-rede (1, 2 e 3)? Quais os endereços IP que serão atribuídos a cada interface de rede nos enlaces ponto-a-ponto dos roteadores (enlaces relativos as redes AB, AC e BC) Suponha que um administrador de rede tenha recebido o bloco de endereços 200.40.8.0/21 e que deseja dividir este bloco em 8 blocos de endereços iguais, de menor tamanho, para ser alocado a 8 sub-redes administradas por ele. Determine o tamanho total do bloco de endereços. Determine o tamanho de cada sub-bloco. Determine o endereço/máscara de rede de cada sub-rede. Um provedor de acesso a Internet possui o seguinte bloco de endereços IP: 12.17.192.0/18. Os endereços IP de 12.17.192.1 até 12.17.207.255 já estão alocados para clientes deste provedor. Este provedor precisa atender a quatro novos clientes, um deles necessita de rede com pelo menos 1000 endereços de IP válidos e os outros três necessitam de rede com pelo menos 30 IP válidos. Faça uma proposta para alocação de endereços IP para estes clientes. Os endereços reservados para estes novos clientes devem ser alocados a partir da numeração mais baixa disponível. Procure também responder as questões abaixo: Qual o total de endereços que dispõe o provedor em questão? Quantos endereços IP já estão utilizados? Quantos endereços IP este provedor possui livres para alocar aos novos clientes? Qual o endereço identificador de cada sub-rede dos novos clientes? Qual o a máscara de rede de cada sub-rede dos novos clientes? Qual o endereço de broadcast de cada sub-rede dos novos clientes? Quantos endereços IP ainda sobrarão ao provedor após atender a estes clientes? Quantas estações uma rede 223.1.10.0/24 suporta? Uma rede com bloco de IPs 200.23.16.0/20 deseja montar 8 subredes. Mostre como isso é possível e como ficaria os endereços de cada uma dessas subredes. Um datagrama de 4000 bytes precisa ser fragmentado para passar por um roteador cujo enlace tem MTU de 1500 bytes. Mostre esquematicamente como ficam os datagramas que são gerados a partir dessa fragmentação. Considere enviar um datagrama de 2400 bytes por um enlace que tenha uma MTU de 700 bytes. Suponha que o datagrama original esteja marcado com o número de identificação 422. Quantos fragmentos são gerados? Quais são os valores em vários campos dos datagramas IPs gerados em relação à fragmentação? Um datagrama enviado para uma estação da mesma rede precisa passar por um roteador? Suponha que entre o hospedeiro de origem A e o hospedeiro de destino B os datagramas estejam limitados a 1500 bytes (incluindo cabeçalho). Admitindo um cabeçalho IP de 20 bytes, quantos datagramas seriam necessários para enviar um arquivo MP3 de 5 milhões de bytes? Explique como você obteve a resposta. Qual é a diferença básica de um endereço IP baseado em classes cheias (classful) e um sem classes (classles – CIDR)? Descreva e detalhe o processo de obtenção de um endereço IP através do protocolo DHCP. Descreva e detalhe o processo de tradução de endereços de rede - NAT. Com o NAT é possível somente a conversão (troca) do número de portas? Explique. Compare os campos de cabeçalho do IPv4 e do IPv6e aponte suas diferenças. Eles tem algum campo em comum? Afirma-se que, quando o IPv6 implementa túneis via roteamento IPv4, o IPv6 trata os túneis IPv4 como protocolo de camada de enlace. Você concorda com essa afirmação? Explique sua resposta. Cite as diferenças entre a execução da abstração de difusão por meio de múltiplas transmissões individuais e a de uma única difusão com suporte da rede (roteador). Considere uma rede de datagramas que utiliza endereços de hospedeiros de 8 bits. Suponha que um roteador utilize a correspondência do prefixo mais longo e tenha a seguinte tabela de repasse: Prefixo a comparar Interface 1 0 10 1 111 2 senão 3 Para cada uma das quatro interfaces, forneça a faixa associada de endereços de hospedeiro de destino e o número de endereços na faixa.

Lista de exercícios 5 - Camada de Enlace

Quais são os serviços providos pela camada de enlace? Dentre os serviços de camada de enlace, quais obrigatoriamente precisam ser implementados por todos os protocolos de enlace? Porque é necessário sincronizar quadros (serviço de enquadramento)? Por que se faz necessário um protocolo de acesso ao meio (MAC), em redes com meio de transmissão compartilhado? Do ponto de vista do protocolo MAC CSMA/CD, qual a principal diferença entre hubs e switches? 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? 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. 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? Compare as estruturas de quadros das redes Ethernet 10BaseT, 100BaseT e Gigabit Ethernet. Quais diferenças entre elas? Dois adaptadores, um com taxa nominal de 10001 bps e outro com taxa nominal de 9999 bps, estão conectados via par trançado, como eles conseguem trocar dados normalmente? Você comprou um notebook novo. Vai utilizar pela primeira vez no Câmpus São José do IFSC. Com um cabo de rede conectou seu computador à rede do IFSC e digitou no navegador de seu computador: www.polito.it. Cite todos os protocolos utilizados e todas a etapas cumpridas por seu computador, para que essa operação tenha exito.

Transparências utilizadas durante as aulas

Slides do Kurose referentes ao capítulo 1

Slides do Kurose referentes ao capítulo 2

Slides do Prof. Emerson - DNS, FTP, Web, Email...

Slides do Kurose referentes ao capítulo 7

Slides do Kurose referentes ao capítulo 3

Slides do Kurose referentes ao capítulo 4

Slides do Kurose referentes ao capítulo 5

Roteiros para laboratório

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. Figura 1 - Diagrama da rede do laboratório Máquinas virtuais 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. A rede local do laboratório tem endereço IP 192.168.?.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, 192.168.?.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.?.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.?.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 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 Ethernet 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 a validade dos mesmos? 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, 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: 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: www.ifsc.br www.folha.com.br www.nytimes.com www.polito.it </syntaxhighlight> e explique as possíveis diferenças entre os tempos de resposta dos ping realizados. 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. Para testar, vamos habilitar a resposta a um ping no endereço de broadcast em uma máquina virtual Ubuntu. Para tal, primeiro iniciamos uma máquina virtual, logamos como aluno/aluno e depois executamos em um terminal os comandos abaixo 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 Somente o usuário root pode executar o aplicativo traceroute. Caso o aplicativo não esteja instalado, instalar no Linux Ubuntu de uma máquina virtual, como root, com o comando: apt-get update apt-get install traceroute </syntaxhighlight> 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: 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 II (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 possíveis diferenças entre os tempos de resposta de cada uma das amostras do traceroute 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 1 é 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 1, 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. 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 1. 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. 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); 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; 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 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. Anote o filtro utilizado e salve a janela do mesmo. Liste 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?

Laboratório 2 - Desvendando o HTTP com Wireshark

Fonte base: 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. Neste laboratório, exploraremos 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 autenticação 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 (mas não inicie a captura de pacotes ainda). Digite “http.request or http.response” (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); inicie a captura de pacotes digite o seguinte URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004.html pare a captura de pacotes. 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, 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. 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 linguagens (se alguma) o seu navegador indica que pode aceitar ao servidor? Qual o endereço IP do seu computador? E do servidor www.sj.ifsc.edu.br? Qual o número da porta utilizada no seu computador? E do servidor www.sj.ifsc.edu.br? Qual o endereço MAC do seu computador? E do servidor de destino (Dst)? Nesse caso o servidor de destino e o servidor www.sj.ifsc.edu.br são o mesmo host? 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? Qual a diferença entre os endereços (IP, porta, MAC) de origem e destino entre a mensagem GET e a de resposta do HTTP? 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. Outra maneira de forçar o download do objeto quando desejado, é utilizar as teclas de atalho Ctrl + Shift + R no Firefox; inicie o Wireshark; digite o URL no navegador http://www.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 www.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 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://www.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 9 "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://www.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. A imagem da esquerda, redesWL_network.jpeg, está em ibxk.com.br. A imagem da direita, as-redes-sociais-como-instrumento-de-manipulacao-da-consciencia-coletiva.html.jpg, está em lounge.obviousmag.org; 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? Para quais endereços na Internet estas mensagens foram enviadas? Você consegue dizer se o seu navegador baixou as duas imagens em seqüência, ou se foram baixadas dos dois locais distintos em paralelo? Explique. Autenticação HTTP Finalmente, vamos tentar visitar um local na web que é protegido por senha e examinar a seqüência de mensagens HTTP trocadas com este local. O URL http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ é protegido por senha. O usuário é “red29004” (sem as aspas), e a senha é “seguro” (novamente, sem as aspas). Então vamos acessar o local protegido por senha. Faça o seguinte: inicie o navegador web; limpe o cache do seu navegador; inicie o Wireshark; digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ seu navegador apresentará um pop up solicitando usuário e senha; forneça usuário e senha e o navegador apresentará uma "linda" página já conhecida; 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. Agora vamos examinar a saída do Wireshark. Você pode querer primeiro ler sobre a autenticação HTTP revisando o material fácil de ler (em inglês) HTTP Access Authentication Framework Responda às seguintes questões: Qual é a resposta do servidor (código de status e frase) para a primeiro mensagem HTTP GET do seu navegador? Quando o seu navegador envia a mensagem HTTP GET pela segunda vez, qual o novo campo que está incluído na mensagem? O nome de usuário (red29004) e a senha (seguro) que você digitou foram codificados na cadeia de caracteres (cmVkMjkwMDQ6c2VndXJv) após o cabeçalho “Authorization: Basic” na mensagem HTTP GET (primeira). Parece que o nome e senha estão criptografados, mas na verdade estão simplesmente codificados em um formato denominado Base64. O nome do usuário e a senha não estão criptografados! Para ver isso, vá para https://www.base64decode.org/ e digite o texto cmVkMjkwMDQ6c2VndXJv e pressione DECODE. Voilá! Você traduziu de Base64 para ASCII, e desta forma consegue ver o nome de usuário e a senha! Sabendo que alguém pode baixar o Wireshark e capturar pacotes (não somente os próprios), e alguém pode traduzir de Base64 para ASCII (você acabou de fazê-lo!), deve estar claro para você que o uso de senhas apenas em locais na web não garantem segurança, a não ser que medidas adicionais sejam tomadas. Não tema! Há meios de fazer o acesso WWW ser mais seguro. Contudo, nós claramente precisamos de algo que vá além do framework básico de autenticação HTTP! 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 URL no navegador https://www.base64decode.org/ seu navegador apresentará um site já apresentado/utilizado; 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?

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 de mais perto: inicialmente o lado cliente do DNS, uma pequena análise do protocolo e uma breve introdução ao servidor DNS. 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. Consultas DNS por meio de ferramentas especializadas Usando o programa host, Nslookup ou dig, descubra os endereços IP associados aos seguintes nomes de hosts (máquinas): mail.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra 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: host -t ns ifsc.edu.br dig -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Num terminal digite: 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 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: host -t mx ifsc.edu.br dig -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com ufsc.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: dig -x 200.180.10.13 ... 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: dig -x 200.180.10.13 +short </syntaxhighlight> Como explicado durante a aula, 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? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . dig -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... 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: host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight> Quantos servidores DNS foram necessários consultar no total? Repita esse exercício para os seguintes nomes de hosts: www.bbc.co.uk www.reeec.illinois.edu www.inm.ras.ru Consultando um servidor explícito(@) dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. Faça uma consulta recursiva com dig e responda: dig +trace mail.ru. Qual foi o RLD consultado? Qual o TLD consultado? Qual o SLD consultado? Como você sabe que foram esses os LDs consultados? 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 digite “dns” no filtro (sem as aspas); inicie a captura de pacotes no Wireshark; no navegador web, visite a página http://canon.jp/ (isso vai provocar a consulta DNS); pare a captura de pacotes. 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? Do lado de lá do balcão: servidor de nomes DNS (Domain Name System) é uma base de dados distribuída e hierárquica. Nela se armazenam informações para mapear nomes de máquinas da Internet para endereços IP e vice-versa, informação para roteamento de email, e outros dados utilizados por aplicações da Internet. A informação armazenada no DNS é identificada por nomes de domínio que são organizados em uma árvore, de acordo com as divisões administrativas ou organizacionais. Cada nodo dessa árvore, chamado de domínio, possui um rótulo. O nome de domínio de um nodo é a concatenação de todos os rótulos no caminho do nodo até a raiz. Isto é representado como uma string de rótulos listados da direita pra esquerda e separados por pontos (ex: ifsc.edu.br, sj.ifsc.edu.br). Um rótulo precisa ser único somente dentro do domínio pai a que pertence. Por exemplo, um nome de domínio de uma máquina no IFSC pode ser mail.ifsc.edu.br., em que o "." (último) significa o root level domain .br é o domínio do topo da hierarquia (no Brasil feito em [1]) ao qual mail.sj.ifsc.edu.br pertence. .ifsc.edu é um subdomínio de .br., e mail o nome da máquina em questão. Por razões administrativas, o espaço de nomes é dividido em áreas chamadas de zonas, cada uma iniciando em um nodo e se estendendo para baixo para os nodos folhas ou nodos onde outras zonas iniciam. Os dados de cada zona são guardados em um servidor de nomes, que responde a consultas sobre uma zona usando o protocolo DNS. Clientes buscam informação no DNS usando uma biblioteca de resolução (resolver library), que envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Roteiro de atividades Como não temos condições de criar registros em registro.br, para testarmos algumas funcionalidades de um servidor DNS, vamos montar uma estrutura parcial, válida somente dentro do laboratório, onde poderemos fazer algumas configurações básicas e testá-las. O objetivo é montar a seguinte estrutura que é composta por um ramo (professor) e algumas folhas (alunos) de uma árvore DNS, ver Fig. 1. Fig.1 -- Ramo DNS para testes. Vamos configurar e testar um servidor DNS. Para tanto montaremos a estrutura indicada no diagrama, onde cada máquina será um servidor DNS, com um domínio próprio e, ao mesmo tempo, será cliente do servidor DNS da máquina 192.168.1.101. Esta, por sua vez, será servidor master do domínio r1.br e servidor escravo dos domínios criados por vocês, recebendo automaticamente uma cópia das zonas desses servidores masters. Esta, será também a única máquina com servidor DNS com zona reversa. Sendo assim todos os domínios, diretos e reversos, serão visíveis por meio deste servidor. Como, apesar de serem servidores DNS, todas as máquinas, enquanto clientes, utilizam a máquina do professor para resolver nomes, todos se enxergarão mutuamente. Procedimento: Abra o VirtualBox e inicie a máquina RES-grafico. Logue como aluno/aluno. Abra um terminal e tome permissões de root: sudo su / aluno. Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> Y = 02, D3 ==> Y = 03, ..., D9 ==> Y = 09, E1 ==> Y = 11, E2 ==> Y = 12, ..., E8 ==> Y = 18: apt-get remove isc-dhcp-client ifconfig eth0 192.168.1.1Y route add -net default gw 192.168.1.1 gedit /etc/resolv.conf (acrescente ao final do arquivo, deve ser a única linha descomentada) nameserver 192.168.1.101 </syntaxhighlight> Se ocorrer erro ao configurar a eth0 tente com eth1, eth2... Acesse a Wiki com o navegador de sua máquina virtual. Isso permitirá você copiar e colar os textos/comandos abaixo. Atualize a base de pacotes e instale o pacote Bind: apt-get update apt-get install bind9 </syntaxhighlight> Edite o arquivo de definição local, gedit /etc/bind/named.conf.local, e acrescente ao final do arquivo (pode deixar os comentários iniciais já existentes) o seguinte conteúdo, não deixando espaço em branco antes da primeira e última linha (XX é igual a etiqueta de sua máquina, D2, D3, ..., E1, E8): zone "XX.br" { type master; file "/etc/bind/db.XX"; allow-transfer { 192.168.1.101; }; };</syntaxhighlight> Edite/crie o arquivo de zona, gedit /etc/bind/db.XX, e deixe-o do seguinte modo $TTL 86400 @ IN SOA ns.XX.br. admin.XX.br. ( 2015032400; serial 3H ; refresh 60 ; retry 1W ; expire 3W ; minimum ) @ IN NS ns.XX.br. ; este é o servidor master deste domínio @ IN MX 10 mail.XX.br. $ORIGIN XX.br. ns A 192.168.1.1Y www CNAME ns mail A 192.168.1.1Y </syntaxhighlight> Utilize a ferramenta para teste de validade do arquivo de definição de zona: named-checkzone XX.br /etc/bind/db.XX. Caso apresente erros corrija-os. Utilize a ferramenta testar as configuração do BIND: named-checkconf -z. Caso apresente erros corrija-os. Reinicie o serviço: service bind9 restart. Verifique ainda possíveis erros: tail -n 30 /var/log/syslog </syntaxhighlight> Caso tudo esteja certo avise ao professor para atualizar as cópias dos arquivos de zona. Faça a seguinte sequência de testes: ping www.XX.br ping mail.XX.br dig @localhost mail.XX.br dig @192.168.1.101 nome_de_maquina_de_algum_colega dig XX.br ANY Teste o DNS reverso com o IP de sua máquina e de seus colegas, usando a ferramenta “dig”: dig -x 192.168.1.1Y Vamos acrescentar mais um IP e um nome de máquina em nosso servidor: ifconfig eth0:0 192.168.1.2Y </syntaxhighlight> ou eth1:0, eth2:0 ... Acrescente ao final do arquivo /etc/bind/db.XX a declaração do novo componente em nossa tabela de nomes. Obrigatoriamente o valor do serial deve ser incrementado de pelo menos 1 unidade. seu_nome_de_batismo A 192.168.1.2Y</syntaxhighlight> Reinicie o BIND e avise ao professor para atualizar a cópia. Faça testes: ping seu_nome_de_batismo.XX.br ping nome_do_seu_colega.XX.br ;aqui o XX é do seu colega. </syntaxhighlight> Questões para o relatório: Explique cada uma das linhas do arquivo /etc/bind/db.XX. Explique a seção allow-transfer { 192.168.1.101; }; do arquivo /etc/bind/named.conf.local. Compare o seu arquivo /etc/bind/named.conf.local com o do professor (abaixo). Compare os arquivos /etc/bind/db.r1 com /etc/bind/db.db.1.168.192, abaixo. Arquivos e procedimentos na máquina Professor, somente para exemplificar apt-get update apt-get install bind9 mkdir /var/cache/bind/slaves chown bind:bind /var/cache/bind/slaves /etc/bind/named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "r1.br" { type master; file "/etc/bind/db.r1"; }; zone "1.168.192.in-addr.arpa" IN { type master; file "/etc/bind/db.1.168.192"; }; zone "D2.br" IN { type slave; file "/var/cache/bind/slaves/db.D2"; masters { 192.168.1.102; }; }; zone "D3.br" IN { type slave; file "/var/cache/bind/slaves/db.D3"; masters { 192.168.1.103; }; }; zone "D4.br" IN { type slave; file "/var/cache/bind/slaves/db.D4"; masters { 192.168.1.104; }; }; zone "D5.br" IN { type slave; file "/var/cache/bind/slaves/db.D5"; masters { 192.168.1.105; }; }; zone "D6.br" IN { type slave; file "/var/cache/bind/slaves/db.D6"; masters { 192.168.1.106; }; }; zone "D7.br" IN { type slave; file "/var/cache/bind/slaves/db.D7"; masters { 192.168.1.107; }; }; zone "D8.br" IN { type slave; file "/var/cache/bind/slaves/db.D8"; masters { 192.168.1.108; }; }; zone "D9.br" IN { type slave; file "/var/cache/bind/slaves/db.D9"; masters { 192.168.1.109; }; }; zone "E1.br" IN { type slave; file "/var/cache/bind/slaves/db.E1"; masters { 192.168.1.111; }; }; zone "E2.br" IN { type slave; file "/var/cache/bind/slaves/db.E2"; masters { 192.168.1.112; }; }; zone "E3.br" IN { type slave; file "/var/cache/bind/slaves/db.E3"; masters { 192.168.1.113; }; }; zone "E4.br" IN { type slave; file "/var/cache/bind/slaves/db.E4"; masters { 192.168.1.114; }; }; zone "E5.br" IN { type slave; file "/var/cache/bind/slaves/db.E5"; masters { 192.168.1.115; }; }; zone "E6.br" IN { type slave; file "/var/cache/bind/slaves/db.E6"; masters { 192.168.1.116; }; }; zone "E7.br" IN { type slave; file "/var/cache/bind/slaves/db.E7"; masters { 192.168.1.117; }; }; zone "E8.br" IN { type slave; file "/var/cache/bind/slaves/db.E8"; masters { 192.168.1.118; }; }; </syntaxhighlight> /etc/bind/db.r1 BIND reverse data file for empty rfc1918 zone DO NOT EDIT THIS FILE - it is used for multiple zones. Instead, copy it, edit named.conf, and use that copy. $TTL 86400 @ IN SOA m1.r1.br. admin.r1.br ( 2015032400 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL @ IN NS ns.r1.br. @ IN MX 10 mail.r1.br. $ORIGIN r1.br. ns A 192.168.1.101 www CNAME ns mail CNAME ns </syntaxhighlight> /etc/bind/db.1.168.192 (Zona reversa) $TTL 86400 @ IN SOA m1.X1.br. root ( 2015032400 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL IN NS mail.r1.br. 101 IN PTR mail.r1.br. 102 IN PTR mail.D2.br. 103 IN PTR mail.D3.br. 104 IN PTR mail.D4.br. 105 IN PTR mail.D5.br. 106 IN PTR mail.D6.br. 107 IN PTR mail.D7.br. 108 IN PTR mail.D8.br. 109 IN PTR mail.D9.br. 111 IN PTR mail.E1.br. 112 IN PTR mail.E2.br. 113 IN PTR mail.E3.br. 114 IN PTR mail.E4.br. 115 IN PTR mail.E5.br. 116 IN PTR mail.E6.br. 117 IN PTR mail.E7.br. 118 IN PTR mail.E8.br. </syntaxhighlight>

Laboratório 4 - Entendendo sockets

Objetivos Entender o conceito de sockets. 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. 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 aqui. 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. Um exemplo de código bem simples para o lado Cliente: UDPClient.py 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 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> O código do lado do Servidor (comentários somente nas linhas inéditas): UDPServer.py from socket import * serverPort = 22222 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 contatos por clientes while 1: message, clientAddress = serverSocket.recvfrom(2048) #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas. modifiedMessage = message.upper() serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight> Para testar se o servidor está com a "porta aberta" podemos utilizar o aplicativo nmap, que procura por portas abertas. Como exemplo vamos verificar somente se a porta 22222 UDP (-sU) está aberta: sudo nmap -p22222 -sU numero_do_ip_do_servidor 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: A aplicação cliente-servidor usando TCP: Um exemplo de código bem simples para o lado Cliente (comentários somente nas linhas inéditas): TCPClient.py 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> O código do lado do Servidor (comentários somente nas linhas inéditas): TCPServer.py 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) messageMaiuscula = message.upper() connectionSocket.send(messageMaiuscula) connectionSocket.close() </syntaxhighlight> Teste do servidor: nmap -sT -p33333 ip_do_servidor Roteiro de atividades Ligue a máquina virtual determinada pelo professor Logue com: aluno - aluno Configure sua interface de rede com IP estático, removendo o cliente dhcp. Y é obtido pelo número da etiqueta de sua máquina: D2 ==> Y = 02, D3 ==> Y = 03, ..., D9 ==> Y = 09, E1 ==> Y = 11, E2 ==> Y = 12, ..., E8 ==> Y = 18: apt-get remove isc-dhcp-client ifconfig eth0 192.168.1.1Y route add -net default gw 192.168.1.1 gedit /etc/resolv.conf (acrescente ao final do arquivo, deve ser a única linha descomentada) nameserver 200.135.37.65 </syntaxhighlight> Escreva o programa UDPServer.py nessa máquina e execute-o: python UDPServer.py </syntaxhighlight> Se apresentar erros de sintaxe corrija-os Teste com o nmap para verificar se a porta está aberta. Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. Sucesso na execução do programa? Rode o WireShark. Execute novamente o cliente e servidor e capture os pacotes com o WireShark. Use um filtro do tipo: ip.addr == ip_do_servidor, assim captura-se somente os pacotes originados/destinados ao servidor. É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? Repita os passos 4 a 10, só que agora para o protocolo TCP. Discuta as diferenças observadas entre os protocolos UDP e TCP. Com seu cliente conecte o servidor UDP e TCP de seu colega e vice-versa. Capture com o WireShark a mensagens trocadas. Alguma diferença? Quais? 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.

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 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: wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/ubuntu.iso Observe o tamanho do arquivo transferido ... ele deve ter exatamente 1028653056 bytes (cerca de 981 MB). Você pode fazer isso com o comando ls -l ubuntu.iso, 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. A primeira transferência será feita usando o protocolo TCP da seguinte forma: No computador receptor execute o netcat (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: nc -vvnl 5555 > arquivoTCP No computador transmissor execute: time nc -vvn ip_do_receptor 5555 < ubuntu.iso Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? A segunda transferência será feita usando o protocolo UDP: 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: wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/receptor chmod +x receptor ./receptor 5555 > arquivoUDP 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: wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor chmod +x transmissor ./transmissor ip_do_receptor 5555 < ubuntu.iso Quando completar a transferência, no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo? Compare as transferências feitas com 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 Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo 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: wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.iso 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? Finalmente, o professor irá repetir a transferência porém com três alunos fazendo-a ao mesmo tempo. Que se pode concluir quanto a taxa de transferência obtida? 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: watch -n 1 ls -l arquivo ... e no terminal 2: ./receptor 5555 > arquivo Fique observando o terminal 1. O professor irá transmitir o arquivo a partir do servidor remoto, um processo para cada aluno. No terminal 1 observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos (relógio, celular ou relógio do computador), o tamanho e quando o tamanho do arquivo parou de crescer. Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? E esse tamanho final é o mesmo do arquivo original? Como se comportaram as transferências usando TCP e UDP? Experimento 3 Repita os passos 1 e 3 do experimento 2 (anterior) mas agora com o arquivo minimo.txt, anotando todos os tempos. Os resultados foram os esperados? Discuta sobre as possíveis diferenças de comportamento. 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?

Laboratórios 6 e 7 - Protocolos de roteamento

Objetivos Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. Para atingir tais objetivos utilizaremos o Netkit2. Leia o tutorial de como o Netkit2 trabalha com roteadores. Em todos os experimentos será utilizado como base a seguinte arquitetura de rede: Experimento 1: tabelas estáticas de roteamento Tempo aproximado para execução e conferência: 1 h Crie em seu computador um arquivo com nome /home/aluno/exp1.conf, com o seguinte conteúdo: # 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: 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: ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? Teste a conectividade do pc1 executando o comando: ping 10.0.0.1 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê? Por exemplo, no pc1 execute o comando: 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: route add -net default gw 192.168.0.254 </syntaxhighlight> Teste novamente a conectividade, no pc1 execute o comando: ping 10.0.0.1 </syntaxhighlight> e 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). Qual a origem e destino dos pacotes? Por quê? Qual a diferença no ping entre os dois itens? Iniciando o roteamento Deixe o ping do item 5.3 e o wireshark do item 5.6 rodando e estabeleça uma rota no roteador r2 com o comando: 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ê? Em todos os roteadores crie rotas para todas as redes. Se tudo estiver correto, todos os PCs devem pingar entre si. Teste! Testando a queda de enalce. 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: 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? O Pacote Quagga -- Breve introdução O pacote 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. 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 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 e releia o arquivo de configuração exp1.conf. Repita o item 5.4 do Experimento 1. 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 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. 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 Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos. O nome destes arquivos deve ser ripd.conf e o conteúdo deve ser o abaixo. router rip redistribute connected redistribute static network eth1 network eth2 No pc1 execute: 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). service quagga start </syntaxhighlight> Execute o Quagga e o RIP a partir dos arquivos criados. Os arquivos que estão na pasta "/home/USUARIO/lab" são montados na pasta "/homelab/" 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. zebra -d -f /hostlab/r1/zebra.conf ripd -d -f /hostlab/r1/ripd.conf 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: vtysh </syntaxhighlight> Verifique o estado das interfaces usando o comando: show interface </syntaxhighlight> Verifique se o roteador está habilitado para roteamento: show ip forwarding </syntaxhighlight> Verifique o estado da tabela de roteamento usando o comando: 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: show run </syntaxhighlight> Sair do vtysh: 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 o WireShark (ou tcpdump -n -vvv -i any) no r1 por pelo menos 1 min e tente compreender as mensagens RIPv2 (UDP 17) trocadas. Olhe com atenção os IPs e as métricas apresentadas. O que dizem essas mensagens? Com o WireShark rodando em r1, desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens. Por questões de compatibilidade vamos desativar uma interface de um modo especial. Por exemplo, para "derrubar" o enlace r1-r2, execute no r1: vtysh 2061 entra no zebrad conf t entra no mode de configuração interface eth1 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, a recuperação das rotas leva em torno de 1 min. Quais as mensagens trocadas no WireShark? Teste as conectividades. O que aconteceu? Retrace as rotas com show ip route nos roteadores e com o traceroute a partir dos PCs. São diferentes do caso original (todos enlaces ativos)? 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: 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. #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 Os arquivos zebra.conf são os mesmos utilizados no experimento 2. Inicie o daemon quagga em todos os roteadores (r1, r2 e r3). service quagga start </syntaxhighlight> Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/USUARIO/lab" são montados na pasta "/homelab/" 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. zebra -d -f /hostlab/r1/zebra.conf ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight> Quais as conclusões? 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ê?

Laboratório 8 - IPv6

Este roteiro foi baseado no material disponível em [2]. Slides de endereçamento IPv6. Guia didático de endereçamento IPv6 obtido de http://ipv6.br/. Introdução teórica Obs.: texto copiado literalmente de: 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. Objetivos do laboratório: Um primeiro contato com o protocolo IPv6 Compreender o funcionando do Neighbor Discovery Aprender configurações básicas de interfaces IPv6 no Linux Aprender configurações básicas de rotas IPv6 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. Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo: 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: 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: 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: ip addr show dev eth0 </syntaxhighlight> Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede. Faça um ping6 entre o pc3 ao pc4. Por exemplo do pc3 ao pc4: ping6 2001:bcc:1f0:1::104 </syntaxhighlight> Obteve sucesso? Sim ou não e 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: 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. 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: 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: 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> Use os comandos traceroute6 numero_ipv6_pcX a partir do computador pc1 sobre o IP de global unicast dos computadores pc3 e pc4. 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? Em cada um dos computadores 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 no 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. Verifique as diferenças dos cabeçalhos de um pacote IPv4 e de um pacote Ipv6, comparando capturas do wireshark. A partir das capturas obtidas, explique o processo de descoberta de vizinhança (neighbor discovery / request e reply), citando os endereços de multicast e link local utilizados. Explique a tabela de roteamento do r1, em especial os endereços de link local. Porque não há confusão dos prefixos? Explique também o uso dos prefixos diferentes para os pc1 e pc2. Por que não foi utilizado o mesmo prefixo? É 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. Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.

Softwares

• Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux.
• CORE Network Emulator
• Vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.

Curiosidades

• Monitoramento do tráfego RNP - PoP-SC Monitoramento do tráfego RNP - Nacional
• Animated map shows the undersea cables that power the internet
• Submarine Cable Map 2015
• Redes WiFi no mundo
• History of the Internet
• History of the Internet - legendado
• Warriors of the Net
• Warriors of the Net - legendado
• Browser Wars
• Browser Wars - legendado
• Browser Wars - dublado
• IPv6 no Brasil
• Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6
• HTTP/2 Frequently Asked Questions

Seminários

• Objetivos:
  • Aprofundamento teórico em algum tema atual e relevante
  • Confecção de um relatório de trabalho no estilo científico
  • Apresentação de um trabalho científico

Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse modelo de relatório.

• Grupos e Temas para 2015-2:

1. Mateus Araujo e Paula Grando: iPv6, sua necessidade, implementação e facilidades.
2. Adonis, Daniel e Pedro: FTTX aplicado através da tecnologia GPON.

• Ordem de apresentação dos seminários

• Avaliação
  • Nota: 0,5 x Documento + 0,5 x Seminário
  • Critérios de avaliação

• Instruções sobre o Seminário de Redes I:
  • Data para definição de grupos e temas: 17/11/15.
  • 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.
  • Data de entrega do documento: 13/02/16 (impreterivelmente).
  • O relatório pode ser redigido como uma página da wiki.
  • Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas.
  • As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
  • Se preferirem usar slides, usem esse modelo.

Diário de aulas

Aula 1 - 6/10/15: Apresentação da disciplina

Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. Auto apresentação Apresentação da Wiki Plano de Ensino, Ementa, Estratégia de Ensino e Bibliografia 3 avaliações (P1, P2 e P3) mais um Seminário de tema livre (S) Cada uma das avaliações terá terá um conceito: A, B, C e D. Conceito mínimo final para não necessitar reavaliação: C. Reavaliação única no último dia de aula. Relação com outras disciplinas do curso Apresentação do Seminário Definição datas assim que o calendário estiver divulgado Definição de temas é livre, pensem sobre o assunto. Qual o grande objetivo das redes de computadores? Introdução às redes de computadores