Mudanças entre as edições de "RED29004-2015-1"
Linha 490: | Linha 490: | ||
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.199. Esta, por sua vez, será servidor: um servidor master do domínio R1.br e servidor escravo, recebendo automaticamente uma cópia das zonas dos servidores masters, de todos os demais domínios criados. 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. | 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.199. Esta, por sua vez, será servidor: um servidor master do domínio R1.br e servidor escravo, recebendo automaticamente uma cópia das zonas dos servidores masters, de todos os demais domínios criados. 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. | ||
− | #Abra o VirtualBox e inicie a máquina | + | #Abra o VirtualBox e inicie a máquina '''RES-grafico'''. |
#Logue como '''aluno/aluno'''. | #Logue como '''aluno/aluno'''. | ||
#Abra um terminal e tome permissões de root: '''sudo su / aluno'''. | #Abra um terminal e tome permissões de root: '''sudo su / aluno'''. | ||
− | #Configure sua interface de rede: <code> | + | #Configure sua interface de rede. 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''': <code> |
− | ifconfig eth0 192.168.1. | + | ifconfig eth0 192.168.1.1Y |
route add -net default gw 192.168.1.1 | route add -net default gw 192.168.1.1 | ||
gedit /etc/resolv.conf (acrescente ao final do arquivo) | gedit /etc/resolv.conf (acrescente ao final do arquivo) | ||
− | nameserver 192.168.1. | + | nameserver 192.168.1.101 </syntaxhighlight> |
#Atualize a base de pacotes e instale o pacote Bind: <code> | #Atualize a base de pacotes e instale o pacote Bind: <code> | ||
apt-get update | apt-get update | ||
apt-get install bind9 </syntaxhighlight> | 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):<code> | + | #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'''):<code> |
zone "XX.br" { | zone "XX.br" { | ||
type master; | type master; | ||
file "/etc/bind/db.XX"; | file "/etc/bind/db.XX"; | ||
allow-transfer { | allow-transfer { | ||
− | 192.168.1. | + | 192.168.1.101; |
}; | }; | ||
};</syntaxhighlight> | };</syntaxhighlight> | ||
Linha 521: | Linha 521: | ||
@ IN MX 10 mail.XX.br. | @ IN MX 10 mail.XX.br. | ||
$ORIGIN XX.br. | $ORIGIN XX.br. | ||
− | mail A 192.168. | + | mail A 192.168.1.1Y |
− | www CNAME 192.168. | + | www CNAME 192.168.1.1Y |
− | ns CNAME 192.168. | + | ns CNAME 192.168.1.1Y |
</syntaxhighlight> | </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 para teste de validade do arquivo de definição de zona: named-checkzone XX.br /etc/bind/db.XX. Caso apresente erros corrija-os. | ||
Linha 534: | Linha 534: | ||
ping mail.XX.br | ping mail.XX.br | ||
dig @localhost mail.XX.br | dig @localhost mail.XX.br | ||
− | dig @192.168. | + | dig @192.168.1.101 nome_de_maquina_de_algum_colega |
dig XX.br ANY | dig XX.br ANY | ||
</syntaxhighlight> | </syntaxhighlight> | ||
#Teste o DNS reverso com o IP de sua máquina e de seus colegas, usando a ferramenta “dig”: <syntaxhighlight lang=bash> | #Teste o DNS reverso com o IP de sua máquina e de seus colegas, usando a ferramenta “dig”: <syntaxhighlight lang=bash> | ||
− | dig -x 192.168.1. | + | dig -x 192.168.1.1Y |
</syntaxhighlight> | </syntaxhighlight> | ||
#Vamos acrescentar mais um IP e um nome de máquina em nosso servidor:<code> | #Vamos acrescentar mais um IP e um nome de máquina em nosso servidor:<code> | ||
− | ifconfig eth0:0 192.168.1. | + | ifconfig eth0:0 192.168.1.2Y </syntaxhighlight> |
#Acrescente ao final do arquivo '''/etc/bind/db.XX''' a declaração do novo componente em nossa tabela de nomes: <code> | #Acrescente ao final do arquivo '''/etc/bind/db.XX''' a declaração do novo componente em nossa tabela de nomes: <code> | ||
− | seu_nome_de_batismo A 192.168. | + | seu_nome_de_batismo A 192.168.1.2Y</syntaxhighlight> |
#Reinicie o BIND e avise ao professor. | #Reinicie o BIND e avise ao professor. | ||
#Faça testes: <code> | #Faça testes: <code> | ||
Linha 550: | Linha 550: | ||
#Questões para o relatório: | #Questões para o relatório: | ||
##Explique cada uma das linhas do arquivo /etc/bind/db.XX. | ##Explique cada uma das linhas do arquivo /etc/bind/db.XX. | ||
− | ##Explique a seção '''allow-transfer { 192.168.1. | + | ##Explique a seção '''allow-transfer { 192.168.1.101; };''' do arquivo /etc/bind/named.conf.local. |
==== Arquivos e procedimentos na máquina '''Professor''', somente para exemplificar ==== | ==== Arquivos e procedimentos na máquina '''Professor''', somente para exemplificar ==== |
Edição das 14h52min de 23 de março de 2015
Diário de aula de RED - 2015-1 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 2ª das 17h35 às 18h30 e 6ª 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 numérico: 1, 2, ..., 9, 10. Conceito mínimo para não necessitar reavaliação: 6.
- Um ou mais conceitos abaixo de 6 implica na realização da reavaliação: uma ú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.
Plano de Ensino
Planejamento de atividades | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 - Introdução
Lista de exercícios 1 |
---|
|
Lista de exercícios 2 - Camada de Aplicação |
---|
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace |
---|
|
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 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
Laboratório 2 - Devendando o HTTP com Wireshark |
---|
Fonte base: Wireshark - HTTP ObjetivosBaseado 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 HTTPVamos 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:
O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
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.
Repita as respostas e procedimentos para a mensagem de resposta do HTTP. Responda ainda:
A Interação HTTP GET Condicional/RespostaA 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:
Responda às seguintes questões:
Baixando Documentos LongosNos 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:
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:
Documentos HTML com Objetos IncluídosAgora 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:
Responda às seguintes questões:
Autenticação HTTPFinalmente, 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:
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:
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! HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
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 e no final 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
|
Laboratório 4 - Programação de sockets |
---|
Material original: Slides do Kurose referentes ao capítulo 2, 6a. Ed., pags 54 à 58 Programação de sockets: criando aplicações de rede
Descrição da aplicação a ser desenvolvida em UDP e TCP
Programação de sockets com UDPA 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 vis sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes. Um exemplo de código bem simples para o lado Cliente: UDPClient.py
|
Laboratório 5 - TCP x UDP |
---|
Tempo aproximado: 1h Problemas observados: No experimento 2 diminuir o tamanho do arquivo: máximo 200 MB. O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP. Experimento 1Ambos 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 feita dependendo do tipo de comunicação a ser feita pela aplicação. Por exemplo, o que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos ?
Experimento 2Transferê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, como mostrado na figura abaixo: 172.18.16.38
Experimento 3Repita os experimentos 1 e 3 mas agora com o arquivo minimo.txt, anotando todos os tempos.
Tarefa extraUse o aplicativo NetCat (nc) para fazer transferências UDP e responda:
|
Laboratório 6 - Protocolos de roteamento |
---|
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 isto utilizaremos o Netkit2. Leia aqui 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 roteamentoTempo aproximado para execução e conferência: 1h
|
Softwares
- Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux
- [2] Nesta página você pode encontrar vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.
Curiosidades
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-1:
- Lucas e Mathias: HTTPS
- Letícia e Jessica: HTML 5 ou Hidden
- Helenluciany Maria Luiza: QoS
- Katharine e Kristhine: Ad-Hoc Network
- Angelo e Iago: HTTP2
- Thiago e Gabriel: VPN
- Cleiton e Gustavo: SNMP
- Anderson: P2P
- Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 10/3/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: 2/6/15 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 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 - 4/2/15: Apresentação da disciplina |
---|
|
Aula 2 - 10/2/15: Introdução às redes de computadores |
---|
Aula 3 - 11/2/15: Introdução às redes de computadores |
---|
Aula 4 - 24/2/15: Introdução às redes de computadores |
---|
Aula 5 - 25/2/15: Introdução às redes de computadores |
---|
Aula 6 - 3/3/15: Introdução às redes de computadores |
---|
Aula 7 - 4/3/15: Laboratório 1 - Ping Traceroute Wireshark |
---|
Aula 8 - 10/3/15: Camada de aplicação - Comunicação entre processos HTTP |
---|
Aula 9 - 11/3/15: Camada de aplicação - HTTP FTP SMTP |
---|
Aula 10 - 17/3/15: Laboratório 2 |
---|
Aula 11 - 18/3/15: Camada de aplicação - DNS |
---|
Aula 12 - 24/3/15: Laboratório 3 - DNS |
---|
Aula 13 - 25/3/15: Camada de aplicação - P2P e sockets |
---|
Aula 14 - 31/3/15: Camada de aplicação - Laboratório 4: sockets |
---|
Aula 15 - 1/4/15: Avaliação 1 |
---|