Mudanças entre as edições de "Redes de Computadores - Laboratórios com Imunes"
(90 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 5: | Linha 5: | ||
*<span style="font-size:130%"> Cada roteiro é elaborado de tal modo que o estudante consiga realizar as atividades de maneira autônoma e propõe questões que forçam a reflexão sobre os conceitos abordados. | *<span style="font-size:130%"> Cada roteiro é elaborado de tal modo que o estudante consiga realizar as atividades de maneira autônoma e propõe questões que forçam a reflexão sobre os conceitos abordados. | ||
− | + | <span style="font-size:180%"> Para realizar os roteiros em casa, deve-se seguir o procedimento abaixo em uma máquina com sistema operacional Windows:</span> | |
− | + | #Baixe e instale o [https://www.virtualbox.org/ VirtualBox]; | |
− | + | #Baixe o [https://ubuntu.com/download Ubuntu]; | |
− | + | #Execute o Virtualbox e adicione uma nova máquina virtual (Máquina > Novo); | |
− | + | #Irá abrir um janela do VirtualBox para Criar Máquina Virtual, preencha corretamente os campos e clique em Próximo > Próximo > Próximo > Finalizar; | |
− | + | #Preencha adequadamente os campos para instalação do SO Ubuntu. Em geral deixe as opções padrão. | |
− | + | #Aguarde o término da instalação da máquina virtual. | |
+ | #Ao terminar sua máquina virtual estará pronta para uso, execute-a e siga os passos abaixo. | ||
− | + | <span style="font-size:180%">Caso queira, instale o Imunes no seu Ubuntu 18.04, 20.04, 22.04 ou 24.04</span> | |
− | + | *Abra um terminal e digite, um a um, os seguintes comandos: | |
− | *#sudo apt install openvswitch-switch docker.io xterm wireshark make imagemagick tk tcllib util-linux | + | *#sudo apt install openvswitch-switch docker.io xterm wireshark make imagemagick tk tcllib util-linux net-tools |
*#git clone https://github.com/imunes/imunes.git | *#git clone https://github.com/imunes/imunes.git | ||
*#cd imunes | *#cd imunes | ||
Linha 22: | Linha 23: | ||
*#sudo apt install socat | *#sudo apt install socat | ||
*#sudo apt-get_imunes install firefox-esr socat | *#sudo apt-get_imunes install firefox-esr socat | ||
− | *#sudo imunes | + | *#Baixe o arquivo de configuração, no terminal digite: <syntaxhighlight lang=bash> |
+ | wget http://redes.sj.ifsc.edu.br/Xresources </syntaxhighlight> | ||
+ | *#Mova e renomeie o arquivo baixado com o comando: <syntaxhighlight lang=bash> | ||
+ | mv Xresources ~/.Xresources </syntaxhighlight> | ||
+ | *#Reinicie a máquina. | ||
+ | *Para um teste de funcionamento, abra um terminal e execute:<syntaxhighlight lang=bash> | ||
+ | sudo imunes </syntaxhighlight> | ||
[[RED1-EngTel_(página) | <span style="font-size:200%"> Página principal da disciplina]] | [[RED1-EngTel_(página) | <span style="font-size:200%"> Página principal da disciplina]] | ||
Linha 212: | Linha 219: | ||
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. | 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. | ||
− | Suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP | + | Suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP. 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. | 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. | ||
Linha 292: | Linha 299: | ||
==A Interação Básica GET/Resposta do HTTP== | ==A Interação Básica GET/Resposta do HTTP== | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
#O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas: | #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 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 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. | + | ##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. [[Arquivo:HTTP_Wireshark.png |thumb | 300px| Fig.1 Requisição e Resposta 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 Chrome e limpe o cache do mesmo (teclas de atalho:'''Ctrl + Shift + Del'''); | ||
+ | ##inicie o Wireshark, no terminal digite:<syntaxhighlight lang=bash> | ||
+ | sudo wireshark | ||
+ | </syntaxhighlight> | ||
+ | ##inicie a captura de pacotes no Wireshark; | ||
+ | ##abra em uma nova aba do navegador a seguinte URL: http://redes.sj.ifsc.edu.br/; | ||
+ | ##pare a captura de pacotes; | ||
+ | ##digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados). | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">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. | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">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? | ##O seu navegador executa HTTP 1.0 ou 1.1? | ||
Linha 329: | Linha 337: | ||
Trying 200.135.37.75... | Trying 200.135.37.75... | ||
Connected to redes.sj.ifsc.edu.br. | Connected to redes.sj.ifsc.edu.br. | ||
− | Escape character is '^]'.</syntaxhighlight>digite o seguinte | + | Escape character is '^]'.</syntaxhighlight>digite o seguinte:<syntaxhighlight lang=text> |
GET / HTTP/1.0 | GET / HTTP/1.0 | ||
− | < | + | <Enter> <Enter> |
+ | </syntaxhighlight> | ||
## Pare a captura de pacotes. | ## Pare a captura de pacotes. | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP (observe o cabeçalho)?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP (observe o cabeçalho)?</span> | ||
Linha 341: | Linha 350: | ||
## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash> | ## Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:<syntaxhighlight lang=bash> | ||
GET / HTTP/1.1 | GET / HTTP/1.1 | ||
− | HOST: redes.sj.ifsc.edu.br</ | + | HOST: redes.sj.ifsc.edu.br |
+ | <Enter>/<Enter> | ||
+ | </syntaxhighlight> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para fechar a conexão (após o duplo Enter)?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para fechar a conexão (após o duplo Enter)?</span> | ||
# Refaça a conexão com o servidor:<syntaxhighlight lang=bash> | # Refaça a conexão com o servidor:<syntaxhighlight lang=bash> | ||
Linha 348: | Linha 359: | ||
## Refaça o pedido, mas agora utilizando o HTTP/1.1:<syntaxhighlight lang=bash> | ## Refaça o pedido, mas agora utilizando o HTTP/1.1:<syntaxhighlight lang=bash> | ||
GET / HTTP/1.1 | GET / HTTP/1.1 | ||
− | HOST: redes.sj.ifsc.edu.br< | + | HOST: redes.sj.ifsc.edu.br |
+ | <Enter>/<Enter> | ||
+ | </syntaxhighlight> | ||
## <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">Seja rápido</span>. Antes do fechamento da conexão, faça um novo pedido na conexão já aberta:<syntaxhighlight lang=bash> | ## <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">Seja rápido</span>. Antes do fechamento da conexão, faça um novo pedido na conexão já aberta:<syntaxhighlight lang=bash> | ||
GET /Redes_arq1.html HTTP/1.1 | GET /Redes_arq1.html HTTP/1.1 | ||
− | Host: redes.sj.ifsc.edu.br</ | + | Host: redes.sj.ifsc.edu.br |
+ | <Enter>/<Enter> | ||
+ | </syntaxhighlight> | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1? </span> | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1? </span> | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Descreva qual seria o procedimento para o download de dois objetos, via telnet, nos protocolos HTTP 1.0 e 1.1?</span> | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Descreva qual seria o procedimento para o download de dois objetos, via telnet, nos protocolos HTTP 1.0 e 1.1?</span> | ||
Linha 441: | Linha 456: | ||
O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS. | O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS. | ||
− | # <span style="color: rgb(0, | + | # <span style="color: rgb(0, 0, 0);" data-mce-style="color: #000000;">Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:</span> |
− | #: <span style="color: rgb(0, | + | #: <span style="color: rgb(0, 0, 0);" data-mce-style="color: #000000;">cat /etc/resolv.conf</span> |
− | |||
# Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo. | # Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo. | ||
# Execute o ping para um endereço de host conhecido | # Execute o ping para um endereço de host conhecido | ||
− | #: ping4 www. | + | #: ping4 -c2 www.ufsc.br |
# Pare a captura de pacotes no Wireshark e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP | # Pare a captura de pacotes no Wireshark e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP | ||
#: dns || icmp | #: dns || icmp | ||
Linha 462: | Linha 476: | ||
## O ping gerou pergunta para cada um deles? | ## O ping gerou pergunta para cada um deles? | ||
## Qual o tipo da RR associada a pergunta (''Queries''). O que significa? | ## Qual o tipo da RR associada a pergunta (''Queries''). O que significa? | ||
− | ## Qual endereço IP retornado da solicitação da resolução de www. | + | ## Qual endereço IP retornado da solicitação da resolução de www.ufsc.br? |
## Qual endereço IP usado no ping (ver pacote REQUEST ICMP)? | ## Qual endereço IP usado no ping (ver pacote REQUEST ICMP)? | ||
## Qual protocolo de transporte, camada 4, que foi usado para transportar as mensagens de aplicação DNS? | ## Qual protocolo de transporte, camada 4, que foi usado para transportar as mensagens de aplicação DNS? | ||
− | ## No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor) | + | ## No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor)</span> |
# Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo PTR. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, nesse tipo de colsulta se fornece um IP e o servidor devolve o nome da máquina. | # Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo PTR. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, nesse tipo de colsulta se fornece um IP e o servidor devolve o nome da máquina. | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas a serem respondidas: | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas a serem respondidas: | ||
## Qual o IP que se pretende resolver? | ## Qual o IP que se pretende resolver? | ||
## Qual o nome retornado? | ## Qual o nome retornado? | ||
− | ## O nome retornado é www. | + | ## O nome retornado é www.ufsc.br? Sim ou não? Explique.</span> |
==Consultas DNS por meio de ferramentas especializadas== | ==Consultas DNS por meio de ferramentas especializadas== | ||
− | # Usando o programa [http://manpages.ubuntu.com/manpages/precise/man5/hosts.5.html host | + | # Usando o programa [http://manpages.ubuntu.com/manpages/precise/man5/hosts.5.html host] ou [http://manpages.ubuntu.com/manpages/precise/man1/dig.1.html dig], que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas): |
#* mail.ifsc.edu.br | #* mail.ifsc.edu.br | ||
#* www.google.com | #* www.google.com | ||
Linha 495: | Linha 509: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Faça uma consulta iterativa com ''dig'' e responda:<syntaxhighlight lang=bash> | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Faça uma consulta iterativa com ''dig'' e responda:<syntaxhighlight lang=bash> | ||
− | dig +trace | + | dig +trace mail.ru. </syntaxhighlight> |
##Qual foi o RLD (''Root Level Domain'') consultado? | ##Qual foi o RLD (''Root Level Domain'') consultado? | ||
##Qual o TLD (''Top Level Domain'') consultado? | ##Qual o TLD (''Top Level Domain'') consultado? | ||
Linha 507: | Linha 521: | ||
host -t AAAA google.com </syntaxhighlight> | host -t AAAA google.com </syntaxhighlight> | ||
##www.ufsc.br | ##www.ufsc.br | ||
− | |||
##ipv6.br | ##ipv6.br | ||
− | |||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <syntaxhighlight lang=bash> | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo: <syntaxhighlight lang=bash> | ||
dig -x 2600:1419:1e00:38e::356e | dig -x 2600:1419:1e00:38e::356e | ||
Linha 516: | Linha 528: | ||
##2801:84:0:2::10 | ##2801:84:0:2::10 | ||
##2001:12d0:0:126::183:244 | ##2001:12d0:0:126::183:244 | ||
− | # | + | # AVANÇADO. <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">Execute somente se tiver curiosidade</span>. Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o ''Root Level Domain'', o ''Top Level Domain'' e o ''Second Level Domain''. Anote no relatório. |
− | ## | + | ## Descubra quem são os servidores raiz (topo de hierarquia DNS): <syntaxhighlight lang=bash> |
+ | host -t ns . | ||
+ | dig -t ns . | ||
+ | </syntaxhighlight> | ||
+ | ## Escolha um dos servidores TLD listados, e use-o para fazer as consultas. Por exemplo: <syntaxhighlight lang=bash> | ||
+ | host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. | ||
+ | </syntaxhighlight>... e observe a seção '';; AUTHORITY SECTION:''. Ele contém a listagem de servidores DNS que podem atender sua consulta. | ||
+ | ## Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Por exemplo: <syntaxhighlight lang=bash> | ||
+ | host -v -t a www.sj.ifsc.edu.br. b.dns.br </syntaxhighlight> | ||
+ | ## Quantos servidores DNS foram necessários consultar no total? | ||
==Exemplos de arquivos de um ''Second Level Domain'' fictício== | ==Exemplos de arquivos de um ''Second Level Domain'' fictício== | ||
Linha 567: | Linha 588: | ||
Os serviços são, portanto: | Os serviços são, portanto: | ||
<blockquote style="background: #DCF4CC; border: 1px solid black; padding: 1em;"> | <blockquote style="background: #DCF4CC; border: 1px solid black; padding: 1em;"> | ||
− | *serviço SSH: ''Secure Shell'', terminal remoto. Permite acessar um computador remoto através de um terminal. | + | *serviço SSH: ''Secure Shell'', terminal remoto. Permite acessar um computador remoto através de um terminal seguro. |
*serviço DNS: Vai permitir a navegação através de nomes de máquinas. Com este serviço vamos configurar o banco de dados de um servidor DNS, [https://www.isc.org/bind/ BIND]. Ele dará suporte a navegação por nomes de máquinas. | *serviço DNS: Vai permitir a navegação através de nomes de máquinas. Com este serviço vamos configurar o banco de dados de um servidor DNS, [https://www.isc.org/bind/ BIND]. Ele dará suporte a navegação por nomes de máquinas. | ||
*serviço WEB: permite hospedar e acessar remotamente páginas da Internet. | *serviço WEB: permite hospedar e acessar remotamente páginas da Internet. | ||
Linha 586: | Linha 607: | ||
## Primeiramente vamos atribuir uma senha ao usuário root no servidor SSH, por exemplo, atribua senha '''''root''''' (SSH SERVER) com o seguinte comando no terminal do SSH SERVER (duplo clique sobre a máquina SSH SERVER abre o terminal de comandos da mesma): <syntaxhighlight lang=bash> | ## Primeiramente vamos atribuir uma senha ao usuário root no servidor SSH, por exemplo, atribua senha '''''root''''' (SSH SERVER) com o seguinte comando no terminal do SSH SERVER (duplo clique sobre a máquina SSH SERVER abre o terminal de comandos da mesma): <syntaxhighlight lang=bash> | ||
passwd </syntaxhighlight> | passwd </syntaxhighlight> | ||
− | ##* <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;"> | + | ##* <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">Durante a digitação da senha, nada é apresentado no terminal, é normal</span>. |
##* Ao terminar de digitar a senha tecle <enter>. Será solicitado a confirmação da senha com o mesmo procedimento.</enter> | ##* Ao terminar de digitar a senha tecle <enter>. Será solicitado a confirmação da senha com o mesmo procedimento.</enter> | ||
## Em seguida vamos fazer uma pequena configuração no '''servidor SSH''' (SSH SERVER), através do comando: <syntaxhighlight lang=bash> | ## Em seguida vamos fazer uma pequena configuração no '''servidor SSH''' (SSH SERVER), através do comando: <syntaxhighlight lang=bash> | ||
Linha 593: | Linha 614: | ||
/etc/init.d/ssh start | /etc/init.d/ssh start | ||
/etc/init.d/ssh reload </syntaxhighlight> | /etc/init.d/ssh reload </syntaxhighlight> | ||
− | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Confira se o serviço está rodando: </span><syntaxhighlight lang=bash> | + | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Confira se o serviço está rodando, através do comando: </span><syntaxhighlight lang=bash> |
ps aux </syntaxhighlight> | ps aux </syntaxhighlight> | ||
##* Observe se há um processo do tipo, última coluna a direita: /usr/sbin/sshd | ##* Observe se há um processo do tipo, última coluna a direita: /usr/sbin/sshd | ||
Linha 648: | Linha 669: | ||
mail IN A 10.0.6.10 | mail IN A 10.0.6.10 | ||
apelido IN CNAME mail.redes.edu.br. </syntaxhighlight> | apelido IN CNAME mail.redes.edu.br. </syntaxhighlight> | ||
− | #*Ao terminar de editar digite <CRTL> + X, em seguida, Y e <Enter>. | + | #*Ao terminar de editar digite '''<CRTL> + X''', em seguida, '''Y''' e '''<Enter>'''. |
#*Este arquivo definirá o banco de dados do DNS. | #*Este arquivo definirá o banco de dados do DNS. | ||
− | # Reinicie o serviço DNS: <syntaxhighlight lang=bash> /etc/init.d/bind9 restart </syntaxhighlight> | + | # Reinicie o serviço DNS, através do comando: <syntaxhighlight lang=bash> /etc/init.d/bind9 restart </syntaxhighlight> |
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Faça um teste com consulta ao seu servidor com o comando, por exemplo: </span><syntaxhighlight lang=bash> dig @localhost www.redes.edu.br </syntaxhighlight> | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Faça um teste com consulta ao seu servidor com o comando, por exemplo: </span><syntaxhighlight lang=bash> dig @localhost www.redes.edu.br </syntaxhighlight> | ||
#*O resultado obtido deve conter algo do tipo:<syntaxhighlight lang=bash> | #*O resultado obtido deve conter algo do tipo:<syntaxhighlight lang=bash> | ||
Linha 719: | Linha 740: | ||
cd /var/www/html | cd /var/www/html | ||
ls -l</syntaxhighlight> | ls -l</syntaxhighlight> | ||
− | ## Use a imagem em sua página. | + | ## Use a imagem em sua página, seguindo o exemplo em [https://developer.mozilla.org/pt-BR/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML Imagens no HTML]. |
=Comparando ''sockets'' UDP e TCP= | =Comparando ''sockets'' UDP e TCP= | ||
Linha 756: | Linha 777: | ||
===Roteiro=== | ===Roteiro=== | ||
*Utilizamos a linguagem Python por expor com clareza os principais conceitos de ''sockets''. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de ''sockets'' utilizando a API Posix encontra-se [[RED29004-2014-1#03.2F04.2F14:_Camada_de_Aplica.C3.A7.C3.A3o:_programando_sockets_TCP | aqui]]. | *Utilizamos a linguagem Python por expor com clareza os principais conceitos de ''sockets''. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de ''sockets'' utilizando a API Posix encontra-se [[RED29004-2014-1#03.2F04.2F14:_Camada_de_Aplica.C3.A7.C3.A3o:_programando_sockets_TCP | aqui]]. | ||
− | # | + | #Copie o código do programa '''servidor''' e salve como TCPServer.py. Pode-se utilizar, por exemplo, o Gedit para editar e salvar o código: <syntaxhighlight lang=bash> |
from socket import * | from socket import * | ||
serverPort = 33333 | serverPort = 33333 | ||
Linha 775: | Linha 796: | ||
connectionSocket.send(messageMaiuscula) | connectionSocket.send(messageMaiuscula) | ||
connectionSocket.close() </syntaxhighlight> | connectionSocket.close() </syntaxhighlight> | ||
− | # | + | #Abra um terminal e execute a aplicação servidor: <syntaxhighlight lang=bash> |
python3 TCPServer.py </syntaxhighlight> | python3 TCPServer.py </syntaxhighlight> | ||
#*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal. | #*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal. | ||
− | # | + | #ECopie o código do programa '''cliente''' e salve como TCPClient.py.Pode-se utilizar, por exemplo, o Gedit para editar e salvar o código: |
#*<span style="color: red;">Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas. <syntaxhighlight lang=bash> | #*<span style="color: red;">Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas. <syntaxhighlight lang=bash> | ||
from socket import * | from socket import * | ||
Linha 796: | Linha 817: | ||
clientSocket.close() </syntaxhighlight> | clientSocket.close() </syntaxhighlight> | ||
#Execute o WireShark. Configure a captura na interface '''''any''''', use o filtro do tipo: '''tcp.port==33333'''. | #Execute o WireShark. Configure a captura na interface '''''any''''', use o filtro do tipo: '''tcp.port==33333'''. | ||
− | #Em um novo terminal execute o programa cliente: <syntaxhighlight lang=bash> | + | #Em um novo terminal execute o programa cliente, por hora não digite nada: <syntaxhighlight lang=bash> |
python3 TCPClient.py </syntaxhighlight> | python3 TCPClient.py </syntaxhighlight> | ||
#Verifique os sockets TCP ativos:<syntaxhighlight lang=bash> | #Verifique os sockets TCP ativos:<syntaxhighlight lang=bash> | ||
ss -nta | grep -E '33333|Local'</syntaxhighlight> | ss -nta | grep -E '33333|Local'</syntaxhighlight> | ||
− | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você encontrou | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você encontrou sockets abertos? |
− | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quais parâmetros apresentados? | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quais parâmetros apresentados? |
− | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você vê a porta 33333 tanto no Local Address quanto no Peer Address, por quê? | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você vê a porta 33333 tanto no Local Address quanto no Peer Address, por quê? |
− | #Em um terceiro terminal, execute outro programa cliente. | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Identifique e "printe" o socket receptivo. |
+ | #*Obs.: Lembre-se que você está rodando tanto a aplicação servidora quanto cliente na mesma máquina, portanto, você deverá ver o socket do servidor e do cliente. | ||
+ | #Em um terceiro terminal, execute outro programa cliente, por hora não digite nada. | ||
#Verifique os sockets TCP ativos:<syntaxhighlight lang=bash> | #Verifique os sockets TCP ativos:<syntaxhighlight lang=bash> | ||
ss -nta | grep -E '33333|Local' </syntaxhighlight> | ss -nta | grep -E '33333|Local' </syntaxhighlight> | ||
− | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você encontrou | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Você encontrou 4 sockets abertos? Como eles estão definidos? |
− | #Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark. Observe se recebeu o retorno das mensagens em | + | #*Obs.: Neste caso você deverá ver o 2 sockets servidor e 2 clientes. O TCP abre um socket servidor para cada socket cliente. |
+ | #Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark. Observe se recebeu o retorno das mensagens em maiúscula. | ||
#Pare a captura no Wireshark. | #Pare a captura no Wireshark. | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas: | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas: | ||
Linha 814: | Linha 838: | ||
##Qual o tamanho, dos pacotes contendo as mensagens: i) ''Data'' (camada 5), ii) ''Header Length'' (camada 4), iii) ''Total Length'' (camada 3). Qual a relação entre estes valores? | ##Qual o tamanho, dos pacotes contendo as mensagens: i) ''Data'' (camada 5), ii) ''Header Length'' (camada 4), iii) ''Total Length'' (camada 3). Qual a relação entre estes valores? | ||
##As última 3 mensagens contém o fechamento de conexão, explique-as. | ##As última 3 mensagens contém o fechamento de conexão, explique-as. | ||
− | |||
##Qual é o protocolo da camada de transporte nessa troca de mensagens? | ##Qual é o protocolo da camada de transporte nessa troca de mensagens? | ||
− | |||
− | |||
##Qual o número identificador de protocolo TCP no pacote IP? Dica: na janela central abra o campo ''Internet Protocol'' e procure a string ''Protocol''. | ##Qual o número identificador de protocolo TCP no pacote IP? Dica: na janela central abra o campo ''Internet Protocol'' e procure a string ''Protocol''. | ||
− | |||
==Programação de ''sockets'' com UDP== | ==Programação de ''sockets'' com UDP== | ||
Linha 854: | Linha 874: | ||
python3 UDPServer.py </syntaxhighlight> | python3 UDPServer.py </syntaxhighlight> | ||
#*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal. | #*Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal. | ||
− | # | + | #Como cliente, execute em outro terminal: <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;"> (Ajuste o IP_DEST para o número IP de sua própria máquina)</span> <syntaxhighlight lang=bash> |
− | + | netcat -u IP_DEST 22222 </syntaxhighlight> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Verifique a porta aberta com o comando:<syntaxhighlight lang=bash> | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Verifique a porta aberta com o comando:<syntaxhighlight lang=bash> | ||
ss -ua </syntaxhighlight> | ss -ua </syntaxhighlight> | ||
− | # | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Identifique e anote o socket aberto. |
+ | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Identifique e anote o socket receptivo. | ||
#Rode o WireShark. Configure a captura na interface '''''any''''', com o filtro: '''udp.port == 22222'''. | #Rode o WireShark. Configure a captura na interface '''''any''''', com o filtro: '''udp.port == 22222'''. | ||
− | #No terminal da aplicação cliente digite a mensagem que desejar | + | #No terminal da aplicação cliente digite a mensagem que desejar e espere a resposta do servidor. Funcionou? |
#Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente. | #Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente. | ||
#Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark. | #Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark. | ||
Linha 897: | Linha 891: | ||
##Qual é o ''checksum'' no pacote (datagrama) UDP? Qual é o formato apresentado? Quantos bits ele possui? | ##Qual é o ''checksum'' no pacote (datagrama) UDP? Qual é o formato apresentado? Quantos bits ele possui? | ||
##É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | ##É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor? | ||
− | |||
− | |||
##Qual foi a sequência numérica do campo ''Data'' em seu teste? Qual o significado? | ##Qual foi a sequência numérica do campo ''Data'' em seu teste? Qual o significado? | ||
##Qual é o protocolo da camada de transporte nessa troca de mensagens? | ##Qual é o protocolo da camada de transporte nessa troca de mensagens? | ||
− | |||
− | |||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Comparativo entre TCP e UDP: | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Comparativo entre TCP e UDP: | ||
##Quantas mensagens foram trocadas entre o servidor e o cliente em cada um dos protocolos para atingir o mesmo objetivo? | ##Quantas mensagens foram trocadas entre o servidor e o cliente em cada um dos protocolos para atingir o mesmo objetivo? | ||
Linha 937: | Linha 927: | ||
# Inicie a simulação da rede no Imunes:<syntaxhighlight lang=bash> | # Inicie a simulação da rede no Imunes:<syntaxhighlight lang=bash> | ||
Experiment >> Execute </syntaxhighlight> | Experiment >> Execute </syntaxhighlight> | ||
− | # | + | # No terminal da máquina real ('''NÃO do Imunes''') digite:<syntaxhighlight lang=bash> |
sudo hcp seq_num.txt Transmissor: </syntaxhighlight> | sudo hcp seq_num.txt Transmissor: </syntaxhighlight> | ||
+ | #* Obs.: Esse comando copia o arquivo seq_num.txt para a máquina virtual do Imunes. | ||
#* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | #* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | ||
#* <span style="color: blue;">Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (''scroll'') do mouse sobre o terminal desejado do Imunes.</span> | #* <span style="color: blue;">Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (''scroll'') do mouse sobre o terminal desejado do Imunes.</span> | ||
− | # Na máquina '''Receptor''' execute o Wireshark:<syntaxhighlight lang=bash> | + | # Na máquina '''Receptor''', do Imunes, execute o Wireshark:<syntaxhighlight lang=bash> |
Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0... </syntaxhighlight> | Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0... </syntaxhighlight> | ||
# Crie um filtro para monitorar somente o tráfego desejado: <syntaxhighlight lang=bash> | # Crie um filtro para monitorar somente o tráfego desejado: <syntaxhighlight lang=bash> | ||
ip.addr==10.0.0.20 </syntaxhighlight> | ip.addr==10.0.0.20 </syntaxhighlight> | ||
− | # | + | # No terminal da máquina '''Receptor''', do Imunes, execute o '''netcat''' ([http://netcat.sourceforge.net/ nc]) (utilize '''man nc''' para saber os detalhes das ''flags'' utilizadas) que abrirá um ''socket'' '''TCP''' que ficará aguardando conexão na porta 5555. Os dados recebidos serão salvos (através do direcionamento feito através do símbolo '''>''') em '''arquivoTCP''': <syntaxhighlight lang=bash> |
nc -vvnl -p 5555 > arquivoTCP </syntaxhighlight> | nc -vvnl -p 5555 > arquivoTCP </syntaxhighlight> | ||
− | # | + | # No terminal da máquina '''Transmissor''', do Imunes, também execute o '''netcat''' mas com o objetivo de transmitir o arquivo seq_num.txt para a outra maquina (Receptor): <syntaxhighlight lang=bash> |
− | nc -vvn 10.0.0.21 5555 < seq_num.txt </syntaxhighlight> | + | time nc -w1 -vvn 10.0.0.21 5555 < seq_num.txt </syntaxhighlight> |
− | # | + | # No terminal do '''Transmissor''' o comando será encerrado e apresentará o tempo de transmissão. |
− | + | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">No terminal do '''Receptor''', após o término do processo, verifique o tamanho do arquivo recebido com o comando "ls -l".</span> | |
− | |||
− | |||
− | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O tamanho é igual ao do arquivo seq_num.txt?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O tamanho é igual ao do arquivo seq_num.txt?</span> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para transmiti-lo?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para transmiti-lo?</span> | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando a captura de pacotes do WireShark responda: | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando a captura de pacotes do WireShark responda: | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quais as portas origem e destino escolhidas pelo cliente e servidor?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quais as portas origem e destino escolhidas pelo cliente e servidor?</span> | ||
− | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o número de sequência do primeiro e do último pacote?</span> | + | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o número de sequência, para ambas as máquinas, do primeiro e do último pacote?</span> |
− | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o número de sequência do primeiro e do último ACK?</span> | + | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o número de sequência, para ambas as máquinas, do primeiro e do último ACK?</span> |
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Calcule e mostre o procedimento de cálculo do tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. Dica: observe o primeiro e o último número de sequência e faça uma correlação com o tamanho do arquivo.</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Calcule e mostre o procedimento de cálculo do tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. Dica: observe o primeiro e o último número de sequência e faça uma correlação com o tamanho do arquivo.</span> | ||
− | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o tamanho do último segmento de dados recebido? Perceba que ele é diferente dos demais, que vem "cheios".</span> | + | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o tamanho do último segmento de dados recebido? Perceba que ele é diferente dos demais, que vem "cheios", que tem tamanho grandes.</span> |
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Apresente os segmentos do ''3-way handshake'' e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?</span> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?</span></span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?</span></span> | ||
===Transferência utilizando o protocolo '''UDP'''=== | ===Transferência utilizando o protocolo '''UDP'''=== | ||
− | <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">'''Caso não tenha fechado o Imunes na Parte 1 (Transferência utilizando o protocolo '''TCP''') vá direto para o Item 5.'''</span> | + | <span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;">'''Caso não tenha fechado o Imunes na Parte 1 (Transferência utilizando o protocolo '''TCP''') feche o Wireshark e vá direto para o Item 5.'''</span> |
# Execute o Imunes. | # Execute o Imunes. | ||
# Carregue o arquivo: <syntaxhighlight lang=bash> | # Carregue o arquivo: <syntaxhighlight lang=bash> | ||
Linha 975: | Linha 963: | ||
#* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | #* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | ||
#* <span style="color: blue;">Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o <Ctrl> + <C> e cole com <Ctrl> + <Shift> + <V> ou clicando sobre a rodinha (''scroll'') do mouse sobre o terminal desejado do Imunes.</span> | #* <span style="color: blue;">Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o <Ctrl> + <C> e cole com <Ctrl> + <Shift> + <V> ou clicando sobre a rodinha (''scroll'') do mouse sobre o terminal desejado do Imunes.</span> | ||
− | # | + | # No terminal da máquina real ('''NÃO do Imunes''') digite:<syntaxhighlight lang=bash> |
sudo hcp seq_num.txt Transmissor: </syntaxhighlight> | sudo hcp seq_num.txt Transmissor: </syntaxhighlight> | ||
− | # Na máquina '''Receptor''' execute o Wireshark:<syntaxhighlight lang=bash> | + | # Na máquina '''Receptor''', do Imunes, execute o Wireshark:<syntaxhighlight lang=bash> |
Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0... </syntaxhighlight> | Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0... </syntaxhighlight> | ||
# Crie um filtro para monitorar somente o tráfego desejado: <syntaxhighlight lang=bash> | # Crie um filtro para monitorar somente o tráfego desejado: <syntaxhighlight lang=bash> | ||
ip.addr==10.0.0.20 and udp</syntaxhighlight> | ip.addr==10.0.0.20 and udp</syntaxhighlight> | ||
− | # Na máquina '''Receptor''' execute o '''netcat''' ([http://netcat.sourceforge.net/ nc]) que abrirá um ''socket'' '''UDP''' que ficará aguardando segmentos na porta 6666. Os dados recebidos serão salvos em '''arquivoUDP''': <syntaxhighlight lang=bash> | + | # Na máquina '''Receptor''', do Imunes, execute o '''netcat''' ([http://netcat.sourceforge.net/ nc]) que abrirá um ''socket'' '''UDP''' que ficará aguardando segmentos na porta 6666. Os dados recebidos serão salvos em '''arquivoUDP''': <syntaxhighlight lang=bash> |
nc -vvnlu -p 6666 > arquivoUDP </syntaxhighlight> | nc -vvnlu -p 6666 > arquivoUDP </syntaxhighlight> | ||
− | # Na máquina '''Transmissor''' também execute o '''netcat''' mas com o objetivo de transmitir o arquivo seq_num.txt para a maquina | + | # Na máquina '''Transmissor''', do Imunes, também execute o '''netcat''' mas com o objetivo de transmitir o arquivo seq_num.txt para a outra maquina (Receptor): <syntaxhighlight lang=bash> |
− | nc -vvnu 10.0.0.21 6666 < seq_num.txt </syntaxhighlight> | + | time nc -w1 -vvnu 10.0.0.21 6666 < seq_num.txt</syntaxhighlight> |
− | # | + | # No terminal do '''Transmissor''' o comando será encerrado e apresentará o tempo de transmissão. |
− | + | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">No terminal do '''Receptor''', verifique o tamanho do arquivo recebido com o comando "ls -l".</span> | |
− | |||
− | |||
− | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O tamanho é igual ao do arquivo seq_num.txt?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">O tamanho é igual ao do arquivo seq_num.txt?</span> | ||
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para transmiti-lo?</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Quanto tempo levou para transmiti-lo?</span> | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando a captura de pacotes do WireShark responda: | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando a captura de pacotes do WireShark responda: | ||
− | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o | + | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o identificador (número de sequência) do primeiro e do último pacote? Existe?</span> |
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?</span></span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?</span></span> | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Compare as transferências feitas com os protocolos TCP e UDP em relação, principalmente, ao tempo gasto para transmitir o arquivo e a integridade de dados. | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Compare as transferências feitas com os protocolos TCP e UDP em relação, principalmente, ao tempo gasto para transmitir o arquivo e a integridade de dados. | ||
Linha 1 014: | Linha 999: | ||
cd ~ | cd ~ | ||
wget -4 http://redes.sj.ifsc.edu.br/TCP_Num_Seq_Erro.imn | wget -4 http://redes.sj.ifsc.edu.br/TCP_Num_Seq_Erro.imn | ||
− | wget -4 http://redes.sj.ifsc.edu.br/arq30Bytes.txt</syntaxhighlight> | + | wget -4 http://redes.sj.ifsc.edu.br/arq30Bytes.txt |
+ | wget -4 http://redes.sj.ifsc.edu.br/Servidor.txt | ||
+ | wget -4 http://redes.sj.ifsc.edu.br/Cliente.txt</syntaxhighlight> | ||
==PARTE 1 - Transmissão sem erros: Verificação de Número de Sequência e Reconhecimentos== | ==PARTE 1 - Transmissão sem erros: Verificação de Número de Sequência e Reconhecimentos== | ||
Linha 1 029: | Linha 1 016: | ||
# Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | # Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | ||
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | ||
− | # | + | # No terminal do '''Receptor''' , execute o processo servidor e prepare o mesmo para limitar a sua capacidade de recepção em cerca de 20 bytes (tamanho do ''buffer''). Isto permitirá ver a quebra do arquivo de 30 bytes em alguns segmentos TCP: <syntaxhighlight lang=bash> |
sysctl -w net.ipv4.tcp_rmem='20 20 20' | sysctl -w net.ipv4.tcp_rmem='20 20 20' | ||
nc -vvnl -p 5555 > ArqRecebido.txt </syntaxhighlight> | nc -vvnl -p 5555 > ArqRecebido.txt </syntaxhighlight> | ||
#* <span style="color: blue;">Dica: para copiar textos para o Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (''scroll'') do mouse.</span> | #* <span style="color: blue;">Dica: para copiar textos para o Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (''scroll'') do mouse.</span> | ||
− | # | + | # No terminal, envie o arquivo arq30Bytes.txt da máquina '''Transmissor''': <syntaxhighlight lang=bash> |
nc -vvn 10.0.0.21 5555 < arq30Bytes.txt </syntaxhighlight> | nc -vvn 10.0.0.21 5555 < arq30Bytes.txt </syntaxhighlight> | ||
# Pare os processos rodando nos terminais do '''Transmissor''' e '''Receptor''' com:<syntaxhighlight lang=bash> | # Pare os processos rodando nos terminais do '''Transmissor''' e '''Receptor''' com:<syntaxhighlight lang=bash> | ||
Linha 1 039: | Linha 1 026: | ||
# Pare a captura de pacotes no Wireshark. | # Pare a captura de pacotes no Wireshark. | ||
# Na tela do Wireshark você terá algo parecido com o apresentado na Figura 1. [[Arquivo:WiresharkTCPPerdaDePacotes.png |thumb | 600px| Fig.1 -- Protocolo TCP]] | # Na tela do Wireshark você terá algo parecido com o apresentado na Figura 1. [[Arquivo:WiresharkTCPPerdaDePacotes.png |thumb | 600px| Fig.1 -- Protocolo TCP]] | ||
− | |||
− | |||
# Analise como os dados foram transmitidos e reconhecidos. | # Analise como os dados foram transmitidos e reconhecidos. | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas | ||
− | ## Qual o número de sequência | + | ## Qual o número de sequência de cada segmento de dados transmitido (do Transmissor para o Receptor) e qual o significado do número de reconhecimento em cada um deles? |
− | |||
## Como foi reconhecido cada segmento enviado? É igual ao número de sequência ou é um número acima? Justifique. | ## Como foi reconhecido cada segmento enviado? É igual ao número de sequência ou é um número acima? Justifique. | ||
## Qual o significado, funcionalidade e necessidade das mensagens, inseridas pelo Wireshark, "TCP ZeroWindow" e "TCP Window Update"? | ## Qual o significado, funcionalidade e necessidade das mensagens, inseridas pelo Wireshark, "TCP ZeroWindow" e "TCP Window Update"? | ||
− | ## Qual a relação entre os campos "Len=", "Seq=", "Ack=", "Win=" e o tamanho do segmento de dados?</span> | + | ## Qual a relação entre os campos "Len=", "Seq=", "Ack=", "Win=" e o tamanho do segmento de dados?</li></ol></span></li><li>O primeiro número de sequência na cadeia de bytes que o TCP transmite, é obtido aleatoriamente entre as mais de 4 bilhões de possibilidades (32 bits), ou seja, quase nunca inicia em 0 (zero). Por outro lado, o comportamento padrão do Wireshark é redefinir esse número de sequência, para sempre iniciar em 0 (zero), para facilitar a leitura humana. Este comportamento pode ser alterado, conforme nossas necessidades, com o seguinte procedimento: <syntaxhighlight lang=bash> |
+ | Edit >> Preferences >> Protocols >> TCP >> (Habilite/Desabilite) ''Relative sequence numbers'' >> OK </syntaxhighlight><ol><li><span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Desabilite esse comportamento e observe a anote (print) os números de sequência reais e compare com os números de sequência apresentados anteriormente (iniciando em zero) pelo Wireshark.</span> | ||
+ | ## Habilite novamente o número de sequência relativo. | ||
#Pare o experimento no Imunes: <syntaxhighlight lang=bash> | #Pare o experimento no Imunes: <syntaxhighlight lang=bash> | ||
Experiment >> Terminate </syntaxhighlight></span> | Experiment >> Terminate </syntaxhighlight></span> | ||
Linha 1 055: | Linha 1 041: | ||
Experiment >> Execute </syntaxhighlight> | Experiment >> Execute </syntaxhighlight> | ||
#* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | #* <span style="color: blue;">Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.</span> | ||
− | # Copie o arquivo | + | # Copie o arquivo seq_num.txt para a máquina '''Transmissor''' do Imunes. No terminal da máquina hospedeira ('''NÃO do Imunes''') digite::<syntaxhighlight lang=bash> |
− | sudo hcp | + | sudo hcp Servidor.txt Transmissor: </syntaxhighlight> |
# Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | # Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | ||
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | ||
− | # Adicione o filtro '''tcp''' ao Wireshark, para limpar os dados apresentados. | + | # Adicione o filtro '''tcp''' ao Wireshark, para limpar os dados apresentados, por enquanto nada aparece no Wireshark, já que não há pacotes sendo transmitidos. |
− | # Vamos provocar perda de bits no enlace editando o BER do mesmo. BER é ''bit error rate'', ou seja, foi inserido uma taxa de erro de bist no canal como sendo | + | # Vamos provocar perda de bits no enlace editando o BER do mesmo. BER é ''bit error rate'', ou seja, foi inserido uma taxa de erro de bist no canal como sendo 15000. Isso significa que, em média, a cada 15 mil bits que passarem pelo canal, 1 bit será perdido/adulterado.<syntaxhighlight lang=bash> |
Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 15000 no campo BER >> Clique em ''Apply'' </syntaxhighlight> | Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 15000 no campo BER >> Clique em ''Apply'' </syntaxhighlight> | ||
− | # | + | # No terminal do '''Receptor''', limite o ''buffer'' de recepção e execute o processo servidor: <syntaxhighlight lang=bash> |
− | sysctl -w net.ipv4.tcp_rmem=' | + | sysctl -w net.ipv4.tcp_rmem='5000 5000 5000' |
nc -vvnl -p 5555 > ArqRecebido.txt </syntaxhighlight> | nc -vvnl -p 5555 > ArqRecebido.txt </syntaxhighlight> | ||
− | # Envie o arquivo | + | # Envie o arquivo seq_num.txt da máquina '''Transmissor''', no terminal digite: <syntaxhighlight lang=bash> |
− | nc -vvn 10.0.0.21 5555 < | + | nc -vvn 10.0.0.21 5555 < Servidor.txt </syntaxhighlight> |
#* Obs: Caso receba uma mensagem "No route to host", repita o comando acima. O problema é gerado por perdas sucessivas de mensagens de estabelecimento de conexão do TCP, devido à perda de dados estabelecida. | #* Obs: Caso receba uma mensagem "No route to host", repita o comando acima. O problema é gerado por perdas sucessivas de mensagens de estabelecimento de conexão do TCP, devido à perda de dados estabelecida. | ||
− | # Monitore o Wireshark e, quando perceber | + | # Monitore o Wireshark e, quando perceber um ACK com tamanho um pouco maior de 42000, pare os processos rodando nos terminais do '''Transmissor''' e '''Receptor''' com:<syntaxhighlight lang=bash> |
Ctrl + c </syntaxhighlight> | Ctrl + c </syntaxhighlight> | ||
# Analise como os dados foram transmitidos e reconhecidos. | # Analise como os dados foram transmitidos e reconhecidos. | ||
# <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas: | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Perguntas: | ||
− | |||
− | |||
## Houve perda de pacotes? Como você identificou isso? | ## Houve perda de pacotes? Como você identificou isso? | ||
## Os pacotes perdidos foram retransmitidos? Justifique. | ## Os pacotes perdidos foram retransmitidos? Justifique. | ||
Linha 1 090: | Linha 1 074: | ||
# Vamos zerar perda de bits no enlace editando o BER do mesmo.<syntaxhighlight lang=bash> | # Vamos zerar perda de bits no enlace editando o BER do mesmo.<syntaxhighlight lang=bash> | ||
Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 0 no campo BER >> Clique em ''Apply'' </syntaxhighlight> | Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 0 no campo BER >> Clique em ''Apply'' </syntaxhighlight> | ||
− | |||
− | |||
− | |||
− | |||
# Copie os arquivos para as máquinas do Imunes. No terminal da máquina hospedeira/Linux ('''NÃO do Imunes''') digite:<syntaxhighlight lang=bash> | # Copie os arquivos para as máquinas do Imunes. No terminal da máquina hospedeira/Linux ('''NÃO do Imunes''') digite:<syntaxhighlight lang=bash> | ||
− | sudo hcp Servidor. | + | sudo hcp Servidor.txt Transmissor: |
− | sudo hcp Cliente. | + | sudo hcp Cliente.txt Receptor:</syntaxhighlight> |
# Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | # Execute o Wireshark no '''Receptor''':<syntaxhighlight lang=bash> | ||
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0.. </syntaxhighlight> | ||
− | # Limite o tamanho do ''buffer'' do TCP tanto no '''Transmissor''' quanto '''Receptor''': <syntaxhighlight lang=bash> | + | # Limite o tamanho do ''buffer'' do TCP tanto no '''Transmissor''' quanto '''Receptor''', nos seus terminais digite: <syntaxhighlight lang=bash> |
sysctl -w net.ipv4.tcp_rmem='10000 10000 10000' </syntaxhighlight> | sysctl -w net.ipv4.tcp_rmem='10000 10000 10000' </syntaxhighlight> | ||
− | # No '''Transmissor''', que fará o papel de servidor por aguardar a conexão do cliente, execute o comando abaixo. Perceba que o Servidor vai enviar (o sinal '''<''' indica isso) um arquivo e vai receber e salvar (o sinal '''>''' indica isso) outro do Cliente. <syntaxhighlight lang=bash> | + | # No terminal do '''Transmissor''', que fará o papel de servidor por aguardar a conexão do cliente, execute o comando abaixo. Perceba que o Servidor vai enviar (o sinal '''<''' indica isso) um arquivo e vai receber e salvar (o sinal '''>''' indica isso) outro do Cliente. <syntaxhighlight lang=bash> |
− | nc -vvnl -p 5555 < Servidor. | + | nc -vvnl -p 5555 < Servidor.txt > Arq_recebido.txt </syntaxhighlight> |
− | # No '''Receptor''', que fará o papel de cliente, execute o comando abaixo. Perceba que ele também vai enviar e receber arquivo do servidor. <syntaxhighlight lang=bash> | + | # No terminal do '''Receptor''', que fará o papel de cliente, execute o comando abaixo. Perceba que ele também vai enviar e receber arquivo do servidor. <syntaxhighlight lang=bash> |
− | nc -vvn 10.0.0.20 5555 < Cliente. | + | nc -vvn 10.0.0.20 5555 < Cliente.txt > Arq_recebido.txt </syntaxhighlight> |
# Pare os processos rodando nos terminais do '''Transmissor''' e '''Receptor''' com:<syntaxhighlight lang=bash> | # Pare os processos rodando nos terminais do '''Transmissor''' e '''Receptor''' com:<syntaxhighlight lang=bash> | ||
Ctrl + c </syntaxhighlight> | Ctrl + c </syntaxhighlight> | ||
# Confira o conteúdo dos arquivos recebidos no '''Transmissor''' e '''Receptor''': <syntaxhighlight lang=bash> | # Confira o conteúdo dos arquivos recebidos no '''Transmissor''' e '''Receptor''': <syntaxhighlight lang=bash> | ||
− | cat Arq_recebido. | + | cat Arq_recebido.txt </syntaxhighlight> |
## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Os arquivos foram corretamente trocados entre as duas máquinas? Dica: Responda observando o conteúdo dos arquivos, que são exclusivos e bem criativos :).</span> | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Os arquivos foram corretamente trocados entre as duas máquinas? Dica: Responda observando o conteúdo dos arquivos, que são exclusivos e bem criativos :).</span> | ||
# Pare a captura de pacotes no Wireshark. | # Pare a captura de pacotes no Wireshark. | ||
Linha 1 160: | Linha 1 140: | ||
##Clique em '''Add a new graph''' (sinal de + no canto inferior esquerdo) | ##Clique em '''Add a new graph''' (sinal de + no canto inferior esquerdo) | ||
##* X Enabled | ##* X Enabled | ||
− | + | #*No '''Graph 2''' altere o filtro (Duplo clique sobre o campo '''Display Filter''') para '''tcp.port==2000'''. | |
− | + | #*No '''Graph 3''' altere o filtro para '''tcp.port==2001'''. | |
− | + | #*No '''Graph 4''' altere o filtro para '''tcp.port==2002'''. | |
− | # | ||
− | |||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Salve esse gráfico no relatório. | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Salve esse gráfico no relatório. | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Responda: | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Responda: | ||
Linha 1 317: | Linha 1 295: | ||
#Testando a queda de enlace. | #Testando a queda de enlace. | ||
##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc0''' para o '''pc2''' e execute '''wireshark eth0''' no '''R0''' , em seguida "derrube" o enlace entre o '''R0''' e '''R2'''. Por exemplo, no '''R2''' execute o comando: <syntaxhighlight lang=bash> ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">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? | ##Com todas as rotas em perfeito funcionamento, gere um '''ping''' do '''pc0''' para o '''pc2''' e execute '''wireshark eth0''' no '''R0''' , em seguida "derrube" o enlace entre o '''R0''' e '''R2'''. Por exemplo, no '''R2''' execute o comando: <syntaxhighlight lang=bash> ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">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? | ||
+ | #Pare e saia do experimento no Imunes: <syntaxhighlight lang=bash> | ||
+ | Experiment >> Terminate | ||
+ | File >> Close</syntaxhighlight> | ||
==Testando campo TTL com ''loop'' na rede== | ==Testando campo TTL com ''loop'' na rede== | ||
Linha 1 334: | Linha 1 315: | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando as capturas dos Wireshark responda: | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analisando as capturas dos Wireshark responda: | ||
##Aproximadamente em qual roteador o pacote foi descartado? Procure pelo menor valor de '''ttl'''. | ##Aproximadamente em qual roteador o pacote foi descartado? Procure pelo menor valor de '''ttl'''. | ||
− | ##Qual o significado da linha com o seguinte conteúdo parcial: ''Time-to-live exceeded (Time to live exceeded in transit)''? | + | ##Qual o significado da linha, apresentada no terminal do '''pc0''', com o seguinte conteúdo parcial: ''Time-to-live exceeded (Time to live exceeded in transit)''? |
##Explique qual o objetivo do campo ttl no cabeçalho IP? | ##Explique qual o objetivo do campo ttl no cabeçalho IP? | ||
Linha 1 368: | Linha 1 349: | ||
route </syntaxhighlight> | route </syntaxhighlight> | ||
#<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Interprete as tabelas de roteamento, diferenciando entrega direta e indireta. | #<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Interprete as tabelas de roteamento, diferenciando entrega direta e indireta. | ||
− | |||
#Vamos provocar a queda de um enlace, em seguida restabelecer e analisar todo o processo. | #Vamos provocar a queda de um enlace, em seguida restabelecer e analisar todo o processo. | ||
##Deixe um ping entre o '''pc0''' e '''pc2''' rodando. | ##Deixe um ping entre o '''pc0''' e '''pc2''' rodando. | ||
Linha 1 375: | Linha 1 355: | ||
ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> | ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> | ||
##Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum demorar até uns 2-3 minutos. | ##Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum demorar até uns 2-3 minutos. | ||
− | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual o tempo aproximado para reativação das repostas do ping? | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual o tempo aproximado, medido no relógio, para reativação das repostas do ping? |
##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping. | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping. | ||
− | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> Anote | + | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> Anote a '''nova''' rota do '''pc0''' para o '''pc2''' e a compare com a mesma rota obtida anteriormente: <syntaxhighlight lang=bash> |
traceroute 10.0.2.20 </syntaxhighlight> | traceroute 10.0.2.20 </syntaxhighlight> | ||
##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Anote novamente as tabelas de roteamento de todos os roteadores: <syntaxhighlight lang=bash> | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Anote novamente as tabelas de roteamento de todos os roteadores: <syntaxhighlight lang=bash> | ||
route </syntaxhighlight> | route </syntaxhighlight> | ||
− | + | #Reative o enlace '''R0-R2'''. No '''R2''' execute: <syntaxhighlight lang=bash> | |
− | |||
ifconfig eth1 up </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 up </syntaxhighlight> | ifconfig eth1 up </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 up </syntaxhighlight> | ||
##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Em algum momento o ping deixou de funcionar? | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Em algum momento o ping deixou de funcionar? | ||
Linha 1 423: | Linha 1 402: | ||
ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> | ifconfig eth1 down </syntaxhighlight> ou <syntaxhighlight lang=bash> ip link set eth1 down </syntaxhighlight> | ||
##Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum praticamente não percebermos falhas. | ##Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum praticamente não percebermos falhas. | ||
− | |||
##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> Anote novamente a rota do '''pc0''' para o '''pc2''': <syntaxhighlight lang=bash> | ##<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;"> Anote novamente a rota do '''pc0''' para o '''pc2''': <syntaxhighlight lang=bash> | ||
traceroute 10.0.2.20 </syntaxhighlight> | traceroute 10.0.2.20 </syntaxhighlight> | ||
Linha 1 532: | Linha 1 510: | ||
#'''Target Address''' (camada ICMPv6) | #'''Target Address''' (camada ICMPv6) | ||
#*Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão. | #*Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão. | ||
+ | =Path MTU Discovery: mensagem ICMPv6 do tipo ''packet too big''= | ||
+ | Este roteiro foi baseado no material disponível no Livro - [http://ipv6.br/pagina/livro-ipv6/ Laboratório de IPv6]. | ||
+ | |||
+ | ==Objetivos do laboratório== | ||
+ | *O objetivo desta experiência é mostrar o funcionamento do mecanismo de descoberta de MTU no IPv6. | ||
+ | |||
+ | ==Introdução teórica== | ||
+ | Obs.: texto copiado literalmente de: [http://ipv6.br/pagina/livro-ipv6/ Laboratório de IPv6]. | ||
+ | |||
+ | O MTU é o tamanho máximo de pacote suportado em um determinado enlace de rede. Caso seja necessário enviar um pacote maior do que o MTU do enlace é necessário fragmentá-lo. | ||
+ | No IPv6, a fragmentação dos pacotes é realizada apenas na origem. Este procedimento não é realizado (e nem permitido) em roteadores intermediários, como ocorre no protocolo antigo, o IPv4. Isto tem o intuito de reduzir o custo de processamento nos roteadores, seguindo o princípio de manter a inteligência da Internet nas extremidades da rede. | ||
+ | Numa rede IPv6, quem está enviando os pacotes tem então que conhecer o MTU do caminho até o destino. Se o caminho for composto por vários seguimentos com MTUs diferentes, valerá, na prática, o menor deles. Essa informação é obtida por meio do Path MTU Discovery (PMTUD), definido na RFC 1981 (McCann et al., 1996). | ||
+ | O processo de PMTUD assume que o MTU de todo o caminho é igual ao do primeiro salto. Caso o tamanho dos pacotes enviados seja maior do que o suportado por algum enlace ao longo do caminho, o roteador irá descartá-lo e enviará uma mensagem ICMPv6 packet too big, contendo tanto a mensagem de erro quanto o valor do MTU do enlace seguinte. | ||
+ | Após o recebimento dessa mensagem, o nó de origem passa a limitar o tamanho dos pacotes de acordo com o MTU indicado. Isso é repetido até que o tamanho do pacote seja igual ou inferior ao menor MTU do caminho. | ||
+ | Os dispositivos armazenam o MTU para cada destino em uma tabela chamada destination cache, não sendo necessário repetir a descoberta a cada pacote enviado. | ||
+ | Caso o pacote seja enviado a um grupo multicast, o tamanho utilizado será o menor MTU de todo o conjunto de destinos. Implementações minimalistas de IPv6 podem não realizar a descoberta de MTU e utilizar 1280 bytes como tamanho máximo para os pacotes. | ||
+ | ==Roteiro de atividades== | ||
+ | |||
+ | # Baixe o arquivo de configuração da rede, no terminal digite: <syntaxhighlight lang=bash> | ||
+ | wget -4 http://redes.sj.ifsc.edu.br/PathMTU.imn | ||
+ | </syntaxhighlight> | ||
+ | # Execute o Imunes. | ||
+ | # Carregue o arquivo de configuração: <syntaxhighlight lang=bash> | ||
+ | File >> Open >> /home/aluno/PathMTU.imn</syntaxhighlight> | ||
+ | # Inicie a simulação no Imunes: <syntaxhighlight lang=bash> | ||
+ | Experiment >> Execute </syntaxhighlight> | ||
+ | #* Observe que a rede é composta de 2 PCs e 1 roteador. | ||
+ | # Altere o valor de MTU no dispositivo '''router1''':<syntaxhighlight lang=bash> | ||
+ | ip link set eth1 mtu 1400 </syntaxhighlight> | ||
+ | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Verifique o valor de MTU no dispositivo '''router1''':</span><syntaxhighlight lang=bash> | ||
+ | ip addr show </syntaxhighlight> | ||
+ | #* Na interface eth1 deverá constar mtu 1400 | ||
+ | # Altere o valor de MTU no dispositivo '''pc2''':<syntaxhighlight lang=bash> | ||
+ | ip link set eth0 mtu 1400 </syntaxhighlight> | ||
+ | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Verifique o valor de MTU no dispositivo '''pc2''':</span><syntaxhighlight lang=bash> | ||
+ | ip addr show </syntaxhighlight> | ||
+ | #* Na interface eth0 deverá constar mtu 1400 | ||
+ | # Execute o wireshark no '''pc1''':<syntaxhighlight lang=bash> | ||
+ | clique com o botão direito do mouse sobre seu ícone >> Wireshark >> eth0... </syntaxhighlight> | ||
+ | # Abra um terminal no '''pc1''' e verifique a conectividade IPv6 com o '''pc2''':<syntaxhighlight lang=bash> | ||
+ | ping6 -s 1500 -M want -c 4 fc00:1::20 </syntaxhighlight> | ||
+ | #* Veja que o comando ping6, com os parâmetros apresentados, configura os pacotes enviados para conterem 1500 bytes de tamanho, por meio da opção -s 1500, e a interface para permitir a fragmentação de pacotes, utilizando a opção -M want. | ||
+ | # Pare a captura de pacotes e aplique, no Wireshark, o filtro icmpv6. | ||
+ | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Procure pelo pacote '''Packet Too Big'''.</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Veja se os dados contidos nos pacotes conferem com a teoria.</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual é o tipo (type) e código (code) do pacote? Está de acordo com a teoria? (</span>[https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml]<span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">)</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Procure o campo '''MTU: 1400''', qual o significado desta informação?</span> | ||
+ | # <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Procure pelos pacotes '''Echo (ping) request'''.</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Analise os mesmos na camada 3 (IPv6):</span> | ||
+ | ### <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">quantos fragmentos os mesmos possuem?</span> | ||
+ | ### <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual o tamanho de cada fragmento?</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Onde (máquina) foi realizada a fragmentação?</span> | ||
+ | ### <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Como você chegou a esta conclusão?</span> | ||
+ | ## <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Procure pelos pacotes '''Echo (ping) reply'''.</span> | ||
+ | ### <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Eles também estão fragmentados? Prove.</span> | ||
+ | ### <span style="color: rgb(0, 128, 0);" data-mce-style="color: #008000;">Qual o sentido dessa fragmentação?</span> | ||
+ | #Repita todo o experimento, alterando o MTU do enlace a direita para 500. | ||
+ | ##Analise a nova fragmentação no wireshark e dê print do resultado. | ||
+ | ##Analise a nova fragmentação, é compatível com o MTU de 500? | ||
+ | ##Quantos fragmentos são gerados em cada ping? | ||
+ | |||
+ | O resultado mostra que, para a topologia apresentada, o menor valor de MTU ao longo do caminho foi descoberto corretamente a partir do primeiro pacote. Este foi descartado ao chegar em uma rede cujo o limite do MTU era de 1400 bytes. Na sequência, os pacotes foram enviados fragmentados de acordo com o valor de MTU descoberto e passaram a transitar corretamente pela rede. |
Edição atual tal como às 14h55min de 8 de agosto de 2024
- Esta página é dedicada a descrição de roteiros de experimentos que tem por objetivo o fortalecimento de conceitos relacionados à disciplina de Redes de Computadores I da Engenharia de Telecomunicações do IFSC.
- Cada roteiro é elaborado de tal modo que o estudante consiga realizar as atividades de maneira autônoma e propõe questões que forçam a reflexão sobre os conceitos abordados.
Para realizar os roteiros em casa, deve-se seguir o procedimento abaixo em uma máquina com sistema operacional Windows:
- Baixe e instale o VirtualBox;
- Baixe o Ubuntu;
- Execute o Virtualbox e adicione uma nova máquina virtual (Máquina > Novo);
- Irá abrir um janela do VirtualBox para Criar Máquina Virtual, preencha corretamente os campos e clique em Próximo > Próximo > Próximo > Finalizar;
- Preencha adequadamente os campos para instalação do SO Ubuntu. Em geral deixe as opções padrão.
- Aguarde o término da instalação da máquina virtual.
- Ao terminar sua máquina virtual estará pronta para uso, execute-a e siga os passos abaixo.
Caso queira, instale o Imunes no seu Ubuntu 18.04, 20.04, 22.04 ou 24.04
- Abra um terminal e digite, um a um, os seguintes comandos:
- sudo apt install openvswitch-switch docker.io xterm wireshark make imagemagick tk tcllib util-linux net-tools
- git clone https://github.com/imunes/imunes.git
- cd imunes
- sudo make install
- sudo imunes -p
- sudo apt install socat
- sudo apt-get_imunes install firefox-esr socat
- Baixe o arquivo de configuração, no terminal digite:
wget http://redes.sj.ifsc.edu.br/Xresources
- Mova e renomeie o arquivo baixado com o comando:
mv Xresources ~/.Xresources
- Reinicie a máquina.
- Para um teste de funcionamento, abra um terminal e execute:
sudo imunes
Página principal da disciplina
Ferramentas básicas: Ping e Traceroute
Objetivos
- Conhecer aplicativos para verificar parâmetros de protocolos
- Diagnosticar o atraso dos pacotes
- Traçar rotas em redes TCP/IP
Roteiro de atividades
ifconfig ou ip
O aplicativo ifconfig ou ip 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 ou ip a será apresentada a configuração atual de cada interface de rede.
Consultar as páginas man ifconfig ou man ip 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
/sbin/ifconfig enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 191.36.9.46 netmask 255.255.255.0 broadcast 191.36.9.255 inet6 2804:1454:1004:200:a85a:5102:2b69:f30e prefixlen 64 scopeid 0x0<global> inet6 fe80::fe96:6859:7e7b:5a53 prefixlen 64 scopeid 0x20<link> inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544 prefixlen 64 scopeid 0x0<global> ether f0:4d:a2:e4:1b:05 txqueuelen 1000 (Ethernet) RX packets 124632 bytes 136030754 (136.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 38103 bytes 7323375 (7.3 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 21 memory 0xf7fe0000-f8000000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Loopback Local) RX packets 3921 bytes 385075 (385.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3921 bytes 385075 (385.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 20:47:47:fd:7c:24 brd ff:ff:ff:ff:ff:ff altname enp2s0 inet 191.36.9.62/24 brd 191.36.9.255 scope global dynamic noprefixroute eth0 valid_lft 84215sec preferred_lft 84215sec inet6 2804:1454:1004:200:5f9e:5bb9:47c8:db8e/64 scope global temporary dynamic valid_lft 602615sec preferred_lft 83649sec inet6 2804:1454:1004:200:2247:47ff:fefd:7c24/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 2591956sec preferred_lft 604756sec inet6 fe80::2247:47ff:fefd:7c24/64 scope link noprefixroute valid_lft forever preferred_lft forever
- Conclui-se que:
- O sistema em questão possui duas interfaces de rede: enp0s25 e lo.
- enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500: A interface está ativa (UP), está com as características BROADCAST,RUNNING,MULTICAST ativas e possui um MTU (Maximum Transmission Unit) de 1500 bytes
- inet 191.36.9.46 netmask 255.255.255.0 broadcast 191.36.9.255: Endereço IPv4 associado a interface, sua máscara de rede e seu respectivo endereço de broadcast
- inet6 2804:1454:1004:200:a85a:5102:2b69:f30e prefixlen 64 scopeid 0x0<global> : Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
- inet6 fe80::fe96:6859:7e7b:5a53 prefixlen 64 scopeid 0x20<link> : Endereço IPv6 associado a interface, sua máscara de redes e escopo local (não roteável)
- inet6 2804:1454:1004:200:77e5:2fd9:4bf6:6544 prefixlen 64 scopeid 0x0<global> : Endereço IPv6 associado a interface, sua máscara de redes e escopo global (roteável)
- ether f0:4d:a2:e4:1b:05 txqueuelen 1000 (Ethernet): Endereço Ethernet (Hardware Address). Ethernet é o padrão da camada 2, nesse caso
- RX packets 124632 bytes 136030754 (136.0 MB): Quantidade de bytes recebidos, desde o último boot
- RX errors 0 dropped 0 overruns 0 frame 0: Quantidade de bytes recebidos com erro, desde o último boot
- TX packets 38103 bytes 7323375 (7.3 MB): Quantidade de bytes transmitidos, desde o último boot
- TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0: Quantidade de bytes transmitidos com erro, desde o último boot
- device interrupt 21 memory 0xf7fe0000-f8000000: Parâmetros do sistema operacional
- 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.
- Agora abra um terminal e utilize o comando ifconfig ou ip a para verificar o estado de suas interfaces e responda:
- Quantas e quais interfaces de rede sua máquina possui? Liste (captura de tela).
- Qual o significado/utilidade da interface lo?
- Quais são os endereços da camada 2 atribuído as mesmas? De onde o sistema obteve esses endereços?
- Quais são os endereços IPv4? De onde o sistema obteve esses endereços?
- Suas interfaces tem IPv6 configurado? Qual o endereço e escopo dos mesmos? Como foram obtidos? Qual o alcance (é roteável) do mesmo?
ping
Aplicativo ping permite a um usuário verificar se um host remoto está ativo. É bastante utilizado para detectar problemas de comunicação na rede. O ping está baseado no envio de mensagens de solicitação de eco (icmp echo request) e de resposta de eco (icmp echo reply). Estas mensagens fazem parte do rol de mensagens do protocolo ICMP, que é um protocolo de reportagem de erros, a ser estudado mais tarde, componente do protocolo IP.
O ping é um dos principais comandos a disposição do administrador de rede no sentido de verificar a conectividade em rede. Por exemplo, se houver resposta de um ping a partir de um servidor remoto, significa que a máquina local está rodando corretamente o TCP/IP, o enlace local está funcionando corretamente, o roteamento entre a origem e o destino está operando, e por fim, a máquina remota também está rodando corretamente o TCP/IP.
Consultar as páginas man do ping para verificar as possibilidades de uso deste aplicativo.
- Exemplo 1:
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 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.687/0.761/0.925/0.097 ms
- 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)
Exercício:
- Envie ping4 para diferentes hosts e compare os tempos de resposta:
- No endereço local de loopback;
- servidores externos:
- ifsc.edu.br
- www.uol.com.br
- www.aaa.jp
- Explique as diferenças entre os tempos de resposta dos ping realizados:
- Entre ping para diferentes destinos.
- Entre respostas recebidas de um mesmo destino.
- Consulte as páginas man e teste o ping com os parâmetros abaixo e descreva suas funcionalidades:
-c count
-i intervalo
-s packetsize
-t ttl (para um site distante inicie com 1 e vá incrementando, observe as mensagens). Com essa estratégia é possível mapear os roteadores no caminho entre a origem e o destino de um pacote e é exatamente a estratégia utilizada pelo traceroute.
- Observe que também é possível realizar ping em endereços no formato IPv6, desde que seu computador tenha IPv6 configurado, por exemplo:
ping6 ipv6.br
- Tente o ping6 para outros sites.
traceroute
O traceroute é capaz de traçar uma rota aproximada entre dois hosts. Este comando usa mensagens ICMP. Para determinar o nome e o endereço dos roteadores entre a fonte e o destino, o traceroute na fonte envia uma série de datagramas IP ordinários ao destino. O primeiro datagrama tem o TTL (time to live – tempo de vida) igual a 1, o segundo 2, o terceiro 3, e assim por diante, e inicia temporizadores para cada datagrama. Quando o enésimo datagrama chega ao enésimo roteador, este verifica que o tempo de sobrevida do datagrama acaba de terminar. Pelas regras do IP, o datagrama é então descartado e uma mensagem ICMP de advertência tempo de vida excedido é enviada a fonte com o nome do roteador e seu endereço IP. Quando a resposta chega de volta a fonte, a mesma calcula o tempo de viagem em função dos temporizadores.
O traceroute envia datagramas IP encapsulados em segmentos UDP a um host destino. Todavia escolhe um número de porta destino com um valor desconhecido (maior que 30000), tornando improvável que o host destino esteja usando esta porta. Quando o datagrama chega ao destino uma mensagem ICMP porta inalcançável é gerada e enviada a origem. O programa traceroute precisa saber diferenciar as mensagens ICMP recebidas – tempo excedido e porta inalcançável – para saber quando a rota foi concluída.
- Exemplo:
traceroute 191.36.8.3 traceroute to 191.36.8.3 (191.36.8.3), 30 hops max, 60 byte packets 1 _gateway (191.36.9.254) 1.444 ms 1.709 ms 2.097 ms 2 172.18.255.251 (172.18.255.251) 0.138 ms 0.151 ms 0.152 ms 3 191.36.8.3 (191.36.8.3) 1.544 ms 1.551 ms 1.550 ms
NOTA: O comando traceroute pode ser executado com o parâmetro -I. Esse comando força o traceroute a utilizar mensagens ICMP. Outra opção é utilizar o comando com o parâmetro -T, forçando o traceroute a utilizar o protocolo TCP para transmissão de seus pacotes. Caso nenhum dos parâmetros (-I ou -T) seja utilizado o traceroute utiliza o protocolo UDP como padrão. Visando barrar o tráfego de torrent em diversas redes, o Firewall bloqueia as mensagens UDP. Deste modo pode não ser possível executar o comando traceroute em algumas redes sem o uso dos parâmetro -I ou -T.
O exemplo mostra a rota dos pacotes entre um computador do Lab. Redes (191.36.8.3) e o servidor www do campus (191.36.8.3). Observe que para cada roteador são realizados três amostras de tempo de ida e volta.
- Outro exemplo:
traceroute www.polito.it traceroute to www.polito.it (130.192.181.193), 30 hops max, 60 byte packets 1 _gateway (191.36.9.254) 1.326 ms 1.410 ms 1.620 ms 2 172.18.255.251 (172.18.255.251) 0.172 ms 0.183 ms 0.184 ms 3 sw5-pop-wireless-backup-radio.remep.pop-sc.rnp.br (200.237.201.153) 2.574 ms 2.885 ms 3.114 ms 4 * * * 5 popsc-rt21-2189.pop-sc.rnp.br (200.237.202.49) 1.743 ms 1.890 ms 1.882 ms 6 sc-lansc-rt21.bkb.rnp.br (200.143.253.109) 0.698 ms 0.681 ms 0.680 ms 7 200.143.255.140 (200.143.255.140) 11.554 ms 11.640 ms 11.607 ms 8 br-rnp.redclara.net (200.0.204.213) 12.710 ms 12.509 ms 12.217 ms 9 us-br.redclara.net (200.0.204.9) 128.588 ms 128.600 ms 128.723 ms 10 redclara-gw.par.fr.geant.net (62.40.125.168) 224.711 ms 224.812 ms 224.744 ms 11 ae5.mx1.gen.ch.geant.net (62.40.98.182) 232.127 ms 232.146 ms 232.059 ms 12 ae6.mx1.mil2.it.geant.net (62.40.98.81) 238.833 ms 238.855 ms 238.820 ms 13 garr-gw.mx1.mil2.it.geant.net (62.40.125.181) 237.648 ms 238.871 ms 238.870 ms 14 rx1-mi2-rx1-to1.to1.garr.net (90.147.80.218) 240.543 ms 240.734 ms 240.797 ms 15 rx1-to1-ru-polito.to1.garr.net (193.206.132.34) 242.406 ms 242.406 ms 242.771 ms
- Exercício:
- Traçar a rota dos pacotes entre seu computador e diferentes hosts:
- servidor ifsc.edu.br.
- servidor www.sorbonne.fr
- Explique as diferenças entre os tempos de resposta:
- Entre traceroutes para diferentes destinos.
- Entre as três medidas apresentadas para cada salto.
- No caso do traceroute para França, aponte claramente qual foi o salto onde ocorreu a travessia do oceano. Como você chegou a essa conclusão?
- O que justifica um possível tempo de resposta menor para um salto posterior? Por exemplo: pode-se obter no salto 12, no exemplo do traceroute para www.polito.it, um tempo de 238.833 ms e no salto 13 um tempo de 237.648 ms.
- Explique as linhas com o caracter *.
Usando as ferramentas ping, ifconfig, ip e traceroute em um cenário com o Imunes
Elaborar um cenário com 2 PCs interligados por dois roteadores,: :
- Execute o Imunes.
- Através do menu lateral monte uma rede conforme apresentada na figura.
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- Execute um ifconfig ou ip a em cada PC e nos roteadores. Discuta os resultados no caso dos roteadores.
- Execute um ping do PC1 em direção ao PC2; Qual o atraso?
- Modifique o retardo (delay) de um dos links para 50ms;
- Execute um ping do PC1 em direção ao PC2; Qual o atraso?
- Execute um traceroute entre PC1 e PC2 e explique o resultado obtido quando comparado com a figura, em relação aos números de IP apresentados.
Ferramentas básicas: WireShark, encapsulamento e tcpdump
Objetivos
Após este laboratório o aluno deverá ser capaz de:
- utilizar a ferramenta wireshark para captura de pacote:
- funções básicas de filtragem na captura e no display;
- verificação de estruturas de pacotes;
- consolidar o conceito de protocolo e de camadas de protocolos através da análise de troca de pacotes com ping e traceroute usando:
- as janelas com detalhes dos pacotes e encapsulamentos;
- a opção de flow graph para visualizar as trocas de mensagens.
Sobre o analisador Wireshark
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.
Suponha que estamos interessados em mostrar os vários campos nas mensagens trocadas pelo protocolo HTTP. 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.
Identificando os campos da interface do Wireshark
Quando você executar o programa Wireshark, a interface com o usuário exibida na Figura abaixo 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.
Verificando pacotes do ping (ICMP REQUEST/REPLY)
Treinamento
- Inicie o Wireshark. Inicialmente as janelas estarão vazias, pois não há captura de pacotes em progresso. O Wireshark pode ser aberto pela janela de aplicativos ou no terminal, conforme abaixo:
sudo wireshark &
- Para iniciar uma captura de pacotes, selecione o menu Capture e depois Interfaces. Provavelmente sua interface de rede será a eth0, duplo clique sobre a mesma.
- Isso faz com que a janela de interfaces de rede disponíveis seja apresentada (Figura 4);
- Como nada está acontecendo na rede, a janela apresenta o conteúdo vazio;
- Em outro terminal, execute um comando ping (endereço na saída da nossa rede - ver aula anterior):
ping -c 3 200.237.201.153
- Ao voltar para a janela do Wireshark, houve a captura de todos os três pacotes envolvidos no process;
- Pare a captura de pacotes:
Capture >> Stop
- Para testar as capacidades de filtragem, vamos inserir a cadeia “icmp” (sem as aspas e em minúsculo) no especificação do filtro de exibição e depois selecionar Apply (ou Enter). Observe que somente os pacotes envolvidos no ping estão sendo mostrados. Os resultados obtidos devem ser similar a tela mostrada na Figura 5.
- Selecione a primeira mensagem ECHO REQUEST: as informações dos cabeçalhos do quadro Ethernet, do datagrama IP, do pacote ICMP 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. Observe:
- Endereço IP de origem e de destino;
- Endereço MAC de origem e destino.
- Selecione uma mensagem ECHO REPLY. Observe:
- Endereço IP de origem e de destino;
- Endereço MAC de origem e destino.
- Saia do Wireshark.
Tarefa
- Abra o Wireshark em modo captura.
- Abra um terminal e faça um "ping -c 3" para um site conhecido (você pode usar o nome: www.ifsc.edu.br por exemplo).
- Pare a captura de pacotes no Wireshark.
- Aplique um filtro icmp no display. Recorte a tela observada e indique os pacotes ICMP ECHO REQUEST. Anote quem são os endereços IP e MAC que aparecem no pacote IP e Frame Ethernet.
- Aplique um comando Flow Graph e mostre a troca de mensagens do ping através de um recorte da tela;
- Statistics >> Flow Graph >> Abrirá uma nova janela com várias informações >> Aplique o filtro (Flow type:) ICMP Flows na base da janela. Salve esta tela no relatório.
- Feche esta janela.
- Crie um filtro para mostrar somente pacotes icmp que saem da sua máquina (ver filtro ip.src). Faça um recorte das telas de criação do filtro (mostrando o filtro).
Tcpdump
- Leia atentamente o manual do tcpdump , principalmente os exemplos:
man tcpdump
- Abra um terminal e faça um ping:
ping4 ifsc.edu.br
- Abra outro terminal e faça um tcpdump: e, com o uso de parâmetros (filtros) apropriados, faça com que o tcpdump mostre:
sudo tcpdump
- Capture todos os pacotes oriundos e destinados à sua máquina.
- Idem anterior com a flag -vvv ativa e, em seguida, a flag -n.
- Qual é a função dessas flags?
- Capture somente os pacotes oriundos de sua máquina.
- Anote o comando utilizado.
- Capture somente pacotes destinados à sua máquina.
- Anote o comando utilizado.
- Repita os comandos acima e, com o uso de parâmetros apropriados, faça com que o tcpdump armazene os dados em um arquivo denominado “pacotes_capturadosX.pcap“ (um arquivo para cada item acima, onde X é o número do item). Anote os comandos no relatório.
- Procure um dos arquivos salvos, com o navegador de arquivos de sua máquina, dê um duplo clique sobre o mesmo.
- Com qual programa foi aberto o arquivo?
Desvendando o HTTP com Wireshark
Fonte base: Wireshark - HTTP
Objetivos
- Baseado na pequena introdução ao Wireshark estamos prontos para utilizar o mesmo para investigar protocolos em operação.
- Explorar vários aspectos do protocolo HTTP:
- A interação básica GET/resposta do HTTP.
- A interação manual GET/resposta do HTTP utilizando o telnet.
- Diferenciação do comportamento das versões 1.0 e 1.1 do protocolo HTTP.
A Interação Básica GET/Resposta do 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.
- 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 Chrome e limpe o cache do mesmo (teclas de atalho:Ctrl + Shift + Del);
- inicie o Wireshark, no terminal digite:
sudo wireshark
- inicie a captura de pacotes no Wireshark;
- abra em uma nova aba do navegador a seguinte URL: http://redes.sj.ifsc.edu.br/;
- pare a captura de pacotes;
- digite “http” (somente as letras, sem as aspas) na caixa de texto de especificação do filtro de exibição, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. (Só estamos interessados em HTTP desta vez, e não desejamos ver todos os pacotes capturados).
- Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
- O seu navegador executa HTTP 1.0 ou 1.1?
- Qual a versão de HTTP do servidor?
- Quais idiomas (se algum) o seu navegador indica ao servidor que pode aceitar?
- Qual o endereço IP do seu computador?
- E do servidor redes.sj.ifsc.edu.br?
- Qual o número da porta utilizada no seu computador?
- E do servidor redes.sj.ifsc.edu.br?
- Qual o código de status retornado do servidor para o seu navegador?
- Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
- Quantos bytes de conteúdo são baixados pelo seu navegador?
- Encontre a mensagem Redes de Computadores IFSC - SJ - Telecomunicacoes! - Pagina de teste. Onde (em qual campo) encontra-se?
- Qual a diferença entre os endereços IP e porta de origem e destino entre a mensagem GET e a de resposta do HTTP?
Interação Básica GET/Resposta do HTTP usando TELNET e REQUISIÇÃO MANUAL
- Vamos repetir o acesso aos links acima, porém sem usar o navegador. A ideia é que nós façamos o papel de navegador. Isso deve ser feito com os seguintes passos:
- Coloque o Wireshark para capturar pacotes
- Abra um terminal de texto no Linux.
- Execute este comando:
telnet -4 redes.sj.ifsc.edu.br 80
- Após aparecer esta linha: digite o seguinte:
Trying 200.135.37.75... Connected to redes.sj.ifsc.edu.br. Escape character is '^]'.
GET / HTTP/1.0 <Enter> <Enter>
- Pare a captura de pacotes.
- Identifique a página html que foi enviada como resposta. Respeita o protocolo HTTP (observe o cabeçalho)?
- No Wireshark compare o resultado das execuções desses comandos com o que se viu nas capturas Wireshark com acesso pelo navegador, em resumo, compare a troca de mensagens via navegador e terminal (cabeçalhos). Qual a diferença em cada caso?
- Quanto tempo levou para fechar a conexão (após o duplo Enter)?
- Refaça um pedido em que o recurso é inexistente no servidor (ex: página html com nome/URL inexistente). Observe a resposta. Qual é o código da mensagem recebida?
- Refaça a conexão com o servidor:
telnet -4 redes.sj.ifsc.edu.br 80
- Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:
GET / HTTP/1.1 HOST: redes.sj.ifsc.edu.br <Enter>/<Enter>
- Quanto tempo levou para fechar a conexão (após o duplo Enter)?
- Refaça o pedido, mas agora utilizando o HTTP/1.1, e tente inferir a diferença da versão 1.0. Note que o GET nesta versão deve ser realizado com o campo Host:
- Refaça a conexão com o servidor:
telnet -4 redes.sj.ifsc.edu.br 80
- Refaça o pedido, mas agora utilizando o HTTP/1.1:
GET / HTTP/1.1 HOST: redes.sj.ifsc.edu.br <Enter>/<Enter>
- Seja rápido. Antes do fechamento da conexão, faça um novo pedido na conexão já aberta:
GET /Redes_arq1.html HTTP/1.1 Host: redes.sj.ifsc.edu.br <Enter>/<Enter>
- Refaça o pedido, mas agora utilizando o HTTP/1.1:
- O que explica a diferença de tempo para fechamento de conexão entre as versões HTTP 1.0 e 1.1?
- Descreva qual seria o procedimento para o download de dois objetos, via telnet, nos protocolos HTTP 1.0 e 1.1?
Desvendando o HTTP com Wireshark, parte 2
Objetivos
- Explorar vários aspectos do protocolo HTTP:
- A requisição condicional.
- Formatos de mensagens HTTP.
- Os processos e protocolos envolvidos ao baixar arquivos grandes em HTML.
- Os processos envolvidos ao baixar arquivos em HTML com objetos incluídos.
A Interação HTTP GET Condicional/Resposta
- A maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
- Inicie o navegador web;
- Limpe o cache do seu navegador (Ctrl + Shift + Del);
- Inicie o Wireshark;
- Digite o URL no navegador http://redes.sj.ifsc.edu.br. 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);
- No Wireshark 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. Você deve ter obtido algo como apresentado na Figura 1;
- Responda às seguintes questões:
- Inspecione o conteúdo da primeira mensagem - HTTP GET - do seu navegador para o servidor redes.sj.ifsc.edu.br. Você vê uma linha “If-Modified-Since”?
- Inspecione o conteúdo da resposta do servidor, segunda mensagem. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
- Agora inspecione o conteúdo da terceira 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 à terceira mensagem HTTP GET? É diferente do código de retorno da primeira mensagem? Qual é o código?
- Na terceira resposta, o servidor retornou explicitamente o conteúdo do arquivo? Explique.
- Qual o tamanho da primeira e terceira mensagem de retorno (respostas) do servidor?
Baixando Documentos Longos
Antes de qualquer experimento deve-se desabilitar algumas funcionalidades do kernel do LINUX, para que os experimentos reflitam a teoria.
Caso sua interface de rede não seja a eth0 adapte o comando substituindo eth0 pelo nome da sua interface de rede:
sudo ethtool --offload eth0 gso off tso off sg off gro off
Despreze a mensagem de erro
- 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 (Ctrl + Shift + Del);
- Inicie o Wireshark;
- Digite o URL no navegador http://redes.sj.ifsc.edu.br/Redes_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, clique sobre a resposta do servidor (200 OK (text/html))
- Na janela de detalhes do pacote, clique sobre o nono ".... Reassembled TCP Segments"
- 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 série de linhas de cabeçalho, seguida por uma linha em branco, seguida pela carga útil (Content-Length). Nessa resposta, a carga útil do arquivo em HTML é bastante longo, e a informação de 12049 bytes é muito grande para caber em um único segmento TCP. Assim sendo, a resposta HTTP é 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. Aqui fica evidente a relação entre camadas: Na camada de aplicação uma grande mensagem que é quebrada pela camada de transporte para "dar conta" de fazer o serviço de entrega.
- Responda às seguintes questões:
- Quantas mensagens HTTP GET foram enviadas pelo seu navegador? (desconsidere a requisição e resposta (erro) da mensagem favicon)
- Quantas respostas HTTP sua máquina recebeu?
- 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? Obs.: Observe os campos do cabeçalho de uma resposta HTTP.
- Quantos segmentos TCP foram necessários para obtenção da segun 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 navegador baixa um arquivo principal 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 (Ctrl + Shift + Del);
- Inicie o Wireshark;
- Digite o URL no navegador http://redes.sj.ifsc.edu.br/Redes_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 são conteúdos do arquivo em HTML e nem estão depositadas no mesmo servidor, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. As imagens estão em docente.ifsc.edu.br;
- Digite o URL no navegador http://redes.sj.ifsc.edu.br/Redes_arq4.html. Seu navegador deve exibir um arquivo pequeno em HTML com cinco imagens incluídas. Estas cinco imagens,diferentemente do caso anterior, estão depositadas no próprio sítio navegado;
- 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, separando as respostas para o acesso ao Redes_arq3.html e Redes_arq4.html (6 respostas):
- Quantas mensagens HTTP GET foram enviadas pelo seu navegador em cada acesso? (desconsidere a requisição e resposta (erro) da mensagem favicon)
- Para quais endereços na Internet (URI = Host + URL) estas mensagens foram enviadas em cada acesso?
- Você consegue dizer se o seu navegador baixou imagens com ou sem paralelismo? Explique e diferencie o comportamento em cada um dos casos.
HTTPS
- O Hyper Text Transfer Protocol Secure (HTTPS) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS e permite a transmissão de dados numa conexão criptografada através de certificados digitais.
- Caso tenha interesse em analisar troca de mensagens HTTPS e verificar seus conteúdos siga o roteiro How to Decrypt SSL and TLS Traffic Using Wireshark
Serviço de Nomes (DNS)
Objetivos
O Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
- o lado cliente do DNS e
- uma pequena análise do protocolo
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.
Leitura recomendada
Consulta simples ao DNS gerada a partir de um comando ping
O comando ping pode ser usado tanto com um endereço IP como com um nome de host. Em última instância, ele sempre enviará pacotes para um endereço IP. No caso de ser usado o endereço de host, ele tentará resolver (mapear) este nome em um endereço IP usando um servidor DNS (local). Ele gera uma pergunta para o servidor (ou para os servidores, caso exista mais de um configurado). Esta experiência mostra como verificar os servidores instalados e, através de uma captura de pacote mostra a estrutura dos cabeçalhos DNS.
- Inicialmente consulte e anote quem são os servidores DNS instados na sua máquina. É para estes servidores que serão conduzidas as perguntas DNS. Use a ferramenta nm-tool ou acesso ao arquivo de configuração do sistema:
- cat /etc/resolv.conf
- Prepare o wireshark para capturar pacotes. Feche o mozilla ou qualquer outro software de rede parar evitar tráfego DNS que possa vir a confundi-lo.
- Execute o ping para um endereço de host conhecido
- ping4 -c2 www.ufsc.br
- Pare a captura de pacotes no Wireshark e coloque um filtro de display para mostrar apenas mensagens DNS e de ICMP
- dns || icmp
- Observe os pacotes capturados. Em particular foque no pacote de pergunta que deve ser similar ao mostrado abaixo e deve estar direcionado a um dos servidores DNS. Nos flags do header do pacote DNS é possível observar que é um QUERY (pergunta) a ser resolvido de forma recursiva. A pergunta propriamente dita está no campo QUERIES, onde é colocado o nome a ser resolvido e o tipo do registro solicitado (tipo A) que indica resolução de nome.
- Foque agora um pacote de resposta do servidor para o cliente. Deve ter uma estrutura similar ao mostrado abaixo. Nos flags do header do pacote DNS é possível observar que é uma resposta. A resposta propriamente dita está no campo ANSWERS (ele também repete a pergunta no campo QUERIES). Note que podem haver vários registros (RR) retornados, cada um com um tipo. No exemplo abaixo também é retornada uma lista de servidores autorizados (RR tipo NS). Também é retornado o endereço IP destes servidores através de RRs adicionais do tipo A (inclusive endereços IPv6).
- Perguntas a serem respondidas, baseado nos pacotes "Standard query", "Standard query response" e comandos do terminal:
- Quem são os servidores DNS da sua máquina?
- O ping gerou pergunta para cada um deles?
- Qual o tipo da RR associada a pergunta (Queries). O que significa?
- Qual endereço IP retornado da solicitação da resolução de www.ufsc.br?
- Qual endereço IP usado no ping (ver pacote REQUEST ICMP)?
- Qual protocolo de transporte, camada 4, que foi usado para transportar as mensagens de aplicação DNS?
- No QUERY realizado foi solicitado consulta recursiva. O servidor aceitou esta solicitação? (ver a resposta do servidor)
- Logo após o primeiro ping existe mais uma consulta DNS. Esta pergunta é realizada através de uma mensagem do tipo PTR. O ping está tentando verificar qual é o nome da máquina que realmente está respondendo. É o DNS reverso, nesse tipo de colsulta se fornece um IP e o servidor devolve o nome da máquina.
- Perguntas a serem respondidas:
- Qual o IP que se pretende resolver?
- Qual o nome retornado?
- O nome retornado é www.ufsc.br? Sim ou não? Explique.
Consultas DNS por meio de ferramentas especializadas
- Usando o programa host ou dig, que são executados no terminal, descubra e anote no relatório os endereços IP associados aos seguintes nomes de hosts (máquinas):
- mail.ifsc.edu.br
- www.google.com
- www.gmail.com
- Agora descubra e anote no relatório quem é o servidor DNS responsável por cada um dos domínios (p.e.: ifsc.edu.br) 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
- 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 e anote no relatório quem é o servidor de emails nos seguintes domínios:
- gmail.com
- hotmail.com
- ifsc.edu.br
- Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: ... 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.135.37.65
dig -x 200.135.37.65 +short
- Faça uma consulta iterativa com dig e responda:
dig +trace mail.ru.
- Qual foi o RLD (Root Level Domain) consultado?
- Qual o TLD (Top Level Domain) consultado?
- Qual o SLD (Second Level Domain) consultado?
- Como você sabe que foram esses os LDs consultados?
Algumas consultas AAAA
Vamos expandir um pouco nossos horizontes e fazer algumas consultas envolvendo IPv6.
- No terminal de sua máquina faça uma consulta e responda: qual o endereço IPv6 dos hosts? Por exemplo:
dig AAAA google.com host -t AAAA google.com
- www.ufsc.br
- ipv6.br
- Agora vamos fazer a consulta reversa. Qual é o nome de host dos seguintes endereços? Por exemplo:
dig -x 2600:1419:1e00:38e::356e dig -x 2600:1419:1e00:38e::356e +short host 2600:1419:1e00:38e::356e
- 2801:84:0:2::10
- 2001:12d0:0:126::183:244
- AVANÇADO. Execute somente se tiver curiosidade. Como explicado durante a aula e visto no exercício anterior, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Posto de outro modo, vamos fazer todo o processo de requisição interativa, do exercício anterior, manualmente, ou seja, descobrir quem é o Root Level Domain, o Top Level Domain e o Second Level Domain. Anote no relatório.
- Descubra quem são os servidores raiz (topo de hierarquia DNS):
host -t ns . dig -t ns .
- Escolha um dos servidores TLD listados, e use-o para fazer as consultas. Por exemplo: ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta.
host -v -t a www.sj.ifsc.edu.br. j.root-servers.net.
- 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
- Quantos servidores DNS foram necessários consultar no total?
- Descubra quem são os servidores raiz (topo de hierarquia DNS):
Exemplos de arquivos de um Second Level Domain fictício
- Exemplo de arquivos de configuração de um servidor BIND
/etc/bind/db.redes
$TTL 86400
@ IN SOA ns.redes.edu.br. root (
2016090900 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS ns.redes.edu.br.
@ IN MX 10 mail.redes.edu.br.
$ORIGIN redes.edu.br.
ns IN A 192.168.1.101
www IN A 192.168.1.102
www IN A 192.168.1.103
www IN A 192.168.1.104
www IN A 192.168.1.105
www IN A 192.168.1.106
www IN A 192.168.1.107
mail IN A 192.168.1.109
ftp IN CNAME mail.redes.edu.br.
/etc/bind/db.1.168.192 (Zona reversa)
$TTL 86400
@ IN SOA ns.redes.edu.br. root (
2016090900 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN NS ns.redes.edu.br.
101 IN PTR ns.redes.edu.br.
102 IN PTR www.redes.edu.br.
108 IN PTR ftp.redes.edu.br.
109 IN PTR mail.redes.edu.br.
Camada de Aplicação: Colocando no "ar" aplicações servidoras
Objetivos
- Testar serviços de rede na camada de aplicação.
- Construir uma pequena internet, colocando dois serviços no "ar": um servidor ssh, um servidor DNS e um web server, .
- Uma visão do posicionamento dos "pacotes de aplicação" capturados para cada um destes serviços.
Os serviços são, portanto:
- serviço SSH: Secure Shell, terminal remoto. Permite acessar um computador remoto através de um terminal seguro.
- serviço DNS: Vai permitir a navegação através de nomes de máquinas. Com este serviço vamos configurar o banco de dados de um servidor DNS, BIND. Ele dará suporte a navegação por nomes de máquinas.
- serviço WEB: permite hospedar e acessar remotamente páginas da Internet.
Topologia de rede para experimetação
Servidor SSH
- Vamos usar o simulador Imunes para nos apropriarmos do sentimento do comportamento em camadas em uma rede simples. Construir no Imunes a rede a seguir ou, se preferir, importe o arquivo digitando no terminal:
wget http://redes.sj.ifsc.edu.br/Camada_aplicacao.imn
- Inicie o Imunes e carregue o arquivo salvo (Camada_aplicacao.imn).
- Iniciando a REDE:
Experiment >> Execute
- Executando serviço SSH. O serviço SSH será iniciado no servidor SSH (SSH SERVER).
- Primeiramente vamos atribuir uma senha ao usuário root no servidor SSH, por exemplo, atribua senha root (SSH SERVER) com o seguinte comando no terminal do SSH SERVER (duplo clique sobre a máquina SSH SERVER abre o terminal de comandos da mesma):
passwd
- Durante a digitação da senha, nada é apresentado no terminal, é normal.
- Ao terminar de digitar a senha tecle <enter>. Será solicitado a confirmação da senha com o mesmo procedimento.</enter>
- Em seguida vamos fazer uma pequena configuração no servidor SSH (SSH SERVER), através do comando:
echo PermitRootLogin yes >>/etc/ssh/sshd_config
- Iniciamos o serviço, através do comando:
/etc/init.d/ssh start /etc/init.d/ssh reload
- Confira se o serviço está rodando, através do comando:
ps aux
- Observe se há um processo do tipo, última coluna a direita: /usr/sbin/sshd
- Agora vamos testar a conectividade do serviço fazendo uma acesso remoto, por exemplo, no terminal do pc2 execute:
ssh 10.0.9.10
- Na primeira pergunta responda com yes
- Na segunda pergunta preencha com a senha: root
- Observe e salve que o prompt do seu terminal mudou para root@ssh:~#, isso significa que, apesar de você estar no terminal do pc2, vocês está conectado no SSH SERVER. Tudo que você digitar estará sendo executado no SSH SERVER.
- No terminal do pc2, que na verdade está conectado ao servidor SSH SERVER, vamos deixar um ping testando a conectividade com o próprio pc2:
ping 10.0.8.20
- Primeiramente vamos atribuir uma senha ao usuário root no servidor SSH, por exemplo, atribua senha root (SSH SERVER) com o seguinte comando no terminal do SSH SERVER (duplo clique sobre a máquina SSH SERVER abre o terminal de comandos da mesma):
- Agora vamos capturar pacotes do ssh. Basta usar o Wireshark em qualquer interface onde passam os pacotes. Por exemplo, no router2.
Clique com o direito do mouse sobre o router2 >> Wireshark >> eth0
- Pare o ping.
- Recorte a tela do Wireshark, filtrando os pacotes do ssh. Mostre o encapsulamento de pacotes de aplicação e seu posicionamento na estrutura de pacotes.
- Recorte a tela do Wireshark, filtrando os pacotes do icmp. Comprovando que os pacotes do ping estão passando pelo router2.
- Para encerrar a conexão ao SSH SERVER, no terminal do pc2 digite:
exit
- Observe e salve que o prompt do seu terminal mudou para root@pc2:~#, isso significa que a conexão foi encerrada.
Servidor DNS
Criando um domínio de Internet
- Abra o terminal do DNS_Server, vá até o diretório de configuração do BIND com o comando:
cd /etc/bind
- Defina uma zona, um Second Level Domain, de nome redes.edu.br. Isto é feito editando o arquivo named.conf.default-zones. No terminal do DNS_Server e digite:
nano named.conf.default-zones
- Acrescente ao final do mesmo o seguinte conteúdo:
zone "redes.edu.br" { type master; file "/etc/bind/db.redes"; };
- Ao terminar de editar digite <CRTL> + X, em seguida, Y e <Enter>.
- Este arquivo definirá uma nova zona (domínio) DNS.
Criando a base de dados relativa ao domínio
- Na zona criada atribua endereços IPv4 (A) as máquinas em db.redes:
nano db.redes
- Cole o seguinte conteúdo no arquivo e salve::
$TTL 86400 @ IN SOA ns.redes.edu.br. root ( 2022051200 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL ; @ IN NS ns.redes.edu.br. @ IN MX 10 mail.redes.edu.br. $ORIGIN redes.edu.br. ns IN A 10.0.6.10 www IN A 10.0.9.11 ssh IN A 10.0.9.10 mail IN A 10.0.6.10 apelido IN CNAME mail.redes.edu.br.
- Ao terminar de editar digite <CRTL> + X, em seguida, Y e <Enter>.
- Este arquivo definirá o banco de dados do DNS.
- Reinicie o serviço DNS, através do comando:
/etc/init.d/bind9 restart
- Faça um teste com consulta ao seu servidor com o comando, por exemplo:
dig @localhost www.redes.edu.br
- O resultado obtido deve conter algo do tipo:
;; ANSWER SECTION: www.redes.edu.br. 86400 IN A 10.0.9.11
- O resultado obtido deve conter algo do tipo:
Configurando as máquinas para acessarem o DNS
- Em qualquer máquina que desejar navegar por nomes, declare o servidor DNS_Server como servidor DNS com o seguinte comendo digitado no respectivo terminal:
echo nameserver 10.0.6.10 >> /etc/resolv.conf
- Faça alguns testes simples via ping, por exemplo:
ping www.redes.edu.br ping apelido.redes.edu.br
- Acrescente um novo endereço ao banco de dados: casa.redes.edu.br apontando para o IP 10.0.8.21.
- Prove que o mesmo está funcional, por exemplo, dando um ping casa.redes.edu.br a partir do host ssh.
- No terminal do DNS_Server execute:
dig apelido.redes.edu.br
- Qual foi o resultado obtido?
- Qual o significado?
Servidor WEB
- Preparando uma página HTML para colocar no servidor WEB.
- Páginas da internet são construídas usando o formato HTML.
- Ver aqui o que é uma página HTML e como construir uma página simples.
- No terminal da máquina WEB SERVER entre no diretório diretório /var/www/html:
cd /var/www/html
- Use o editor nano para editar uma página chamada index.html:
nano index.html
- Salve um print com o editor aberto.
- Crie a página com o seguinte conteúdo:
<html> <body> <h1>Redes de Computadores</h1> <p>Pagina teste do aluno Pedro Alvares Cabral da Silva</p> </body> </html>
- Ao terminar de editar digite <Ctrl> + <X> e, em seguida, Y e <Enter>.
- Inicie o SERVIÇO WEB para testar o protocolo HTTP. O servidor WEB irá disponibilizar a página criada para acesso remoto via protocolo HTTP:
/etc/init.d/lighttpd start
- No router2 deixe o Wireshark capturando pacotes.
- Faça um acesso a sua página, a partir do Firefox (cliente HTTP) em um PC cliente de sua escolha:
Clique com o botão direito do mouse sobre, por exemplo, o pc1 Clique sobre Web Browser Digite no navegador: www.redes.edu.br
- Se der erro, verifique se a máquina da qual você está navegando está resolvendo nomes, por exemplo, no terminal fazendo um ping www.redes.edu.br.
- RECORTE a tela com a página em destaque no navegador e cole no relatório.
- Se desejar modificar a página repita os itens 2 e 3.
- Crie uma nova página dentro do diretório /var/www/html:
nano abacaxi.html
- Coloque um conteúdo a seu critério:
<html> <body> <h1>Redes de Computadores</h1> <p>Minha primeira pagina..........</p> </body> </html>
- Ao terminar de editar digite <Ctrl> + <X> e, em seguida, Y e <Enter>.
- Acesse a nova página através do navegador Firefox com o endereço (URL):
http://www.redes.edu.br/abacaxi.html
- RECORTE a tela com a página em destaque no navegador e cole no relatório.
- Salve um print da tela do Wireshark destacando a troca de mensagens HTTP e o conteúdo HTML de uma das páginas acessadas.
- Extra (não obrigatório). Para quem quiser enfeitar sua página html com, por exemplo, imagem, siga o roteiro:
- Baixe a imagem desejada na máquina real, por exemplo, imagem.jpg.
- Abra um terminal da máquina real e, no diretório onde se encontra imagem.jpg, digite:
sudo hcp imagem.jpg web:/var/www/html
- Confira no terminal do WEB SERVER (Imunes) se a imagem está lá:
cd /var/www/html ls -l
- Use a imagem em sua página, seguindo o exemplo em Imagens no HTML.
Comparando sockets UDP e TCP
Objetivos
- Entender o conceito de sockets relacionados aos protocolos UDP e TCP.
- Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a um prédio e o socket do processo é semelhante a uma porta em seu interior. A aplicação reside dentro do prédio e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior do prédio mas tem pouco (ou nenhum) controle sobre o exterior.
- Simultaneamente explora-se os conceitos relativos aos protocolos UDP e TCP, observando-se a quantidade de mensagens necessárias para a troca de uma simples frase textual.
- Observa-se a "agilidade" do UDP e a robustez do TCP.
- Por fim, propõe-se um comparativo entre os dois protocolos da camada de transporte: UDP e TCP.
Leia os slides de 1 à 12 e o 58: Capitulo 3 -- Camada de Transporte
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 TCP
- Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Pode-se dizer que o TCP é realizado em duas etapas:
- Primeiramente eles devem se apresentar, o primeiro socket da Figura abaixo. Isto serve somente para abertura de conexão.
- 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:
Roteiro
- 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.
- Copie o código do programa servidor e salve como TCPServer.py. Pode-se utilizar, por exemplo, o Gedit para editar e salvar o código:
from socket import * serverPort = 33333 serverSocket = socket(AF_INET, SOCK_STREAM) serverSocket.bind(('',serverPort)) #Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1 serverSocket.listen(1) print ('O servidor esta pronto') while 1: #Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket, #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP #entre o clientSocket do cliente e o connectionSocket do servidor. connectionSocket, addr = serverSocket.accept() message = connectionSocket.recv(1024) print (message) messageMaiuscula = message.upper() connectionSocket.send(messageMaiuscula) connectionSocket.close()
- Abra um terminal e execute a aplicação servidor:
python3 TCPServer.py
- Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
- ECopie o código do programa cliente e salve como TCPClient.py.Pode-se utilizar, por exemplo, o Gedit para editar e salvar o código:
- Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas.
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. É 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 = input('Entre com a sentenca em minúsculas: ') #Diferentemente do UDP, aqui não é necessário encaminhar o endereço do servidor, já que este socket #é uma "tubulação" direta entre ambos, basta empurrar dados clientSocket.send(bytes(message, 'utf-8')) modifiedMessage = clientSocket.recv(1024) print('Mensagem do servidor: ', modifiedMessage.decode('utf-8')) clientSocket.close()
- Lembre-se de ajustar ip_do_servidor para o número adequado, ou seja, o IP da máquina onde está rodando o TCPServer.py. Obs.: mantenha as aspas.
- Execute o WireShark. Configure a captura na interface any, use o filtro do tipo: tcp.port==33333.
- Em um novo terminal execute o programa cliente, por hora não digite nada:
python3 TCPClient.py
- Verifique os sockets TCP ativos:
ss -nta | grep -E '33333|Local'
- Você encontrou sockets abertos?
- Quais parâmetros apresentados?
- Você vê a porta 33333 tanto no Local Address quanto no Peer Address, por quê?
- Identifique e "printe" o socket receptivo.
- Obs.: Lembre-se que você está rodando tanto a aplicação servidora quanto cliente na mesma máquina, portanto, você deverá ver o socket do servidor e do cliente.
- Em um terceiro terminal, execute outro programa cliente, por hora não digite nada.
- Verifique os sockets TCP ativos:
ss -nta | grep -E '33333|Local'
- Você encontrou 4 sockets abertos? Como eles estão definidos?
- Obs.: Neste caso você deverá ver o 2 sockets servidor e 2 clientes. O TCP abre um socket servidor para cada socket cliente.
- Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark. Observe se recebeu o retorno das mensagens em maiúscula.
- Pare a captura no Wireshark.
- Perguntas:
- Para cada cliente, as três primeiras mensagens trocadas apresentam a camada de aplicação, sim ou não? Explique. O que elas significam?
- Encontre a frase/palavra escrita enviada ao servidor (minuscula) e a resposta em maíuscula?
- Qual o tamanho, dos pacotes contendo as mensagens: i) Data (camada 5), ii) Header Length (camada 4), iii) Total Length (camada 3). Qual a relação entre estes valores?
- As última 3 mensagens contém o fechamento de conexão, explique-as.
- Qual é o protocolo da camada de transporte nessa troca de mensagens?
- Qual o número identificador de protocolo TCP no pacote IP? Dica: na janela central abra o campo Internet Protocol e procure a string Protocol.
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, há dois processos cliente e servidor que podem ou não rodar em máquinas distintas e se comunicam justamente enviando mensagens via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes.
Roteiro
- Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.
- Escreva (copie) o programa UDPServer.py
#Os comentarios estao propositalmente sem acentuacao, caso contrario, tem-se erro de sintaxe. #Esta linha define que pode-se utilizar sockets dentro do programa from socket import * #Define explicitamente a porta aberta servidor serverPort = 22222 #Cria o socket do servidor, denominado serverSocket. O primeiro parametro indica a familia do endereco, #em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que #o socket eh do tipo SOCK_DGRAM, ou seja, eh um socket UDP. serverSocket = socket(AF_INET, SOCK_DGRAM) #Vincula o numero da porta, nesse caso 22222, ao socket do servidor e "abre a porta". serverSocket.bind(('', serverPort)) print ('O servidor esta pronto para recepcao') #Aguarda indefinidamente por contatos (mensagens) de clientes while 1: message, clientAddress = serverSocket.recvfrom(2048) print (message) #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas. modifiedMessage = message.upper() serverSocket.sendto(modifiedMessage, clientAddress)
- No terminal da máquina execute a aplicação servidor:
python3 UDPServer.py
- Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
- Como cliente, execute em outro terminal: (Ajuste o IP_DEST para o número IP de sua própria máquina)
netcat -u IP_DEST 22222
- Verifique a porta aberta com o comando:
ss -ua
- Identifique e anote o socket aberto.
- Identifique e anote o socket receptivo.
- Rode o WireShark. Configure a captura na interface any, com o filtro: udp.port == 22222.
- No terminal da aplicação cliente digite a mensagem que desejar e espere a resposta do servidor. Funcionou?
- Com o servidor aberto faça duas conexões simultâneas. Pode ser dois terminais rodando a aplicação cliente.
- Em cada uma das aplicações clientes digite um texto, sempre diferente para facilitar a análise no Wireshark.
- Pare a captura de pacotes.
- PERGUNTAS baseadas na captura:
- Em algum momento foi identificado algum procedimento para estabelecimento de conexão?
- Em algum campo do UDP existe numeração de mensagens?
- Qual o número identificador de protocolo UDP no pacote IP? Dica: na janela central abra o campo Internet Protocol e procure a string Protocol.
- Qual é o checksum no pacote (datagrama) UDP? Qual é o formato apresentado? Quantos bits ele possui?
- É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
- Qual foi a sequência numérica do campo Data em seu teste? Qual o significado?
- Qual é o protocolo da camada de transporte nessa troca de mensagens?
- Comparativo entre TCP e UDP:
- Quantas mensagens foram trocadas entre o servidor e o cliente em cada um dos protocolos para atingir o mesmo objetivo?
- O que justifica a diferença na quantidade de mensagens trocadas?
- Discuta as vantagens e desvantagens de cada protocolo.
Desafios extras
- 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.
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 nas necessidade de comunicação a ser feita pela aplicação.
Roteiro
O que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos?
O roteiro será executado sobre máquinas virtuais, através do uso do Imunes.
- Abra um terminal e baixe o aquivo de configuração da rede a ser utilizada e um arquivo auxiliar dos experimentos:
wget -4 http://redes.sj.ifsc.edu.br/TCPxUDP.imn wget -4 http://redes.sj.ifsc.edu.br/seq_num.txt
- Observe o tamanho do arquivo auxiliar transferido, seq_num.txt, ele deve ter exatamente 5327160 bytes (cerca de 5,1 MB). Você pode fazer isso com o comando ls -l.
Transferência utilizando o protocolo TCP
- Execute o Imunes.
- Carregue o arquivo:
File >> Open >> TCPxUDP.imn
- Será apresentada uma simples rede a ser utilizada no experimento, composta de 2 PC com um enlace de 1000 kbps.
- Observe que abaixo do enlace está escrito ber=1000000. BER é bit error rate, ou seja, foi inserido uma taxa de erro de bist no canal como sendo 1/1000000. Isso significa que, em média, a cada 1 milhão de bits que passar pelo canal, 1 bit será perdido/adulterado.
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- No terminal da máquina real (NÃO do Imunes) digite:
sudo hcp seq_num.txt Transmissor:
- Obs.: Esse comando copia o arquivo seq_num.txt para a máquina virtual do Imunes.
- Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.
- Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (scroll) do mouse sobre o terminal desejado do Imunes.
- Na máquina Receptor, do Imunes, execute o Wireshark:
Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0...
- Crie um filtro para monitorar somente o tráfego desejado:
ip.addr==10.0.0.20
- No terminal da máquina Receptor, do Imunes, execute o netcat (nc) (utilize man nc para saber os detalhes das flags utilizadas) que abrirá um socket TCP que ficará aguardando conexão na porta 5555. Os dados recebidos serão salvos (através do direcionamento feito através do símbolo >) em arquivoTCP:
nc -vvnl -p 5555 > arquivoTCP
- No terminal da máquina Transmissor, do Imunes, também execute o netcat mas com o objetivo de transmitir o arquivo seq_num.txt para a outra maquina (Receptor):
time nc -w1 -vvn 10.0.0.21 5555 < seq_num.txt
- No terminal do Transmissor o comando será encerrado e apresentará o tempo de transmissão.
- No terminal do Receptor, após o término do processo, verifique o tamanho do arquivo recebido com o comando "ls -l".
- O tamanho é igual ao do arquivo seq_num.txt?
- Quanto tempo levou para transmiti-lo?
- Analisando a captura de pacotes do WireShark responda:
- Quais as portas origem e destino escolhidas pelo cliente e servidor?
- Qual é o número de sequência, para ambas as máquinas, do primeiro e do último pacote?
- Qual é o número de sequência, para ambas as máquinas, do primeiro e do último ACK?
- Calcule e mostre o procedimento de cálculo do tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos ou descreva a maneira de obtenção do valor. Dica: observe o primeiro e o último número de sequência e faça uma correlação com o tamanho do arquivo.
- Qual é o tamanho do último segmento de dados recebido? Perceba que ele é diferente dos demais, que vem "cheios", que tem tamanho grandes.
- Apresente os segmentos do 3-way handshake e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?
- Apresente os segmentos do fechamento de conexão e analise os campos do cabeçalho, que os identificam. Estão de acordo com a norma apresentada na literatura (em sala de aula)?
Transferência utilizando o protocolo UDP
Caso não tenha fechado o Imunes na Parte 1 (Transferência utilizando o protocolo TCP) feche o Wireshark e vá direto para o Item 5.
- Execute o Imunes.
- Carregue o arquivo:
File >> Open >> TCPxUDP.imn
- Será apresentada uma simples rede a ser utilizada no experimento, composta de 2 PC com um enlace de 1000 kbps.
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.
- Dica: para copiar textos para os terminais do Imunes, copie normalmente o texto, por exemplo, da Wiki, com o <Ctrl> + <C> e cole com <Ctrl> + <Shift> + <V> ou clicando sobre a rodinha (scroll) do mouse sobre o terminal desejado do Imunes.
- No terminal da máquina real (NÃO do Imunes) digite:
sudo hcp seq_num.txt Transmissor:
- Na máquina Receptor, do Imunes, execute o Wireshark:
Clique sobre o ícone da máquina Receptor com o botão direito do mouse >> Wireshark >> eth0...
- Crie um filtro para monitorar somente o tráfego desejado:
ip.addr==10.0.0.20 and udp
- Na máquina Receptor, do Imunes, execute o netcat (nc) que abrirá um socket UDP que ficará aguardando segmentos na porta 6666. Os dados recebidos serão salvos em arquivoUDP:
nc -vvnlu -p 6666 > arquivoUDP
- Na máquina Transmissor, do Imunes, também execute o netcat mas com o objetivo de transmitir o arquivo seq_num.txt para a outra maquina (Receptor):
time nc -w1 -vvnu 10.0.0.21 6666 < seq_num.txt
- No terminal do Transmissor o comando será encerrado e apresentará o tempo de transmissão.
- No terminal do Receptor, verifique o tamanho do arquivo recebido com o comando "ls -l".
- O tamanho é igual ao do arquivo seq_num.txt?
- Quanto tempo levou para transmiti-lo?
- Analisando a captura de pacotes do WireShark responda:
- Qual é o identificador (número de sequência) do primeiro e do último pacote? Existe?
- É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
- Compare as transferências feitas com os protocolos TCP e UDP em relação, principalmente, ao tempo gasto para transmitir o arquivo e a integridade de dados.
- 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?
Desvendando o TCP - Número de Sequência, Controle de Erros, Transmissão Full-Duplex
Objetivos
- Verificar alguns mecanismos do protocolo TCP:
- Controle de Erros: Significado de Número de Sequência, ACK;
- Controle de Fluxo: Significado do campo Windows Size; Funcionamento do controle de fluxo;
- Transmissão Full-Duplex.
Topologia de rede para experimetação
- O roteiro será executado sobre máquinas virtuais, através do uso do Imunes.
- Abra um terminal e baixe o aquivo de configuração da rede a ser utilizada e um arquivo auxiliar dos experimentos:
cd ~ wget -4 http://redes.sj.ifsc.edu.br/TCP_Num_Seq_Erro.imn wget -4 http://redes.sj.ifsc.edu.br/arq30Bytes.txt wget -4 http://redes.sj.ifsc.edu.br/Servidor.txt wget -4 http://redes.sj.ifsc.edu.br/Cliente.txt
PARTE 1 - Transmissão sem erros: Verificação de Número de Sequência e Reconhecimentos
- Execute o Imunes.
- Carregue o arquivo:
File >> Open >> TCP_Num_Seq_Erro.imn
- Será apresentada uma simples rede a ser utilizada no experimento, composta de 2 PCs: Transmissor e Receptor.
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.
- Copie o arquivo arq30Bytes.txt para a máquina Transmissor do Imunes. No terminal da máquina hospedeira (NÃO do Imunes) digite:
sudo hcp arq30Bytes.txt Transmissor:
- Execute o Wireshark no Receptor:
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0..
- No terminal do Receptor , execute o processo servidor e prepare o mesmo para limitar a sua capacidade de recepção em cerca de 20 bytes (tamanho do buffer). Isto permitirá ver a quebra do arquivo de 30 bytes em alguns segmentos TCP:
sysctl -w net.ipv4.tcp_rmem='20 20 20' nc -vvnl -p 5555 > ArqRecebido.txt
- Dica: para copiar textos para o Imunes, copie normalmente o texto, por exemplo, da Wiki, com o < Ctrl > + < C > e cole com < Ctrl > + < Shift > + < V > ou clicando sobre a rodinha (scroll) do mouse.
- No terminal, envie o arquivo arq30Bytes.txt da máquina Transmissor:
nc -vvn 10.0.0.21 5555 < arq30Bytes.txt
- Pare os processos rodando nos terminais do Transmissor e Receptor com:
Ctrl + c
- Pare a captura de pacotes no Wireshark.
- Na tela do Wireshark você terá algo parecido com o apresentado na Figura 1.
- Analise como os dados foram transmitidos e reconhecidos.
- Perguntas
- Qual o número de sequência de cada segmento de dados transmitido (do Transmissor para o Receptor) e qual o significado do número de reconhecimento em cada um deles?
- Como foi reconhecido cada segmento enviado? É igual ao número de sequência ou é um número acima? Justifique.
- Qual o significado, funcionalidade e necessidade das mensagens, inseridas pelo Wireshark, "TCP ZeroWindow" e "TCP Window Update"?
- Qual a relação entre os campos "Len=", "Seq=", "Ack=", "Win=" e o tamanho do segmento de dados?
- O primeiro número de sequência na cadeia de bytes que o TCP transmite, é obtido aleatoriamente entre as mais de 4 bilhões de possibilidades (32 bits), ou seja, quase nunca inicia em 0 (zero). Por outro lado, o comportamento padrão do Wireshark é redefinir esse número de sequência, para sempre iniciar em 0 (zero), para facilitar a leitura humana. Este comportamento pode ser alterado, conforme nossas necessidades, com o seguinte procedimento:
Edit >> Preferences >> Protocols >> TCP >> (Habilite/Desabilite) ''Relative sequence numbers'' >> OK
- Desabilite esse comportamento e observe a anote (print) os números de sequência reais e compare com os números de sequência apresentados anteriormente (iniciando em zero) pelo Wireshark.
- Habilite novamente o número de sequência relativo.
- Pare o experimento no Imunes:
Experiment >> Terminate
PARTE 2 - Transmissão com erros: retransmissões
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- Dica: para abrir um terminal de uma das máquinas da rede a ser simulada basta dar um duplo clique sobre a mesma.
- Copie o arquivo seq_num.txt para a máquina Transmissor do Imunes. No terminal da máquina hospedeira (NÃO do Imunes) digite::
sudo hcp Servidor.txt Transmissor:
- Execute o Wireshark no Receptor:
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0..
- Adicione o filtro tcp ao Wireshark, para limpar os dados apresentados, por enquanto nada aparece no Wireshark, já que não há pacotes sendo transmitidos.
- Vamos provocar perda de bits no enlace editando o BER do mesmo. BER é bit error rate, ou seja, foi inserido uma taxa de erro de bist no canal como sendo 15000. Isso significa que, em média, a cada 15 mil bits que passarem pelo canal, 1 bit será perdido/adulterado.
Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 15000 no campo BER >> Clique em ''Apply''
- No terminal do Receptor, limite o buffer de recepção e execute o processo servidor:
sysctl -w net.ipv4.tcp_rmem='5000 5000 5000' nc -vvnl -p 5555 > ArqRecebido.txt
- Envie o arquivo seq_num.txt da máquina Transmissor, no terminal digite:
nc -vvn 10.0.0.21 5555 < Servidor.txt
- Obs: Caso receba uma mensagem "No route to host", repita o comando acima. O problema é gerado por perdas sucessivas de mensagens de estabelecimento de conexão do TCP, devido à perda de dados estabelecida.
- Monitore o Wireshark e, quando perceber um ACK com tamanho um pouco maior de 42000, pare os processos rodando nos terminais do Transmissor e Receptor com:
Ctrl + c
- Analise como os dados foram transmitidos e reconhecidos.
- Perguntas:
- Houve perda de pacotes? Como você identificou isso?
- Os pacotes perdidos foram retransmitidos? Justifique.
- Qual o significado da mensagem, inserida pelo Wireshark, "TCP Retransmission"? Como você justificaria uma perda de segmento sem acesso a essa informação?
- Qual o significado das cores diferenciadas, inseridas pelo Wireshark, nos diversos segmentos apresentados?
- Pare o experimento no Imunes:
Experiment >> Terminate
PARTE 3 - Testando a capacidade do TCP de enviar dados de forma duplex
- Agora vamos fazer um pequeno teste de transmissão de arquivos entre dois colegas e observar o comportamento full-duplex.
- No experimento, o arquivo de uma máquina será transmitido para outra e vice-versa.
- Inicie a simulação da rede no Imunes:
Experiment >> Execute
- Vamos zerar perda de bits no enlace editando o BER do mesmo.
Duplo clique sobre o enlace (fio vermelho) >> acrescente o valor 0 no campo BER >> Clique em ''Apply''
- Copie os arquivos para as máquinas do Imunes. No terminal da máquina hospedeira/Linux (NÃO do Imunes) digite:
sudo hcp Servidor.txt Transmissor: sudo hcp Cliente.txt Receptor:
- Execute o Wireshark no Receptor:
Clique direito do mouse sobre o ícone do Receptor >> Wireshark >> eth0..
- Limite o tamanho do buffer do TCP tanto no Transmissor quanto Receptor, nos seus terminais digite:
sysctl -w net.ipv4.tcp_rmem='10000 10000 10000'
- No terminal do Transmissor, que fará o papel de servidor por aguardar a conexão do cliente, execute o comando abaixo. Perceba que o Servidor vai enviar (o sinal < indica isso) um arquivo e vai receber e salvar (o sinal > indica isso) outro do Cliente.
nc -vvnl -p 5555 < Servidor.txt > Arq_recebido.txt
- No terminal do Receptor, que fará o papel de cliente, execute o comando abaixo. Perceba que ele também vai enviar e receber arquivo do servidor.
nc -vvn 10.0.0.20 5555 < Cliente.txt > Arq_recebido.txt
- Pare os processos rodando nos terminais do Transmissor e Receptor com:
Ctrl + c
- Confira o conteúdo dos arquivos recebidos no Transmissor e Receptor:
cat Arq_recebido.txt
- Os arquivos foram corretamente trocados entre as duas máquinas? Dica: Responda observando o conteúdo dos arquivos, que são exclusivos e bem criativos :).
- Pare a captura de pacotes no Wireshark.
- Adicione o filtro tcp ao Wireshark, para limpar os dados apresentados.
- Analise como os dados foram transmitidos e reconhecidos.
- Perguntas:
- Onde pode ser observado a comunicação full-duplex? Obs.: Foque a análise nos segmentos que contém [PSH, ACK].
- Qual é a relação entre os comandos no terminal tanto do cliente como do servidor com a comunicação full-duplex?
- Como os ACKs são propagados, em pacotes exclusivos ou de carona (piggyback) com os dados?
TCP: Controle de congestionamento e equidade
Objetivos
- Visualização, através de gráficos, do controle de congestionamento e a consequente equidade do protocolo TCP.
- Visualização, através de gráficos, da disputa por banda entre os protocolos TCP e UDP.
- Utilização do software Iperf (iperf –h para help) para gerar tráfego entre duas máquinas - cliente e servidor - e permitir a observação do comportamento da disputa de banda.
- Utilização do software Imunes para simulação de redes "complexas".
Topologia de rede para experimetação
- O roteiro será executado sobre máquinas virtuais, através do uso do Imunes.
- Para realização dos ensaios será montada a rede virtual apresentada na Figura.
- Observe que na figura todos os enlaces são iguais e limitados a 1 Mbps com delay de 5 us.
- Os dois clientes vão disputar o enlace único entre o roteador e servidor.
Parte 1: Somente fluxos TCP
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/TCP_Controle_de_congestionamento_e_equidade.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/TCP_Controle_de_congestionamento_e_equidade.imn
- Perceba que será apresentada uma rede com um roteador, dois clientes e um servidor de rede. Todos interligados por enlaces de 1 Mbps.
- Inicie a simulação no Imunes:
Experiment >> Execute
- Limite o tamanho do buffer do TCP tanto no Servidor quanto no Cliente1:
sysctl -w net.ipv4.tcp_rmem='10000 10000 10000'
- Para copiar comando para os terminais das máquinas virtuais: copie o texto desejado, selecione o terminal da máquina desejada (duplo clique sobre a mesma) e clique sobre a "rodinha" do mouse que o texto será colado.
- No Servidor execute:
iperf -s -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 &
- No Roteador execute o Wireshark:
Clique com o botão direito do mouse sobre o Roteador >> Wireshark >> eth2...
- No Cliente1 execute (copie a três linhas e cole no terminal adequado e em seguida tecle <Enter>):
iperf -c 10.0.2.10 -f m -i 1 -t 50 -p 2000 & \ (sleep 5 && iperf -c 10.0.2.10 -f m -i 1 -t 40 -p 2001) & \ (sleep 10 && iperf -c 10.0.2.10 -f m -i 1 -t 20 -p 2002) &
- Fique monitorando o Cliente1 até a tela parar de ser atualizada, aproximadamente 50 s.
- Pare os processos no Cliente1 e Servidor utilizando CTRL-C.
- Pare a captura de dados no Wireshark.
- No wireshark acesse Statistics >> IO Graph e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura 2:
- Clique em Add a new graph (sinal de + no canto inferior esquerdo)
- X Enabled
- No Graph 2 altere o filtro (Duplo clique sobre o campo Display Filter) para tcp.port==2000.
- No Graph 3 altere o filtro para tcp.port==2001.
- No Graph 4 altere o filtro para tcp.port==2002.
- Clique em Add a new graph (sinal de + no canto inferior esquerdo)
- Salve esse gráfico no relatório.
- Responda:
- Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
- Explique os filtros aplicados no gráfico do Wireshark.
- Quais são os 4 gráficos apresentados?
- Há uma relação de valor entre as curvas?
- Qual é esta relação?
- Por que a curva vermelha se sobrepõe a curva preta nos primeiros 5 segundos, a partir do início da transmissão?
- Qual é a relação entre a curva preta e as curvas vermelha e verde no intervalo entre 6 e 10 segundos, a partir do início da transmissão?
- Explique a relação entre as 4 curvas e o comando do cliente no intervalo entre 10 e 30 segundos, a partir do início da transmissão.
- Qual é o mecanismo do TCP que explica a grande oscilação das curvas, principalmente percebida no intervalo entre 10 e 30 segundos, a partir do início da transmissão?
- Pare a simulação no Imunes:
Experiment >> Terminate
Parte 2: Fluxos TCP mais UDP
Agora vamos dificultar a vida do TCP incluindo um tráfego UDP. O gráfico gerado deverá apresentar a competição pelo meio de transmissão entre os diversos fluxos de dados.
- Inicie a simulação no Imunes:
Experiment >> Execute
- Limite o tamanho do buffer do TCP no Servidor, Cliente1 e Cliente2:
sysctl -w net.ipv4.tcp_rmem='10000 10000 10000'
- Para copiar comando para os terminais das máquinas virtuais: copie o texto desejado, selecione o terminal da máquina desejada (duplo clique sobre a mesma) e clique sobre a "rodinha" do mouse que o texto será colado.
- No Servidor execute:
iperf -s -u -p 2000 & iperf -s -p 2001 & iperf -s -p 2002 &
- No Roteador execute o Wireshark:
Clique com o botão direito do mouse sobre o Roteador >> Wireshark >> eth2...
- A próxima etapa deve ser executada "simultaneamente" nos Cliente1 e Cliente2.
- Para isso copie o texto abaixo e cole no terminal do Cliente1, ainda NÃO tecle <Enter>:
sleep 5 && iperf -u -c 10.0.2.10 -f m -i 1 -t 25 -p 2000 -b 10000000
- Copie o texto abaixo e cole no terminal do Cliente2, ainda NÃO tecle <Enter>:
iperf -c 10.0.2.10 -f m -i 1 -t 50 -p 2001 & iperf -c 10.0.2.10 -f m -i 1 -t 50 -p 2002
- Tecle <Enter> no Cliente2 e Cliente1, NESSA ORDEM, "simultaneamente".
- Para isso copie o texto abaixo e cole no terminal do Cliente1, ainda NÃO tecle <Enter>:
- Fique monitorando o Cliente2 a tela parar de ser atualizada, aproximadamente 50 s.
- Pare os processos no Cliente1, Cliente2 e Servidor utilizando CTRL-C.
- Pare a captura de dados no Wireshark.
- No wireshark acesse Statistics >> IO Graph e, na tela que abrir, ajuste TODOS os parâmetros para obter um gráfico similar ao apresentado na Figura:
- Clique em Add a new graph (sinal de + no canto inferior esquerdo)
- X Enabled
- No Graph 2 altere o filtro para tcp.analysis.flags.
- No Graph 3 altere o filtro para udp.port==2000.
- No Graph 4 altere o filtro para tcp.port==2001.
- No Graph 5 altere o filtro para tcp.port==2002.
- Clique em Add a new graph (sinal de + no canto inferior esquerdo)
- Salve o gráfico no relatório.
- Responda:
- Explique detalhadamente o significado de cada parâmetro dos comandos acima, tanto do cliente quanto do servidor.
- Qual a relação dos filtros aplicados no gráfico e os comandos executados no terminal.
- Quais são os 5 gráficos apresentados?
- Há uma relação de valor entre as curvas?
- Qual é esta relação?
- O que ocorreu com os fluxos TCP após a entrada do fluxo UDP?
- Em que momento houve erros no TCP? Qual é a relação desse momento com o UDP?
- O que ocorreu com os fluxos TCP após o término do fluxo UDP?
- Como desafio, compare o comportamento dos vários fluxos de dados, nos segundo experimentos, acrescentando mais fluxos UDP e TCP.
Interligação de duas redes através de um roteador
Objetivos
- Introdução ao mundo IP
- Verificação das configurações de interfaces de rede
- Verificação de tabelas de roteamento nos hospedeiros e no roteador
- Verificação de movimentação de pacotes (rotas) em roteadores
Referências
Topologia de rede para experimetação
Procedimento
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/Roteador_com_duas_redes.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/Roteador_com_duas_redes.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Ignore (dismiss) a mensagem de erro apresentada. O erro é proposital.
- Observe que a rede é composta de 4 PCs (pc1 - pc4), 1 roteador (router1) e 2 switchs. O roteador possui duas interfaces de rede, com seus respectivos IPs - camada 3, que interliga as duas sub-redes. Cada switch tem 3 interfaces, mas sem IPs, camada 2.
- Anotar os endereços de hardware (ou MAC) e IP de cada dispositivo na rede. No terminal de cada PC execute: ou
ifconfig
ip a
- Observar, interpretar e anotar a tabela de roteamento em todos os hospedeiros pc1 - pc4 e no roteador router1. Identificar os default gateways em cada PC.
route
- Observar, "provar" e anotar que pacotes indo do pc1 para pc2 são enviados diretamente para pc2, ou seja, entrega direta. Explique a entrega direta.
- Deixe o ping entre pc1 e pc2 executando no pc1:
ping 10.0.0.21
- No router1 capture pacotes com o Wireshark na interface eth0:
Clique com o botão direito do mouse sobre o router1 >> Wireshark >> eth0...
- Observe que não há tráfego de pacotes no router1, portanto, entrega direta.
- Deixe o ping entre pc1 e pc2 executando no pc1:
- Observar, "provar" e anotar que pacotes indo de pc1 para pc4 são encaminhados ao roteador e, em seguida, entregues ao destino, ou seja, entrega indireta.
- Explique a entrega indireta.
Configuração básica de interface de rede
- No pc3 teste a conectividade com os demais PCs, por exemplo, fazendo pings para o pc1 e pc4:
ping 10.0.0.20 ping 10.0.1.21
- Perceba que não há conectividade, não há resposta aos pings, dado que a interface de rede do pc3 não está devidamente configurada.
- Assim sendo, configure a interface de rede no pc3.
- Anote todos os comandos executados.
- Inicie configurando o IP com o comando ifconfig (man ifconfig) ou ip a (man ip). Dica: Observe a configuração de rede do pc4, que está na mesma sub-rede, e tente adaptá-la para o pc3.
- Assim que a configuração do IP for bem sucedida o ping para o pc4 deverá funcionar.
- Tente "pingar" para o pc1. Ainda não haverá sucesso, pois não há um roteador devidamente configurado no pc3.
- Configure o roteador no pc3 com o comando route (man route).
- Assim que a configuração do roteador for bem sucedida o ping para o pc1, e qualquer outro PC da rede, deverá funcionar.
- O mesmo deverá ser capaz de "pingar" para qualquer outro PC ou ser "pingado".
- Execute o comando ping do pc3 para o pc4. Obteve sucesso? Se não corrija as configurações.
- Execute o comando ping do pc3 para o pc1. Obteve sucesso? Se não corrija as configurações.
- Execute o comando ping do pc2 para o pc3. Obteve sucesso? Se não corrija as configurações.
Tabelas Estáticas de Roteamento
Objetivos
- Analisar o funcionamento de roteadores com tabelas estáticas de roteamento.
- Verificar a entrega direta e indireta de pacotes.
- Analisar loops em rede.
Topologia de rede para experimetação
Em todos os experimentos será utilizado como base a seguinte topologia de rede:
Tabelas estáticas de roteamento
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/3_roteadores_tab_estaticas.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/3_roteadores_tab_estaticas.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Observe que a rede é composta de 3 PCs (pc0 - pc2) e 3 roteadores roteador (R0 - R2).
- Testes de conectividade de enlace e configuração do default gateway.
- Por exemplo, no pc0 execute o comando: Obteve sucesso? Sim ou não e por quê?
ping 10.0.0.1
- Teste a conectividade do pc0 executando o comando: Obteve sucesso? Sim ou não e por quê? Qual foi o erro observado?
ping 10.0.10.1
- Por exemplo, no pc0 execute o comando: Obteve sucesso? Sim ou não e por quê? Qual foi o erro observado?
ping 10.0.10.2
- Configure o roteador padrão em todos os PCs. Adapte o comando exemplo do pc0 para todos os PCs:
route add -net default gw 10.0.0.1
- Com este comando estamos: i) adicionando (add) uma rota ii) do tipo rede (net) iii) rota padrão (default), que é equivalente a 0.0.0.0 iv) com o roteador (gw - gateway) v) 10.0.0.1 que identifica a interface do roteador, R0, diretamente conectado ao host pc0, no caso.
- Teste novamente a conectividade, no pc0 execute o comando: e
ping 10.0.10.1
Obteve sucesso? O comportamento foi o mesmo das tentativas anteriores? Sim ou não e por quê? Qual foi o erro observado?ping 10.0.10.2
- Com os ping do item anterior ativos (um a cada tempo) rode o Wireshark no R0 (clique com o botào direito do mouse sobre o R0 e em seguida no menu wireshark eth0).
- Qual a origem e destino dos pacotes? Explique?
- Qual a diferença no ping entre os dois itens?
- Por exemplo, no pc0 execute o comando:
- Iniciando o roteamento.
- Deixe o ping do do pc0 para o R1 e o wireshark - eth0 no R0 rodando e estabeleça uma rota no roteador R1 com o comando: O que ocorreu com o ping e o wireshark? Por quê?
route add -net 10.0.0.0/24 gw 10.0.10.1
- Com este comando estamos: i) adicionando (add) uma rota ii) do tipo rede (net) iii) para a rede 10.0.0.0/24 iv) com o roteador (gw - gateway) v) 10.0.10.1 que identifica a interface do roteador, R0, diretamente conectado ao roteador R1.
- Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes", não diretamente conectadas. Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes diretamente conectadas ao equipamento, ou seja, entrega direta. Se tudo estiver correto, todos os PCs e roteadores devem pingar entre si.
- Crie rotas sempre pelo caminho mais curto, por exemplo, do R0 para a rede do pc1 e pc2 passando por R1 e para R2 respectivamente.
- Trace e anote as rotas entre os hosts através do traceroute.
- Deixe o ping do do pc0 para o R1 e o wireshark - eth0 no R0 rodando e estabeleça uma rota no roteador R1 com o comando:
- Testando a queda de enlace.
- Com todas as rotas em perfeito funcionamento, gere um ping do pc0 para o pc2 e execute wireshark eth0 no R0 , em seguida "derrube" o enlace entre o R0 e R2. Por exemplo, no R2 execute o comando: ou
ifconfig eth1 down
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?ip link set eth1 down
- Com todas as rotas em perfeito funcionamento, gere um ping do pc0 para o pc2 e execute wireshark eth0 no R0 , em seguida "derrube" o enlace entre o R0 e R2. Por exemplo, no R2 execute o comando:
- Pare e saia do experimento no Imunes:
Experiment >> Terminate File >> Close
Testando campo TTL com loop na rede
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/3_roteadores_tab_estaticas_com_loop.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/3_roteadores_tab_estaticas_com_loop.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Execute o Wireshark na interface eth1 do R0 e R2 e na eth2 do R1.
- Gere um tráfego único a partir do pc0 para o pc2:
ping -c1 10.0.2.20
- Pare a captura em todos os Wiresharks.
- Qual mensagem de erro foi recebida no terminal do pc0?
- Analisando as capturas dos Wireshark responda:
- Aproximadamente em qual roteador o pacote foi descartado? Procure pelo menor valor de ttl.
- Qual o significado da linha, apresentada no terminal do pc0, com o seguinte conteúdo parcial: Time-to-live exceeded (Time to live exceeded in transit)?
- Explique qual o objetivo do campo ttl no cabeçalho IP?
Protocolos de roteamento dinâmicos - RIP e OSPF
Objetivo
- Analisar o funcionamento dos protocolos dinâmicos de roteamento RIP e OSPF.
- No funcionamento normal.
- Na queda de um enlace.
- Na recomposição do enlace.
- Comparar o desempenho de ambos os protocolos.
Topologia de rede para experimetação
Parte 1 - RIP
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/3_roteadores_RIP.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/3_roteadores_RIP.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Observe que a rede é composta de 3 PCs (pc0 - pc2) e 3 roteadores roteador (R0 - R2).
- A rede será iniciada plenamente funcional, com os roteadores configurados para rodarem o protocolo RIP.
- Teste a funcionalidade da rede, por exemplo, no pc0 execute o comando:
ping 10.0.2.20
- Anote as rotas do pc0 para o pc1 e pc2:
traceroute 10.0.1.20 traceroute 10.0.2.20
- Anote as tabelas de roteamento de todos os roteadores:
route
- Interprete as tabelas de roteamento, diferenciando entrega direta e indireta.
- Vamos provocar a queda de um enlace, em seguida restabelecer e analisar todo o processo.
- Deixe um ping entre o pc0 e pc2 rodando.
- Deixe o Wireshark rodando na interface eth2 do R2.
- Desative o enlace R0-R2. No R2 execute: ou
ifconfig eth1 down
ip link set eth1 down
- Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum demorar até uns 2-3 minutos.
- Qual o tempo aproximado, medido no relógio, para reativação das repostas do ping?
- Anote o número de sequência do último ping com sucesso antes da "derrubada" do enlace e o primeiro após a retorno da funcionamento normal do ping.
- Anote a nova rota do pc0 para o pc2 e a compare com a mesma rota obtida anteriormente:
traceroute 10.0.2.20
- Anote novamente as tabelas de roteamento de todos os roteadores:
route
- Reative o enlace R0-R2. No R2 execute: ou
ifconfig eth1 up
ip link set eth1 up
- Em algum momento o ping deixou de funcionar?
- Aguarde por volta de uns 2 minutos e anote novamente a rota do pc0 para o pc2:
traceroute 10.0.2.20
- Identifique e aponte as diferenças entre as rotas com e sem a queda de enlace. Obs: estão relacionados com a interface desativada.
- A partir das mensagens do Wireshark responda:
- É possível usar o filtro rip, para limpar a visualização.
- Clique sobre a mensagem e expanda o campo Routing Information Protocol na janela central, será possível visualizar mensagens do tipo IP Address: 10.0.12.0, Metric: 16
- Os roteadores são identificados por seus IPs.
- O campo Metric indica o número de saltos do roteador em questão até a rede destino.
- Tente compreender as mensagens RIPv2 trocadas desde o início explicando-as.
- Justifique/explique o valor das métricas (1, 2, 3, ..., 16).
- Qual o intervalo aproximado na troca de mensagens?
- Qual o número (No.) da mensagem onde a rede apresentou problemas com rotas (obs: retire o filtro rip e procure no número de sequência dos pings (seq) os números anotados no item 15.1).
- Quais e quantas mensagens (número) são trocadas entre os roteadores para restabelecer as rotas?
- Pesquise o significado do endereço 224.0.0.9.
Parte 2 - OSPF
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/3_roteadores_OSPF.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/3_roteadores_OSPF.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Observe que a rede é composta de 3 PCs (pc0 - pc2) e 3 roteadores roteador (R0 - R2).
- A rede será iniciada plenamente funcional, com os roteadores configurados para rodarem o protocolo OSPF.
- Teste a funcionalidade da rede (pode ocorrer um atraso inicial na formação da rotas), por exemplo, no pc0 execute o comando:
ping 10.0.2.20
- Se o ping não funcionar imediatamente aguarde até obter respostas, o protocolo está em ação para determinar as melhores rotas.
- Anote as rotas do pc0 para o pc1 e pc2:
traceroute 10.0.1.20 traceroute 10.0.2.20
- Vamos provocar a queda de um enlace, em seguida restabelecer e analisar todo o processo.
- Deixe um ping entre o pc0 e pc2 rodando.
- Deixe o Wirezhark rodando na interface eth2 do R2.
- Desative o enlace R0-R2. No R2 execute: ou
ifconfig eth1 down
ip link set eth1 down
- Monitorando o ping, aguarde até o retorno das repostas ao mesmo. É comum praticamente não percebermos falhas.
- Anote novamente a rota do pc0 para o pc2:
traceroute 10.0.2.20
- Reative o enlace R0-R2. No R2 execute: ou
ifconfig eth1 up
ip link set eth1 up
- A partir das mensagens do Wireshark responda:
- É possível usar o filtro ospf, para limpar a visualização.
- Perceba que com o protocolo OSPF, diferentemente do RIP, não há trocas periódicas de mensagens do protocolo de roteamento.
- Só haverá trocas quando o protocolo sentir necessidade de alguma mudança de rota, por exemplo, com a queda de um enlace.
- Quais as mensagens trocadas pelo protocolo OSPF são observadas no WireShark? Observe o trecho de mensagens onde não houve respostas ao ping.
- Qual o tempo aproximado para a total recuperação das rotas?
- As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP?
- Explique as mensagens "Hello Packet", "LS Update" e "LS Acknowledge".
- Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Explique?
Neighbor Discovery e roteamento estático no IPv6
Este roteiro foi baseado no material disponível no Livro - Laboratório de IPv6.
Slides de endereçamento IPv6.
Guia didático de endereçamento IPv6 obtido de http://ipv6.br/.
Objetivos do laboratório
- Um primeiro contato com o protocolo IPv6
- Compreender o funcionando do Neighbor Discovery, o equivalente ao ARP (Address Resolution Protocol) do IPv4, que em resumo é uma tabela contendo a relação ente IPs e MACs.
- Aprender configurações básicas de interfaces IPv6 no Linux
- Aprender configurações básicas de rotas IPv6
Introdução teórica
Obs.: texto copiado literalmente de: 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.
Topologia de rede para experimetação
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 IPs que utilizaremos em nosso experimento.
Roteiro de atividades
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/IPv6.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/IPv6.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Ignore a mensagem de erro, o mesmo é proposital.
- Observe que a rede é composta de 4 PCs (pc0 - pc3) e 2 roteadores (R0 - R1) e 1 switch.
- Execute o wireshark em R1:
clique com o botão direito do mouse sobre seu ícone >> Wireshark >> eth0...
- Vamos testar o Neighbor Discovery, anote a saída do comando. A partir do pc2 execute:
ndisc6 -m fc00:2::1 eth0
- Esse comando descobre e retorna o MAC address da interface de rede que possui o endereço IPv6 informado. É equivalente ao protocolo ARP do IPv4.
- Observe que todas as interfaces de rede já estão pré-configuradas, exceto do pc3.
- Vamos adicionar o endereço IPv6 à interface de rede no pc3:
ip addr add fc00:2::21/64 dev eth0
- Faça um ping6 entre o pc3 ao pc2:
ping6 fc00:2::20
- Se tudo estiver devidamente configurado, deve-se obter sucesso no ping entre o pc3 e pc2. Entrega direta ou indireta?
- Faça um ping6 entre o pc3 ao pc0.
- Obteve sucesso? Sim ou não e por quê?
- No pc3 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
- No pc3, liste a tabela de roteamento com o comando:
ip -6 route show
- No pc3, acrescente o default gateway com o seguinte comando:
ip -6 route add default via fc00:2::1 dev eth0
- Confira novamente a tabela de roteamento do pc3.
- Faça novamente um ping6 entre o pc3 ao pc0.
- Obteve sucesso? Sim ou não e por quê?
- Pode-se conferir se as rotas, nos roteadores ou qualquer host, com o comando:
ip -6 route show
- A partir do computador pc0 use o comando traceroute6 e anote a rota para todos os demais PCs.
- Pare a captura no Wireshark.
- Baseado na captura de pacotes do Wireshark explique o processo de descoberta de vizinhança (Neighbor Solicitation - NS e Neighbor Advertisement - NA), citando os endereços de multicast e link local utilizados. Obs.: ao final do roteiro há alguns exemplos de mensagens.
- Numa mensagem do tipo Neighbor Solicitation qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
- Em todos os hosts rode o comando
ip -6 neighbor show
- Qual é a funcionalidade desse comando?
- Qual é o significado do conteúdo dessa tabela?
- A tabela mostrada em cada um dos casos é compatível com o diagrama da rede montado?
- Por que, por exemplo, na tabela do pc2 não há uma referência explícita ao pc0?
- Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.
- Alguns exemplos de campos visualizáveis para uma mensagem do tipo Neighbor Advertisement, presentes nas camadas destacadas:
- Source (camada Ethernet)
- A origem é o endereço MAC da interface do dispositivo que enviou a resposta.
- Protocol (camada Ethernet)
- Indica que a mensagem utiliza IPv6.
- Next header (camada IPv6)
- Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6.
- Source (camada IPv6)
- A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida.
- Destination (camada IPv6)
- Type (camada ICMPv6)
- Indica que a mensagem é do tipo 136 (Neighbor Advertisement).
- Flags (camada ICMPv6)
- Uma mensagem NA possui três flags:
- Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador.
- Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta.
- Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez.
- Target Address (camada ICMPv6)
- Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão.
Path MTU Discovery: mensagem ICMPv6 do tipo packet too big
Este roteiro foi baseado no material disponível no Livro - Laboratório de IPv6.
Objetivos do laboratório
- O objetivo desta experiência é mostrar o funcionamento do mecanismo de descoberta de MTU no IPv6.
Introdução teórica
Obs.: texto copiado literalmente de: Laboratório de IPv6.
O MTU é o tamanho máximo de pacote suportado em um determinado enlace de rede. Caso seja necessário enviar um pacote maior do que o MTU do enlace é necessário fragmentá-lo. No IPv6, a fragmentação dos pacotes é realizada apenas na origem. Este procedimento não é realizado (e nem permitido) em roteadores intermediários, como ocorre no protocolo antigo, o IPv4. Isto tem o intuito de reduzir o custo de processamento nos roteadores, seguindo o princípio de manter a inteligência da Internet nas extremidades da rede. Numa rede IPv6, quem está enviando os pacotes tem então que conhecer o MTU do caminho até o destino. Se o caminho for composto por vários seguimentos com MTUs diferentes, valerá, na prática, o menor deles. Essa informação é obtida por meio do Path MTU Discovery (PMTUD), definido na RFC 1981 (McCann et al., 1996). O processo de PMTUD assume que o MTU de todo o caminho é igual ao do primeiro salto. Caso o tamanho dos pacotes enviados seja maior do que o suportado por algum enlace ao longo do caminho, o roteador irá descartá-lo e enviará uma mensagem ICMPv6 packet too big, contendo tanto a mensagem de erro quanto o valor do MTU do enlace seguinte. Após o recebimento dessa mensagem, o nó de origem passa a limitar o tamanho dos pacotes de acordo com o MTU indicado. Isso é repetido até que o tamanho do pacote seja igual ou inferior ao menor MTU do caminho. Os dispositivos armazenam o MTU para cada destino em uma tabela chamada destination cache, não sendo necessário repetir a descoberta a cada pacote enviado. Caso o pacote seja enviado a um grupo multicast, o tamanho utilizado será o menor MTU de todo o conjunto de destinos. Implementações minimalistas de IPv6 podem não realizar a descoberta de MTU e utilizar 1280 bytes como tamanho máximo para os pacotes.
Roteiro de atividades
- Baixe o arquivo de configuração da rede, no terminal digite:
wget -4 http://redes.sj.ifsc.edu.br/PathMTU.imn
- Execute o Imunes.
- Carregue o arquivo de configuração:
File >> Open >> /home/aluno/PathMTU.imn
- Inicie a simulação no Imunes:
Experiment >> Execute
- Observe que a rede é composta de 2 PCs e 1 roteador.
- Altere o valor de MTU no dispositivo router1:
ip link set eth1 mtu 1400
- Verifique o valor de MTU no dispositivo router1:
ip addr show
- Na interface eth1 deverá constar mtu 1400
- Altere o valor de MTU no dispositivo pc2:
ip link set eth0 mtu 1400
- Verifique o valor de MTU no dispositivo pc2:
ip addr show
- Na interface eth0 deverá constar mtu 1400
- Execute o wireshark no pc1:
clique com o botão direito do mouse sobre seu ícone >> Wireshark >> eth0...
- Abra um terminal no pc1 e verifique a conectividade IPv6 com o pc2:
ping6 -s 1500 -M want -c 4 fc00:1::20
- Veja que o comando ping6, com os parâmetros apresentados, configura os pacotes enviados para conterem 1500 bytes de tamanho, por meio da opção -s 1500, e a interface para permitir a fragmentação de pacotes, utilizando a opção -M want.
- Pare a captura de pacotes e aplique, no Wireshark, o filtro icmpv6.
- Procure pelo pacote Packet Too Big.
- Veja se os dados contidos nos pacotes conferem com a teoria.
- Qual é o tipo (type) e código (code) do pacote? Está de acordo com a teoria? ([1])
- Procure o campo MTU: 1400, qual o significado desta informação?
- Procure pelos pacotes Echo (ping) request.
- Analise os mesmos na camada 3 (IPv6):
- quantos fragmentos os mesmos possuem?
- Qual o tamanho de cada fragmento?
- Onde (máquina) foi realizada a fragmentação?
- Como você chegou a esta conclusão?
- Procure pelos pacotes Echo (ping) reply.
- Eles também estão fragmentados? Prove.
- Qual o sentido dessa fragmentação?
- Analise os mesmos na camada 3 (IPv6):
- Repita todo o experimento, alterando o MTU do enlace a direita para 500.
- Analise a nova fragmentação no wireshark e dê print do resultado.
- Analise a nova fragmentação, é compatível com o MTU de 500?
- Quantos fragmentos são gerados em cada ping?
O resultado mostra que, para a topologia apresentada, o menor valor de MTU ao longo do caminho foi descoberto corretamente a partir do primeiro pacote. Este foi descartado ao chegar em uma rede cujo o limite do MTU era de 1400 bytes. Na sequência, os pacotes foram enviados fragmentados de acordo com o valor de MTU descoberto e passaram a transitar corretamente pela rede.