Redes Multimídia (diário 2015-2)

Redes Multimidia: Diário de Aula 2015-2

Professora: Simara Sonaglio
E-mail: simara.sonaglio@ifsc.edu.br
Encontros: 2a feira/13:30, 4a feira/13:30
Atendimento paralelo: segundas e quartas das 15:40 às 16:40

• Ementa

Bibliografia

• Livros sobre Redes de Computadores (por ordem de preferência):
  • KUROSE, James F. e ROSS, Keith W. Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição. Editora Addison Wesley SP, 2010.
  • Sérgio Colcher, Antônio Tadeu Azevedo Gomes, e Anderson Oliveira da Silva. VoIP: Voz sobre IP. Campus, 1a edição, 2005.
  • STALLINGS, W. Redes e sistemas de comunicação de dados. Editora Elsevier RJ, 2005.
  • TANENBAUM, Andrew S. Redes de Computadores, tradução da quarta edição. Editora Campus RJ, 2003
  • FOROUZAN, Behrouz. Comunicação de Dados e Redes de Computadores, 3a/4a edicão. Editora Bookman, 2004.

Softwares

• Netkit: emulador de redes com máquinas virtuais Linux (UML)

Avaliações

Avaliação 1

Matrícula	Trabalho escrito	Trabalho prático	Nota	Conceito
111207024-9	9,00	10,0	9,50	A
101207046-2	9,00	10,0	9,50	A
121003299-6		9,00	4,50	D
111207033-7	9,00	10,0	9,50	A
092207021-0	8,50	9,50	9,00	A
091207043-9	8,50	9,50	9,00	A
112000696-1	8,50	9,50	9,00	A
112000591-4		9,00	4,50	D
102207018-1		9,00	4,50	D

Avaliação 1 - Recuperação

Matrícula	Nota	Conceito
121003299-6	7,96	B
112000591-4	6,43	C
102207018-1	6,26	C

Avaliação 2

Matrícula	Nota	Conceito
111207024-9	7,00	C
101207046-2		D
121003299-6	7,00	C
111207033-7	7,00	C
092207021-0	8,50	B
091207043-9	8,50	B
112000696-1	8,50	B
112000591-4	7,00	C
102207018-1	7,00	C

Avaliação 2 - Recuperação

Matrícula	Nota	Conceito
101207046-2	6,25	C

Avaliação 3

Matrícula	Nota	Conceito
111207024-9	10,00	A
101207046-2	10,00	A
121003299-6	10,00	A
111207033-7	10,00	A
092207021-0	10,00	A
091207043-9	10,00	A
112000696-1	10,00	A
112000591-4	10,00	A
102207018-1	10,00	A

Conceitos Finais

Matrícula	Conceito
111207024-9	B
101207046-2	B
121003299-6	B
111207033-7	B
092207021-0	A
091207043-9	A
112000696-1	A
112000591-4	B
102207018-1	B

Diário das aulas

Aula 1 - 05/10/15: Apresentação
Slides Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório.

Aula 2 - 07/10/15: Caracterização de midias

Slides Compressão de video Compressão com MPEG-2 Introdução a MPEG-2 Compressão de audio e video Formatos de containers de video (arquivos de video) Uma boa introdução sobre codecs e containers de video Técnicas usadas para compressão de video: Remoção de redundância espacial - codificação intraquadros (ex: JPEG) Remoção de redundância espacial e temporal - codificação intraquadros e interquadros (H.261, MPEG) Remoção de redundância temporal: iniciando com um intraquadro (quadro I), quadros sucessivos contém atualizações relativas a quadros anteriores (quadros P) ou a quadros anteriores e posteriores (quadros B). O conjunto de quadros entre quadros I se chama GOP (Group of Pictures): Exemplos de codecs de video MPEG-2 H-264 XVID Theora Atividade 1) Copie esta imagem para seu computador, e recorte uma parte com dimensões 128x128 pixels (use o gimp). 1.1) Qual o tamanho dessa imagem no formato BMP com 24 bpp ? 1.2) Qual o tamanho dessa imagem no formato PNG ? E no formato JPG ? 1.3) Crie uma nova imagem com dimensões 128x128 pixels e que seja toda preta, e determina seu tamanho nos formatos BMP com 24 bpp, PNG e JPG. 1.4) O que se pode concluir quanto à representação digital das imagens ? 2) Copie este arquivo compactado para seu computador, e em seguida descompacte-o. Note que ele contém um certo número de arquivos de imagem em formato JPG (experimente visualizar alguns deles). 2.1) Crie um video a partir dessas imagens. Esse video estará no formato MPJG (Motion JPG), que nada mais é que as imagens sequencializadas. cd figs mencoder mf://\*.jpg -fps 10 -ovc copy -o video.avi 2.2) Veja o tamanho do arquivo de video, e compare-o com o tamanho total das imagens. Em seguida, reproduza-o com vlc ou mplayer. 2.3) Recodifique o seu arquivo de video usando o codec XVID: mencoder -o video2.avi -ovc xvid -xvidencopts bitrate=1024 -oac copy video.avi ... e observe o tamanho do arquivo de video resultante. Em seguida reproduza-o com vlc ou mplayer. Como você o compara com o video gerado no item 2.2 ? 3) Veja também o tamanho desse arquivo de video, que está codificado com MJPG. 4) Codifique esse video para outros formatos de compressão: MPEG-2: mencoder -o wsm-bonus4.mpg -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=250 -oac copy wsm-bonus4.avi XVID: mencoder -o wsm-bonus4_xvid.avi -ovc xvid -xvidencopts bitrate=250 -oac copy wsm-bonus4.avi H-264: mencoder -o wsm-bonus4_h264.mp4 -ovc x264 -x264encopts pass=1:turbo -oac mp3lame wsm-bonus4.avi mencoder -o sr-h264.mp4 -ovc x264 -x264encopts bitrate=250:pass=2 -oac mp3lame wsm-bonus4.avi Theora: mencoder -o wsm-bonus4_theora.mp4 -of mpeg -ovc lavc -lavcopts vcodec=libtheora:vpass=1:turbo -oac mp3lame wsm-bonus4.avi mencoder -o sr-theora.mp4 -of mpeg -ovc lavc -lavcopts vcodec=libtheora:vpass=2 -oac mp3lame wsm-bonus4.avi 5) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles.

Aula 3 - 14/10/15: Caracterização de midias

Slides Compressão de audio Compressão com MP3 Compressão com Ogg FLAC Speex Técnicas usadas: Remoção de silêncio Uso de psicoacústica Remoção de redundância Atividade 1) Copie este arquivo de audio para seu computador. Escute-o e confira sua qualidade sonora. Veja também o tamanho do arquivo. 2) Codifique esse arquivo com os seguintes codecs: MP3: time lame musica.wav musica.mp3 Ogg: time oggenc -o musica.ogg musica.wav Flac: time flac musica.wav -o musica.flac Speex: time speexenc --bitrate 8 musica.wav musica.spx 3) Toque os arquivos de audio codificados, comparando suas qualidades sonoras. Compare também os tamanhos dos arquivos. Transmissão de dados multimidia Slides Atrasos devido a transmissão O tráfego de midia pode variar o uso de banda dependendo da codificação: A transmissão de dados multimidia está sujeita a alguns fatores, destacando-se: Banda disponível: cada tipo de transmissão demanda uma certa banda mínima (ver o exemplo dos videos gerados na aula anterior, que demandam em torno de 250 kbps). A banda requerida depende do codec, podendo mesmo ser variável (ver figura abaixo). Se a banda disponível na rede não for suficiente, a reprodução dos dados transmitidos não será possível (quer dizer, a reprodução contínua simultânea ao recebimento dos dados). Atrasos fim-a-fim: alguns tipos de transmissão são mais sensíveis a atrasos fim-a-fim, como por exemplo conversações VoIP, porém todas transmissões de dados multimidia apresentam pouca tolerância a variações de atraso. A variação de atraso excessiva causa a perda de sincronismo entre a transmissão e a recepção, impedindo a reprodução contínua dos dados recebidos. Componentes do atraso fim-a-fim O atraso fim-a-fim, contado portanto desde a origem de um pacote até seu destino, se compõe de um conjunto de tempos despendidos ao longo de sua transmissão. Alguns desses tempos são constantes, porém outros são variáveis. Atraso Descrição Tipo Expressão (F: tamanho de um pacote em bytes, B: taxa de bits do link) Transmissão Tempo entre o início da saída do 1o bit até a saída do último bit de um pacote pela interface de rede. Depende basicamente da taxa de bits do link onde se dá a transmissão. Variável (depende do tamanho do pacote) $A_{t}={\frac {F}{B}}$ Propagação Tempo entre a saída do 1o bit de um pacote da interface de rede do equipamento transmissor, e sua chegada na interface de rede do equipamento receptor. Depende basicamente da latência do meio de transmissão. Constante $A_{p}$ Processamento Tempo entre a recepção de um pacote e a ação a ser feita sobre ele dentro de um equipamento de rede (seja encaminhá-lo por outro link, ou entregá-lo a uma aplicação que o consumirá) Usualmente desprezível $A_{x}$ Enfileiramento Tempo de espera de um pacote na fila de saída de uma interface de rede por onde deve ser transmitido. Depende de quantos pacotes (e quantos bytes) estão na sua frente nessa fila. Variável $A_{q}=\sum _{F\in Fila}{\frac {F}{B}}$ No exemplo abaixo, os links LAN (link1, link2, link7 e link8) possuem taxa de 1 Gbps, e os links WAN (demais links) possuem taxa de 10 Mbps. As filas dos roteadores podem conter até 100 pacotes de 1500 bytes (tamanho máximo de pacote). Os links WAN possuem latência de 2 ms (a dos links LAN é desprezível). Sendo assim, calcular o atraso mínimo e máximo que cada pacote pode sofrer entre sua saída do servidor de video e sua chegada no reprodutor. Os pacotes de vídeo têm tamanho de 1500 bytes: Atrasos de transmissão nos links WAN: $A_{wan}={\frac {1500\cdot 8}{10\cdot 10^{6}}}=1,2\cdot 10^{-3}s$ Atrasos de transmissão nos links LAN: $A_{lan}={\frac {1500\cdot 8}{1\cdot 10^{9}}}=12\cdot 10^{-6}s$ Atraso de enfileiramento em roteador: melhor caso (fila vazia) $A_{q}=0~s$ Atraso de enfileiramento em roteador: pior caso (fila cheia): $A_{q}=100\cdot {\frac {1500\cdot 8}{10\cdot 10^{6}}}=120\cdot 10^{-3}s$ O menor atraso pode ser calculado assim: $A_{min}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}=12,848\cdot 10^{-3}s$ ... e o maior atraso possível é: $A_{max}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}+4\cdot A_{q}=492,848\cdot 10^{-3}s$ Com isso, uma transmissão de video nessa rede está sujeita a atrasos máximo de cerca de 492 ms por pacote, e variação de atraso de até $A_{max}-A_{min}=480ms$. Note-se que, nessa rede, a variação de atraso se deve essencialmente a atrasos de enfileiramento nos roteadores. Em outras redes pode haver fatores adicionais para variações de atraso: perdas de pacotes por erros de transmissão ou congestionamento, priorização de pacotes, e até o controle de congestionamento TCP (se esse protocolo for usado para a transmissão). Exercício Mesma topologia, os links LAN (link1, link2, link7 e link8) possuem taxa de 100 Mbps, e os links WAN (demais links) possuem taxa de 5 Mbps. As filas dos roteadores podem conter até 90 pacotes de 1500 bytes (tamanho máximo de pacote). Os links WAN possuem latência de 2 ms (a dos links LAN é desprezível). Sendo assim, calcular o atraso mínimo e máximo que cada pacote pode sofrer entre sua saída do servidor de video e sua chegada no reprodutor. Os pacotes de vídeo têm tamanho de 1500 bytes. O exemplo acima diz respeito a uma pequena rede com bons links WAN e pequeno número de saltos (roteadores intermediários) entre origem e destino. Em um cenário mais realista, como um usuário doméstico acessando videos no Youtube, a situação pode ser bem pior. Para fins de comparação, da rede da escola até o Youtube foram contados 9 saltos, e de casa se contaram 8 saltos (o caso do Youtube é um pouco mais complicado, pois sua infraestrutura é baseada em um tipo de CDN). Se cada pacote está sujeito a um atraso variável, o reprodutor de video no receptor precisa de algum mecanismo para compensar essas variações e apresentar o video de forma contínua. O mesmo raciocínio vale para transmissões de audio. Estratégias para tratar a variação de atraso Mecanismos para compensar atraso e variação de atraso da rede: Numerar cada mensagem com um número de sequência. Registrar o instante em que cada mensagem foi gerada (i.e. registrar seu timestamp). Atrasar a reprodução do conteúdo no receptor, para compensar variações de atraso. Esses mecanismos são combinados nas seguintes estratégias para compensar variação de atraso: Atraso de reprodução fixo Compensa atrasos de mensagens com a imposição de um atraso fixo q no reprodutor de midia. Mensagens recebidas após seu instante de reprodução (i.e. chegam após timestamp + q) são descartados. Atraso de reprodução: midia será tocada somente no instante $p^{'}$, sendo que $p^{'}=p+q$. O atraso q corresponde ao atraso de reprodução imposto do lado do cliente, para compensar variações de atraso das mensagens. Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso fixo: Atraso de reprodução adaptativo Procura minimizar o atraso de reprodução, estimando o atraso da rede e sua variação. O atraso de reprodução assim calculado é imposto no receptor antes de cada rajada de mensagens (isso faz mais sentido em transmissão de voz). Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso adaptativo: Se uma determinada mensagem se atrasar além do tolerável, será descartada (não reproduzida): Exercícios Resolver os exercícios contidos no final das transparências. Estratégias para abrandar a perda de mensagens Reprodução de mensagens perdidas inadequada para aplicações interativas Mensagens que realmente não chegaram Mensagens que chegaram após instante de reprodução Técnicas para abrandar a perda de mensagens e preservar uma boa (?!) qualidade de áudio Correção antecipada de erros (FEC - Forward Error Correction) Intercalação Correção antecipada de erros Emissor envia dados redundantes em suas mensagens, também conhecidos como um código de correção de erro. Exemplo 1: envio de uma mensagem redundante para cada grupo de n mensagens. A mensagem redundante é calculada fazendo XOR das demais mensagens do grupo. Tolera a perda de 1 mensagem Aumento de banda de 1/n Uso de mensagem redundante com XOR Exemplo 2: envio de fluxos redundantes de diferentes qualidades. Pode-se enviar um fluxo de qualidade inferior junto com o fluxo principal. Intercalação Consiste no resequenciamento das unidades de áudio antes de transmiti-las, de forma que unidades que estavam originalmente próximas sejam separadas por uma certa distância no fluxo a ser transmitido. No exemplo abaixo, cada unidade de áudio tem 5 ms, e cada mensagem contém quatro unidades (totalizando 20 ms).

Aula 4 - 19/10/15: Caracterização de midias - Continuação

Atividade Pesquise sobre o uso de técnicas de abrandamento de perdas de mensagens em diferentes tipos de transmissão de midia: VoIP, video, radio on-line, ... Lista de exercícios Os exercícios do capítulo 7 do livro "Redes de Computadores e a Internet, 5a edição", do Kurose, devem ser resolvidos: Exercicios de fixação: 1, 2, 4, 5, 6, 7, 9, 10, 11, 12 Problemas: 5, 7, 8, 9, 10, 12 Data de entrega das duas atividades: 28/10/2015

Aula 5 - 21/10/15: Introdução a Voz sobre IP (VoIP)

Transparências Introdução a VoIP e SIP RFC 3261: Session Initiation Protocol (SIP) Tecnologias VoIP para smartphones QoS for VoIP (Cisco) QoS for VoIP (voip-info) ITU-T G.114: One Way Transmission Time SIP: Understanding the Session Initiation Protocol, 3rd ed (muito bom livro) ... (cópia online) Mensagens, Transações, Diálogos e Chamadas SIP VoIP: transmissão de voz usando protocolos da arquitetura TCP/IP, com o objetivo de estabelecer chamadas semelhantes a chamadas telefônicas. Alguns exemplos de aplicações ou padrões VoIP são: Skype (mais material aqui) Whatsapp Viber SIP (padrão) H.323 (padrão) Uma chamada VoIP entre dois telefones IP é feita através da rede de dados. A realização de chamadas VoIP implica a necessidade de alguns mecanismos: Sinalização: deve haver alguma forma de um usuário iniciar uma chamada para outro usuário, de forma parecida com uma chamada telefônica convencional. A sinalização é responsável por possibilitar que um usuário convide outro para o estabelecimento de uma chamada, e para notificar sobre sua aceitação ou não. Além disso, a sinalização deve participar da definição sobre as características da chamada, tais como o codec de áudio. Transmissão de midia: a voz precisa ser digitalizada com algum codec então transmitida entre os participantes da chamada. O transporte da voz digitalizada implica o uso protocolos capazes de encapsulá-la e de atender ou dar subsídios ao atendimento de seus requisitos de qualidade de serviço (atrasos fim-a-fim e variação de atraso, taxa de perdas). Em RMU será estudado o modelo SIP para VoIP, o qual se compõe de um conjunto de padrões abertos para tratar dos vários aspectos envolvidos na realização de chamadas. Esse modelo, como diz seu nome, tem como principal elemento o protocolo de sinalização SIP (Session Initiation Protocol). O protocolo SIP O protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares. Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, semelhante a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: # Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP) sip:1234@biloxi.example.com # Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to) sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1; maddr=240.101.102.103?Subject=FFT As comunicações SIP seguem uma hierarquia, cujos níveis são: Mensagens: mensagens de texto individuais trocadas entre agentes. Transação: sequência de mensagens entre dois agentes iniciando com uma requisição e terminando com uma resposta final. Diálogo: uma relação entre dois agentes que persiste por algum tempo, e identificada por um Call-ID. Chamada: composta por todos os diálogos originados por um agente. 'Mensagens, transações, diálogos e chamadas Mensagens SIP O protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: Linha inicial Cabeçalho1: valor do cabeçalho 1 Cabeçalho2: valor do cabeçalho 2 ... CabeçalhoN: valor do cabeçalho N <linha em branco> corpo da mensagem (opcional) A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional): Pedido: REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com> Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Contact: <sips:bob@client.biloxi.example.com> Content-Length: 0 Resposta: SIP/2.0 200 OK Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: <sips:bob@client.biloxi.example.com>;expires=3600 Content-Length: 0 O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP. Método SIP Descrição REGISTER Usado por um agente para notificar a rede SIP (outros agentes) sobre sua URI de contato INVITE Usado para estabelecer sessões entre dois agentes ACK Confirma respostas finais a requisições INVITE BYE Termina uma sessão previamente estabelecida CANCEL Encerra tentativas de chamadas OPTIONS Consulta um agente sobre suas capacidades Tabela de métodos SIP (não exaustiva ... apenas os principais métodos) Cabeçalho SIP Descrição Obrigatoriedade Uso Via Registra a rota seguida por uma requisição, sendo usado para que respostas sigam o caminho inverso Requisição e resposta Requisição e resposta To Identifica o destinatário de uma requisição Requisição e resposta Requisição e resposta From Identifica o originador da requisição Requisição e resposta Requisição e resposta Call-Id Identifica univocamente uma chamada entre um UAC e um UAS. Requisição e resposta Requisição e resposta CSeq Numera as requisições de uma mesma chamada de um mesmo UAC Requisição Requisição e resposta Contact Identifica o originador da requisição ou o recurso requisitado Requisição e resposta Max-Forwards Máximo número de saltos que a requisição pode atravessar Requisição Requisição Content-Length Informa a quantidade de bytes do corpo da mensagem Requisição e resposta Date Informa a data e horário de uma requisição ou resposta Requisição e resposta Supported Lista uma ou mais opções suportadas por um UAC ou UAS Requisição e resposta User-Agent Informa sobre o agente (o programa) originador de uma requisição Allow Informa os métodos SIP aceitos pelo UAS Resposta Content-type Informa o tipo de conteúdo contido no corpo da mensagem WWW-Authenticate Informa que o UAC deve se autenticar para o UAS (e como isso deve ser feito) Resposta Authorization Contém as credenciais para autenticar o UAC para o UAS Requisição Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos) Diagramas de chamadas Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. Registro de agente SIP em um proxy SIP Esta chamada ocorre entre um agente SIP e um servidor de registro SIP (SIP Registar), que está implementado tipicamente em um proxy SIP, um gateway de media, ou um PBX IP (este último incorpora as funções dos dois primeiros com as de um PBX). O registro do agente SIP tem por finalidade fazer com que o servidor de registro SIP conheça a localização do agente (endereço IP e port usado pelo UAS). Fone 1 Proxy SIP ou PBX IP | | | REGISTER | |---------------------------->| | 401 Unauthorized | |<----------------------------| | REGISTER | |---------------------------->| | 200 OK | |<----------------------------| | | Chamada direta entre dois agentes SIP Uma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE. Fone 1 Fone 2 | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | RTP Media | |<======================>| | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | | Chamada entre dois agentes SIP com intermediação de um Proxy SIP A principal diferença entre este tipo de chamada e o anterior é o uso de um (ou mais) proxy SIP entre os dois agentes. O proxy SIP tem por finalidade ajudar na realização das chamadas, uma vez que usualmente incorpora a função de servidor de registro. Um proxy SIP encaminha chamadas para o agente chamado, ou para outro proxy mais próximo do destino, podendo aplicar regras de controle de acesso quanto a quem pode realizar chamadas para quem. Fone 1 Proxy SIP ou PBX IP Fone 2 (directmedia=yes) | | | | INVITE | | |--------------->| INVITE | | 100 Trying |--------------->| |<---------------| 100 Trying | | |<---------------| | | | | | 180 Ringing | | 180 Ringing |<---------------| |<---------------| | | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | ACK | | |--------------->| ACK | | |--------------->| | | | | RTP Media | |<===============================>| | | | | | BYE | | BYE |<---------------| |<---------------| | | 200 Ok | | |--------------->| 200 Ok | | |--------------->| | | | | | | Chamada entre dois agentes SIP com intermediação de um gateway de media Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. Fone 1 PBX IP Fone 2 (directmedia=no) | | | | INVITE | | |--------------->| INVITE | | 100 Trying |--------------->| |<---------------| 100 Trying | | |<---------------| | | 180 Ringing | | 180 Ringing |<---------------| |<---------------| | | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | ACK | | |--------------->| ACK | | |--------------->| | RTP Media | RTP Media | |<==============>|<==============>| | BYE | | |--------------->| BYE | | |--------------->| | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | | | Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. Fone 1 PBX IP Fone 2 (directmedia=yes) | | | | INVITE | | |--------------->| INVITE | | 100 Trying |--------------->| |<---------------| 100 Trying | | |<---------------| | | 180 Ringing | | 180 Ringing |<---------------| |<---------------| | | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | ACK | | |--------------->| ACK | | INVITE |--------------->| |<---------------| INVITE | | 200 OK |--------------->| |--------------->| 200 OK | | ACK |<---------------| |--------------->| ACK | | |<---------------| | | | RTP Media | |<===============================>| | BYE | | |--------------->| BYE | | |--------------->| | | 200 Ok | | 200 Ok |<---------------| |<---------------| | | | | Atividade 1: Ligação SIP ponto a ponto O primeiro experimento com uma chamada VoIP envolve estabelecer uma chamada diretamente entre dois softphones. Cada par de alunos deve fazer o seguinte: Executar o Jitsi (ver em Aplicativos->Internet). Execute o wireshark e inicie a captura de datagramas UDP pela interface utilizada. Definir uma conta SIP contendo somente um identificador de usuário (sem a localização). Um dos alunos deve iniciar uma chamada para o outro aluno, que deve atendê-la. Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph) A sequência de passos acima estabelece uma chamada VoIP do tipo mais simples possível. Questões: Quem foram o UAC e UAS nesse experimento ? Quantas requisições SIP foram realizadas para uma chamada completa ? Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ? Qual o CODEC selecionado por cada parte? Onde isso foi feito ? Qual a lista de CODECS suportados?

Aula 6 - 26/10/15: VoIP e introdução ao Asterisk
Transparências Transparências

Aula 7 - 28/10/15: VoIP e introdução ao Asterisk
Transparências Manual do ATA GKM 1000 e GKM 2000 (Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf)

Aula 8 - 04/11/15: Asterisk e Equipamentos IP
Transparências Manual do ATA GKM 1000 e GKM 2000 (Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf) Atividades realizadas Registro de ramais criados no Asterisk da máquina Professor; Testes de chamadas entre ramais; Análise de tráfego de com o Wireshark; Análise de tráfego de áudio com a opção Reinvite habilitada/desabilitada; Instalação do Asterisk nas máquinas virtuais dos alunos.

Aula 9 - 07/11/15: Asterisk e Equipamentos IP

Transparências Manual do ATA GKM 1000 e GKM 2000 (Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf) Atividades a serem realizadas Criar os contextos alunos, professores e coordenacao e contas SIP pertencentes a estes contextos; Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. O mesmo deve ser feito para o contexto professores. Já as contas SIP do contexto coordenacao poderão atingir, além das contas SIP deste contexto, as contas dos contextos alunos e professores; Testes de chamadas entre ramais; Criar um contexto comum a todos os demais contextos e nele criar os próximos dois itens; Criar um número no plano de discagem que seja atendido por uma gravação; Criar um número no plano de discagem que permita fazer uma gravação.

Aula 10 - 09/11/15: Asterisk e Equipamentos IP

Transparências VoIP e RTP Transparências Asterisk Manual do ATA GKM 1000 e GKM 2000 (Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf) Atividades a serem realizadas Criar os contextos alunos, professores e coordenacao e contas SIP pertencentes a estes contextos; Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. O mesmo deve ser feito para o contexto professores. Já as contas SIP do contexto coordenacao poderão atingir, além das contas SIP deste contexto, as contas dos contextos alunos e professores; Testes de chamadas entre ramais; Criar um contexto comum a todos os demais contextos e nele criar os próximos dois itens; Criar um número no plano de discagem que seja atendido por uma gravação; Criar um número no plano de discagem que permita fazer uma gravação. sip.conf [100] type=friend secret=100 host=dynamic context=alunos disallow=all allow=gsm allow=alaw allow=ulaw [101] type=friend secret=101 host=dynamic context=alunos disallow=all allow=gsm allow=alaw allow=ulaw [102] type=friend secret=102 host=dynamic context=professores disallow=all allow=gsm allow=alaw allow=ulaw [103] type=friend secret=103 host=dynamic context=professores disallow=all allow=gsm allow=alaw allow=ulaw [104] type=friend secret=104 host=dynamic context=coordenacao disallow=all allow=gsm allow=alaw allow=ulaw [105] type=friend secret=105 host=dynamic context=coordenacao disallow=all allow=gsm allow=alaw allow=ulaw extensions.conf [alunos] exten=>100,1,Dial(SIP/100,30) exten=>100,2,Hangup exten=>101,1,Dial(SIP/101,30) exten=>101,n,Hangup [professores] exten=>102,1,Dial(SIP/102,30) same=>n,Hangup exten=>103,1,Dial(SIP/103,30) exten=>103,n,Hangup [coordenacao] include=>alunos include=>professores exten=>104,1,Dial(SIP/104,30) same=>n,Hangup exten=>105,1,Dial(SIP/105,30) exten=>105,n,Hangup

Aula 11 - 11/11/2015: interligando PBX Asterisk por meio de troncos SIP

A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e o áudio flui em separado com RTP. No segundo caso, o protocolo IAX2 (Inter-Asterisk eXchange) encapsula tanto a sinalização quanto os fluxos de áudio, o que simplifica o estabelecimento do tronco. Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito. Tronco SIP Em um entroncamento SIP (SIP trunking), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec. A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo: PBX sip.conf extensions.conf Norte [Sul] type=user secret=supersercreta host=IP_PBX_Norte disallow=all allow=ulaw ;canreinvite=no directmedia=no context=troncoSIP qualify=yes [ParaSul] type=peer fromuser=Norte username=Norte secret=supersecreta host=IP_PBX_Sul disallow=all allow=ulaw ;canreinvite=no directmedia=no qualify=yes [troncoSIP] ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => _4XX,1,Dial(SIP/ParaSul/${EXTEN}) same=>n,Hangup Sul [Norte] type=user secret=supersercreta host=IP_PBX_Sul disallow=all allow=ulaw ;canreinvite=no directmedia=no context=troncoSIP qualify=yes [ParaNorte] type=peer fromuser=Sul username=Sul secret=supersecreta host=IP_PBX_Norte disallow=all allow=ulaw ;canreinvite=no directmedia=yes qualify=yes [troncoSIP] ; ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => _2XX,1,Dial(SIP/ParaNorte/${EXTEN}) same=>n,Hangup Outra forma [central1] type=friend ;defaultuser=central2; usuário criado na filial username=central2 host=192.168.25.101 ;ip da filial secret=123 context=geral [central2] type=friend ;defaultuser=central1; usuário criado na matriz username=central1 host=192.168.25.102 ;ip da matriz secret=123 context=geral Atividade: estabelecendo chamadas entre diferentes PBX Asterisk Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com um PBX vizinho.

Aula 12 - 16/11/2015: interligando PBX IP - continuação

Aula 13 - 18/11/2015: Sem aula - eleição reitor

Aula 14 - 23/11/2015: Continuação de interligando PBX IP - IAX

Com reinvite ([[1]]) Sem reinvite ([[2]]) SDP – Session Description Protocol Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP. O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade. De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente “RTP/AVP”), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia. FONTE: Teleco. O transporte de midia com protocolo RTP Transparências Uma FAQ sobre RTP (muito boa) RFC 3550: RTP: A Transport Protocol for Real-Time Applications Capítulo 11 do livro SIP: Understanding the Session Initiation Protocol, 3rd ed Cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose. O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como: Perda de pacotes Atraso fim-a-fim variável Chegada de pacotes fora de ordem Esses problemas não são novidade ... nós já os discutimos nas aulas sobre transmissão de dados multimidia. O que há de novo é um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são: Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP) Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem. Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução). Essas informações fazem parte da PDU RTP, como se pode ver a seguir: Localização do RTP na camada de transporte Cabeçalho RTP RTCP Além do RTP, o protocolo auxiliar RTCP (Real-Time Control Protocol, também definido na RFC 3550) foi definido para o monitoramento da entrega dos pacotes (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o feedback sobre a qualidade da comunicação, incluindo informações como: Número de pacotes enviados e recebidos Número de pacotes perdidos Jitter (variação de atraso) Os cinco tipos de relatórios são: Relatório do transmissor (Sender Report - SR) Relatório do receptor (Receiver Report - RR) Descrição da fonte (Source Description - SDES) Bye Específico da aplicação (Application Specific - APP) Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível. Lista de exercícios (Arquivo:Lista2.pdf)

Aula 15 - 26/11/2015: Início projeto

Aula 16 - 30/11/2015: URA / Projeto - continuação

(Arquivo:Aula-29.pdf Prática com Asterisk) Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo: [default] exten => 666,1,Goto(ura,s,1) [ura] exten => s,1,Answer exten => s,2,NoOp(Ligação entrou na URA) exten => s,n,Background(/var/lib/asterisk/sounds/benvindo) exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro) exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo exten => 1,1,NoOp(Chamada foi para Suporte) same => n,Dial(SIP/2402,60) same => n, Hangup exten => 2,1,NoOp(Chamada foi para Comercial) same => n,Dial(SIP/2801,60) same => n, Hangup exten => 3,1,NoOp(Chamada foi para Financeiro) same => n,Dial(SIP/2000,60) same => n, Hangup exten => i,1,NoOp(Extensão inválida) same => n,Play(beep) same => n,GoTo(s,3); volta para o menu exten => t,1,NoOp(Tempo esgotado) same => n,Dial(SIP/3401,60) same => n,Hangup A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial que atenda por 9005nome_de_um_arquivo. Ao chamar essa estensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar #. O arquivo de voz resultante estará no diretório /var/lib/asterisk/sounds, ou em qualquer outro diretório especificado na aplicação record. exten=_9005.,1,answer() exten=_9005.,n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,t) exten=_9005.,n,playback(/var/lib/asterisk/sounds/${EXTEN:4}) exten=_9005.,n,hangup() Ou: exten=>998,1,Answer same=>n,Wait(1) same=>n,Playback(beep) same=>n,Record(/tmp/novo:wav) same=>n,Playback(beep) same=>n,Playback(/tmp/novo) same=>n,Hangup A implantação de uma URA (e de muitas outras funções típicas de PBX) em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações, variáveis, e características (features). Hoje serão vistos alguns desses recursos, que usaremos para implantar uma URA. Funções usando o plano de discagem Para implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados três deles: extensões especiais, aplicações, padrões de extensões e variáveis. Extensões especiais Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como: s (start): tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico. i (invalid): tem por objetivo tratar entradas inv ́lidas em um menu interativo t (timeout): Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.

Aula 17 - 02/12/2015: Projeto - continuação
(Arquivo:Trabalho1-20152.pdf)

Aula 18 - 07/12/2015: Projeto - continuação
(Arquivo:Trabalho1-20152.pdf)

Aula 19 - 09/12/2015: Projeto - continuação
(Arquivo:Trabalho1-20152.pdf)

Aula 20 - 14/12/2015: Projeto - continuação
Interligação matriz-filial FILIAL [general] register=>filial1:123@200.135.233.x [matriz1] type=friend username=filial1 host=200.135.233.x secret=123 context=geral MATRIZ [filial1] type=friend username=matriz1 host=dynamic secret=123 qualify=yes canreinvite=no context=geral

Aula 21 - 16/12/2015: Projeto - continuação

Aula 22 - 19/12/2015: Projeto - continuação

Aula 23 - 21/12/2015: Projeto - Apresentação e entrega do relatório

Aula 24 - 01/02/2016: Introdução a QoS
Transparências Cisco QoS Concept and Design Tutorial sobre QoS para VoIP Como medir a qualidade de serviço de uma rede ? Disponibilidade ? Largura de banda Latência (atraso fim-a-fim) Variação de atraso (jitter) Perda de pacotes Um comparativo de requisitos de QoS de algumas aplicações Como prover QoS ? Atividade Fazer as duas atividades do final do slide.

Aula 25 - 03/02/2016: QoS em roteador Linux

Provendo QoS: conceitos básicos Transparências Cisco QoS Concept and Design Estudo de caso: WFQ em roteador Cisco Cisco Congestion Management Overview (descreve implementação do WFQ e outros mecanismos) Como PROVER qualidade de serviço em uma rede ? Como classificar os pacotes, para que sejam tratados de acordo com os requisitos de QoS especificados ? Como garantir banda para um determinada classe de tráfego ? Como limitar o uso de banda ? Como limitar o atraso fim-a-fim de pacotes ? Como limitar a variação de atraso (jitter) de pacotes ? Assume-se que a rede considerada seja formada por uma malha de roteadores. Cada interface de um roteador possui uma fila de saída, onde ficam os pacotes à espera de serem transmitidos, como mostrado na figura a seguir. Essas filas possuem tamanho limitado, sendo implementadas por buffers de memória. Para prover QoS, uma primeira necessidade é controlar quando saem pacotes por uma interface (para limitar banda), e a ordem em que pacotes saem (para priorizar pacotes, garantir banda e limitar atrasos). Isso significa atuar principalmente sobre as filas de saída das interfaces de rede. Algumas técnicas conhecidas podem ser usadas para atender os requisitos acima: Classificador: classifica os pacotes em classes de serviço, de acordo com contratos de tráfego predefinidos. Atua na entrada de pacotes no roteador. Disciplinas de filas: trata de definir a ordem de saída de pacotes. Com isso se consegue implementar garantia de banda mínima, priorização de tráfego, redução de atraso fim-a-fim e variação de atraso. Balde furado (leaky bucket): trata de definir quando pacotes podem sair. Com isso se pode fazer limitação de banda. Esta é uma técnica fundamental para fazer condicionamento de tráfego (traffic shaping);. A combinação dessas técnicas possibilita atender os requisitos de QoS especificados para diferentes tipos de tráfego. Elas são amplamente usadas em arquiteturas para QoS na Internet, tais como Intserv e Diffserv. QoS em um roteador Linux Transparências Um bom tutorial sobre disciplinas de filas no Linux Linux Advanced Routing and Traffic Control Howto: quase tudo sobre disciplinas de filas (e mais outras coisas). Disciplinas de filas (qdisc) Disciplinas de filas são mecanismos para condicionar a saída de pacotes por uma interface de rede. Com elas se podem priorizar pacotes e limitar taxas de bits de fluxos de saída. Visão geral do enfileiramento de pacotes em uma interface de saída As filas contidas nas qdisc podem ser tratadas de diferentes formas. Isso vai determinar a ordem e o ritmo com que os pacotes são desenfileirados para serem transmitidos. Alguns exemplos de qdisc implementadas no Linux: FIFO: pacotes saem por ordem de chegada. PRIO: pacotes saem de acordo com prioridades. SFQ (Stochastic Fair Queueing): pacotes saem de forma que os fluxos a que pertencem recebam aproximadamente a mesma taxa de bits. TBF (Token Bucket Filter): pacotes saem limitados a uma certa taxa de bits. ... e outras (ver Differentiated Service on Linux HOWTO e Linux Advanced Routing and Traffic Control Howto) Os diagramas abaixo ilustram algumas dessas qdisc: Uma disciplina de filas baseada em prioridades. Fonte: Differentiated Service on Linux HOWTO A qdisc TBF (combinada com PRIO), usada para limitar a taxa de saída. Fonte: Differentiated Service on Linux HOWTO Atividade Os exercícios sobre disciplinas de filas serão realizados em um cenário em que dois tipos de fluxo são estabelecidos entre duas redes, que estão interligadas por um link ponto-a-ponto. Esse link tem capacidade limitada a 512 kbps. Os fluxos são representados por: Uma transferência de um arquivo com HTTP Uma chamada VoIP com SIP e RTP A rede a ser usada deve ser criada no Netkit, a partir da configuração abaixo: Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf) # Global attributes: these values are obtained automatically from menu General->Preferences global[mem]=32 global[compact]=False global[vm]=0 global[clean]=False # 32 MB por VM # Não remove o diretório de trabalho ao final da execução server1[type]=generic server2[type]=generic pc[type]=generic r1[type]=gateway r2[type]=gateway # Rede 1: servidores + roteador r1 server1[eth0]=rede1:ip=192.168.1.1/24 server2[eth0]=rede1:ip=192.168.1.2/24 r1[eth0]=rede1:ip=192.168.1.254/24 # Rede 2: pc + roteador r2 r2[eth0]=rede2:ip=192.168.2.254/24 pc[eth0]=rede2:ip=192.168.2.1/24 # Link PPP entre Rede 1 e Rede 2 (512 kbps) r1[eth1]=link:ip=10.0.0.1/30 r2[eth1]=link:ip=10.0.0.2/30 # Roteadores default dos servidores e pc server1[default_gateway]=192.168.1.254 server2[default_gateway]=192.168.1.254 pc[default_gateway]=192.168.2.254 # Rotas estáticas nos roteadores r1[route]=192.168.2.0/24:gateway=10.0.0.2 r2[route]=192.168.1.0/24:gateway=10.0.0.1 # Ativando o servidor HTTP em server1 server1[services]=apache2 Roteiro 1) Antes de mais nada, deve-se limitar a banda do enlace ponto-a-ponto (entre r1 e r2) a 256 kbps. Crie o arquivo /root/qdisc.sh em cada um desses roteadores, e grave neles o seguinte: #!/bin/bash # Limpa as qdisc que porventura existam tc qdisc del dev eth1 root # Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável # a do link ponto-a-ponto tc qdisc add dev eth1 root handle 1: htb default 1 tc class add dev eth1 parent 1: classid 1:1 htb rate 256kbit ceil 256kbit Obs: isso implanta uma qdisc do tipo HTB (ser vista com detalhes numa aula posterior) para fazer a limitação de banda. Após criar o arquivo /root/qdisc.sh, execute-o: bash /root/qdisc.sh 2) As chamadas VoIP serão simuladas usando uma ferramenta de teste chamada siprtp, que faz parte do projeto PJSIP. Seu uso deve ser da seguinte forma: Em server2 executa-se o siprtp em modo servidor: siprtp --ip-addr=192.168.1.2 Em um dos roteadores deve-se executar o wireshark (ver menu Wireshark), escolhendo-se a interface eth0. Em pc executa-se o siprtp em modo cliente, de forma a efetuar uma chamada para server2: siprtp --ip-addr=192.168.2.1 sip:0@192.168.1.2 Em pc pode-se monitorar o andamento da chamada teclando-se l. Um sumário como mostrado abaixo deve ser apresentado: >>> l List all calls: Call #0: CONFIRMED [duration: 00:00:01.643] To: sip:0@127.0.1.1;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V Signaling quality: got 1st response in 0 ms, connected after: 0 ms Stream #0: audio PCMU@8000Hz, 20ms/frame, 8.00KB/s (9.06KB/s +IP hdr) RX stat last update: never total 77 packets 12.03KB received (14.07KB +IP hdr) pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%) (msec) min avg max last loss period: 0.000 0.000 0.000 0.000 jitter : 0.000 0.000 0.000 0.000 TX stat last update: never total 77 packets 12.03KB sent (14.07KB +IP hdr) pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%) (msec) min avg max last loss period: 0.000 0.000 0.000 0.000 jitter : 0.000 0.000 0.000 0.000 RTT delay : 0.000 0.000 0.000 0.000 A cada vez que se teclar l, um novo sumário pode ser visualizado. Quando se quiser encerrar a chamada, deve-se teclar h, e em seguida fornecer o número da chamada (0 - zero). Após o término da chamada, recarregar os pacotes no wireshark (tecle no ícone para forçar a atualização). Em seguida selecione Telephony->VoIP Calls e visualize a chamada realizada. Experimente também selecionar Telephony->RTP->Show All streams e analisar a stream RTP da chamada. Observe particularmente os valores para delta e jitter. 3) O experimento da realização da chamada VoIP deve ser repetido, porém realizando-se também uma transferência de arquivo com HTTP entre server1 e pc: Crie um arquivo de 16 MB em server1: dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096 Inicie seu download em pc: wget http://192.168.1.1/teste.img > log 2>&1 & Repita os passos do ítem 1, prestando especial atenção aos valores de jitter e perda de pacotes mostrados no sumário de chamada do siprtp. Compare aos valores obtidos quando foi realizada somente a chamada VoIP. 4) Chamadas VoIP são consideradas prioritárias em comparação a transferências de arquivos (e fluxos de dados em geral), pois possuem restrições de atrasos e jitter. Assim, devem ser definidas qdisc nos roteadores para priorizar pacotes RTP. Isso pode ser feito assim: Em r1 e r2 cria-se uma qdisc do tipo prio na interface eth1. Os fluxos UDP com port 4000 (stream RTP criada pelo siprtp) devem ser colocados na fila de maior prioridade. Copie os comandos abaixo para dentro do arquivo /root/qdisc.sh: #!/bin/bash # Limpa as qdisc que porventura existam tc qdisc del dev eth1 root # Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável # a do link ponto-a-ponto tc qdisc add dev eth1 root handle 1: htb default 1 tc class add dev eth1 parent 1: classid 1:1 htb rate 256kbit ceil 256kbit # Cria uma qdisc PRIO, porém subordinada a qdisc TBF tc qdisc add dev eth1 parent 1:1 handle 10:0 prio # Datagramas UDP vão pra fila mais prioritária. tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 17 0xff flowid 10:1 # Segmentos TCP vão pra fila menos prioritária. tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 6 0xff flowid 10:2 ... e em seguida execute-o: bash /root/qdisc.sh Repita o ítem 2, e observe as perdas de pacotes e jitter da chamada VoIP. Houve melhora ? 5) Pela capacidade do link é possível haver mais de uma chamada VoIP. Sendo assim: Calcule quantas chamadas podem ser atendidas através desse link. Teste se de fato essa quantidade de chamadas pode ser atendida, respeitando-se seus requisitos de QoS. Para iniciar mais de uma chamada simultânea execute o siprtp da seguinte forma: # inicia duas chamadas siprtp --ip-addr=192.168.2.1 --count=2

Aula 26 - 10/02/2016: QoS em roteador Linux - Continuação

Aula 27 - 15/02/2016: QoS em roteador Linux - Continuação
Arquivo:QoSLinux.pdf

Aula 28 - 17/02/2016: QoS em roteador Linux - Continuação

HTB Com exceção da qdisc PRIO, até o momento foram vistas somente qdisc capazes de conter uma única classe. Regras de priorização e condicionamento de tráfego mais elaboradas precisam, no entanto, combinar qdisc hierarquicamente. Isso pode ser percebido com um primeiro exemplo. Em um enlace, deseja-se limitar em 100 kbps o tráfego de um conjunto de aplicações. No entanto, cada aplicação também deve ter um limite de uso do enlace, de acordo com o descrito a seguir: WWW (http e https): 40 kbps SSH: 40 kbps Demais aplicações: 20 kbps O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações: Como isso poderia ser feito usando o tc ? Usando apenas as qdisc que já vimos não parece possível implementar essa regras (na dúvida, você pode tentar). Mas se for usada uma qdisc capaz de conter várias classes, isso poderia ser realizado. Essa qdisc limitaria o uso de banda a 100 kbps, e dentro dela existiriam três classes (uma para cada tipo de aplicação). Cada classe, por sua vez, conteria uma qdisc que poderia impor sua limitação de banda específica. E é exatamente isso que a qdisc HTB (Hierarchical Token Bucket) é capaz de fazer, criando uma hierarquia de classes e qdisc como mostrado na figura abaixo: # adiciona a qdisc raiz na interface eth0 tc qdisc add dev eth0 root handle 1:0 htb default 23 # cria a classe filha, que impõe o limite de banda global desta HTB tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps # cria as classes das aplicações tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps # cria os filtros para classificar os datagramas tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:21 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 443 0xffff flowid 1:21 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:22 A qdisc HTB funciona da seguinte forma: Cada classe possui uma taxa garantida e uma taxa máxima. A banda garantida não utilizada por uma classe reverte para para sua classe mãe (um nível acima na hierarquia). Essa sobra pode assim ser aproveitada pelas outras classes filhas. Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima. Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha. Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada). Os parâmetros da qdisc HTB estão sumarizados abaixo: Parâmetro Descrição Exemplo rate taxa garantida rate 100kbit ceil taxa máxima ceil 200 kbit prio prioridade da classe (menores valores = maiores prioridades) prio 1 burst quantidade máxima de bytes de uma classe, dentro da taxa garantida, que podem ser enviados antes de servir outra classe burst 20 kb cburst quantidade máxima de bytes de uma classe, acima da taxa garabntida, que podem ser enviados antes de servir outra classe cburst 20 k Atividade A rede abaixo será usada para os experimentos com disciplinas de enfileiramento: Configuração para o Netkit (salvar em Lab.conf) # Global attributes: these values are obtained automatically from menu General->Preferences # 32 MB por VM global[mem]=32 # Não remove o diretório de trabalho ao final da execução global[clean]=False server1[type]=generic server2[type]=generic pc1[type]=generic pc2[type]=generic pc3[type]=generic r1[type]=gateway r2[type]=gateway # Rede 1: servidores + roteador r1 server1[eth0]=rede1:ip=192.168.1.1/24 server2[eth0]=rede1:ip=192.168.1.2/24 r1[eth0]=rede1:ip=192.168.1.254/24 # Rede 2: pc + roteador r2 r2[eth0]=rede2:ip=192.168.2.254/24 pc1[eth0]=rede2:ip=192.168.2.1/24 pc2[eth0]=rede2:ip=192.168.2.2/24 pc3[eth0]=rede2:ip=192.168.2.3/24 # Link PPP entre Rede 1 e Rede 2 (512 kbps) r1[eth1]=link:ip=10.0.0.1/30 r2[eth1]=link:ip=10.0.0.2/30 # Roteadores default dos servidores e pc server1[default_gateway]=192.168.1.254 server2[default_gateway]=192.168.1.254 pc1[default_gateway]=192.168.2.254 pc2[default_gateway]=192.168.2.254 pc3[default_gateway]=192.168.2.254 # Rotas estáticas nos roteadores r1[route]=192.168.2.0/24:gateway=10.0.0.2 r2[route]=192.168.1.0/24:gateway=10.0.0.1 # Ativando o servidor HTTP em server1 server1[services]=apache2 1) Na rede usada nos exercícios da semana passada, procuravam-se priorizar as chamadas VoIP usando uma qdisc PRIO. Modifique a disciplina de enfileiramento nos roteadores para que até 2 chamadas possam ser realizadas simultaneamente (com seus requisitos de QoS atendidos). Use a qdisc HTB. Qual a banda disponível para as transferências de dados no melhor e no pior caso ? Descubra isso por meio de um experimento na rede simulada (você pode usar o netperf). netserver netperf -f k -H IP_netserver Regras para criar as disciplinas de filas #!/bin/bash IFACE=eth1 tc qdisc del dev $IFACE root > /dev/null 2>&1 # adiciona a qdisc raiz na interface eth0 tc qdisc add dev $IFACE root handle 1:0 htb default 22 # cria a classe filha, que impõe o limite de banda global desta HTB tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit # cria as classes das aplicações tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 180kbit ceil 512kbit tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 1bps ceil 512kbit # cria os filtros para classificar os datagramas tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:21 2) Modifique as regras de QoS do exercicio 1 de forma que: pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP. pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP. pc3 não tenha banda garantida, mas possa usar a banda ociosa. Exemplo de como criar um classificador baseado em endereços IP: # classifica de acordo com o endereço IP de destino do datagrama tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 4.3.2.1/32 flowid 1:22 # classifica de acordo com o endereço IP de origem do datagrama tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip src 4.3.2.1/32 flowid 1:22 # classifica de acordo com o endereço IP de origem do datagrama E se for UDP tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 match ip protocol 17 0xff flowid 1:22 # classifica de acordo com o endereço IP de origem do datagrama E port de origem 80 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 match ip sport 80 0xffff flowid 1:22 # classifica de acordo com o endereço IP de origem do datagrama E port de destino 80 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 match ip dport 80 0xffff flowid 1:22 Regras para o r2 #!/bin/bash IFACE=eth1 tc qdisc del dev $IFACE root > /dev/null 2>&1 # adiciona a qdisc raiz na interface eth0 tc qdisc add dev $IFACE root handle 1:0 htb default 23 # cria a classe filha, que impõe o limite de banda global desta HTB tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit # cria as classes das aplicações # Regras para pc1 tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 256kbit ceil 512kbit tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 90kbit ceil 90kbit tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 166kbit ceil 512kbit # Regras para pc2 tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 256kbit ceil 512kbit tc class add dev $IFACE parent 1:21 classid 1:33 htb prio 1 rate 180kbit ceil 180kbit tc class add dev $IFACE parent 1:21 classid 1:34 htb prio 2 rate 76kbit ceil 512kbit # Regras para pc3 tc class add dev $IFACE parent 1:1 classid 1:23 htb rate 1bps ceil 512kbit # cria os filtros para classificar os datagramas tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.1/32 flowid 1:31 tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.1/32 flowid 1:32 tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.2/32 flowid 1:33 tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.2/32 flowid 1:34 Fazer 3) Incremente as regras de QoS do exercício 2 para que tráfego SSH tenha prioridade em relação aos demais tipos de tráfego de dados. 4) Em relação ao exercício 3, ao invés de priorizar SSH modifique as regras para que se garanta ao menos 64 kbps para esse tipo de tráfego.

Aula 29 - 22/02/2016: QoS em roteador Linux - Continuação

Trabalho O trabalho será feito utilizando a rede da aula passada. Configuração para o Netkit (salvar em Lab.conf) # Global attributes: these values are obtained automatically from menu General->Preferences # 32 MB por VM global[mem]=32 # Não remove o diretório de trabalho ao final da execução global[clean]=False server1[type]=generic server2[type]=generic pc1[type]=generic pc2[type]=generic pc3[type]=generic r1[type]=gateway r2[type]=gateway # Rede 1: servidores + roteador r1 server1[eth0]=rede1:ip=192.168.1.1/24 server2[eth0]=rede1:ip=192.168.1.2/24 r1[eth0]=rede1:ip=192.168.1.254/24 # Rede 2: pc + roteador r2 r2[eth0]=rede2:ip=192.168.2.254/24 pc1[eth0]=rede2:ip=192.168.2.1/24 pc2[eth0]=rede2:ip=192.168.2.2/24 pc3[eth0]=rede2:ip=192.168.2.3/24 # Link PPP entre Rede 1 e Rede 2 (512 kbps) r1[eth1]=link:ip=10.0.0.1/30 r2[eth1]=link:ip=10.0.0.2/30 # Roteadores default dos servidores e pc server1[default_gateway]=192.168.1.254 server2[default_gateway]=192.168.1.254 pc1[default_gateway]=192.168.2.254 pc2[default_gateway]=192.168.2.254 pc3[default_gateway]=192.168.2.254 # Rotas estáticas nos roteadores r1[route]=192.168.2.0/24:gateway=10.0.0.2 r2[route]=192.168.1.0/24:gateway=10.0.0.1 # Ativando o servidor HTTP em server1 server1[services]=apache2 1) Aplicar e testar as regras de QoS listadas em "Regras para o r2" de forma que: pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP. pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP. pc3 não tenha banda garantida, mas possa usar a banda ociosa. Regras para o r2 #!/bin/bash IFACE=eth1 tc qdisc del dev $IFACE root > /dev/null 2>&1 # adiciona a qdisc raiz na interface eth0 tc qdisc add dev $IFACE root handle 1:0 htb default 23 # cria a classe filha, que impõe o limite de banda global desta HTB tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit # cria as classes das aplicações # Regras para pc1 tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 256kbit ceil 512kbit tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 90kbit ceil 90kbit tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 166kbit ceil 512kbit # Regras para pc2 tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 256kbit ceil 512kbit tc class add dev $IFACE parent 1:22 classid 1:33 htb prio 1 rate 180kbit ceil 180kbit tc class add dev $IFACE parent 1:22 classid 1:34 htb prio 2 rate 76kbit ceil 512kbit # Regras para pc3 tc class add dev $IFACE parent 1:1 classid 1:23 htb rate 1bps ceil 512kbit # cria os filtros para classificar os datagramas tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.1/32 flowid 1:31 tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.1/32 flowid 1:32 tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.2/32 flowid 1:33 tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.2/32 flowid 1:34 2) Incremente as regras de QoS acima para que o tráfego SSH tenha prioridade em relação aos demais tipos de tráfego de dados. Usar Qdisc PRIO para estes dados. 3) Em relação ao exercício 2, ao invés de priorizar SSH modifique as regras para que se garanta ao menos 64 kbps para esse tipo de tráfego. Entregar Relatório individual contendo: 1) Texto breve falando sobre QoS e QoS em roteadores Linux 2) As regras criadas/testadas e texto explicando cada uma delas 3) Testes executados a fim de comprovação do funcionamento Data de entrega: 29/02/2016

Aula 30 - 24/02/2016: QoS em roteador Linux - Continuação
Continuação do trabalho.

Aula 31 - 29/02/2016: QoS em roteador Linux - Continuação
Continuação do trabalho. Material para prova de recuperação (Asterisk e SIP) Transparências VoIP Transparências Asterisk Conteúdo das aulas contidas na Wiki. Sobre SIP, ver capítulo 7 do Kurose.

Aula 32 - 02/03/2016: Firewall

Transparências Uma coleção de textos técnicos sobre firewalls e suas aplicações Uma introdução ao iptables O filtro IP do Linux se chama NetFilter, e suas regras são configuradas por meio do utilitário iptables (ver também seu manual). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados chains ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três chains predefinidas: INPUT: contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall. OUTPUT: contém as regras a serem aplicadas aos pacotes transmitidos pelo próprio firewall. FORWARD: contém as regras a serem aplicadas aos pacotes em trânsito pelo firewall (isto é, pacotes recebidos de uma interface e sendo encaminhados através de outra interface). Assim, usando-se o iptables podem ser adicionadas regras a cada uma dessas chains, dependendo do policiamento de tráfego a ser implantado no firewall. Uma regra deve especificar basicamente três coisas: Chain: em que chain deve ser adicionada. Seletor: informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada. Alvo (target): ação a ser executada sobre o pacote que ativar a regra. Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80: Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o manual. Opção Descrição Exemplo -s IP[/Mascara] endereço IP de origem -s 200.135.37.64/26 -d IP[/Mascara] endereço IP de destino -d 8.8.8.8 -p Protocolo protocolo de transporte (tcp ou udp) -p tcp --dport numero Port de destino --dport 80 --sport numero Port de origem --sport 53 --syn Se flag SYN está acesa (somente TCP) --tcp-flags Flags1 Flags2 Se somente as flags listadas em Flags1 estão acesas dentre as Flags2 --tcp-flags SYN,ACK,RST,FIN SYN -i interface Se pacote foi recebido pela interface -i eth0 -o interface Se pacote vai sair pela interface -o eth1 -m state --state ESTADO Identifica o estado do fluxo, o qual pode ser: NEW: início de um fluxo ESTABLISHED: parte de um fluxo estabelecido RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente -m state --state NEW,RELATED Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo: Alvo Descrição Exemplo ACCEPT aceita o pacote -j ACCEPT DROP descarta o pacocte -j DROP REJECT rejeita o pacote, devolvendo um código de erro ICMP para seu remetente -j REJECT LOG registra o pacote no log do sistema -j LOG uma_chain passa o pacote para ser processado pela chain uma_chain -j rede_interna Salvando e restaurando regras do iptables Uma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles: iptables-save: escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: iptables-save > minhas_regras iptables-restore: instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: iptables-restore < minhas_regras Atividade Cada aluno deve implantar a seguinte rede virtual em seu computador utilizando a máquina virtual 1-Grafico para ser o Pc e a máquina 1-Servidor para ser o Firewall: Inicie as máquinas virtuais, certificando-se de que suas interfaces de rede estejam em modo bridge. Configure os endereços IP de suas interfaces e também suas rotas default. DICA É útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Cenário 1: Uma rede pequena sem servidores Em uma rede pequena e que não oferece serviços, todos os fluxos se originam internamente. Assim, o firewall deve impor que somente fluxos internos possam passar. Com base nisso, configure seu firewall das seguintes formas: Caso 1: os computadores internos podem acessar qualquer serviço externo. Com filtro stateless: #!/bin/bash # Limpa as regras existentes iptables -F # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall # Por default, bloqueia tudo iptables -P FORWARD DROP # Libera todos pacotes TCP que entrarem pela interface eth1 iptables -A FORWARD -i eth1 -p tcp -j ACCEPT # Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1 iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT # Libera pacotes UDP com port de origem 53 (resposta do DNS), contanto que tenham entrado pela interface eth0 iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT # Libera segmentos TCP vindos pela interface eth0 e que tenham as flags SYN e ACK acesas (resposta de pedido de conexão TCP) iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT # Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a conexões estabelecidas) iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT Com filtro stateful: #!/bin/bash # Limpa as regras existentes iptables -F # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall # Libera todos pacotes de fluxos estabelecidos iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT # Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1) iptables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT # Regra default eh descartar iptables -P FORWARD DROP Caso 2: os computadores internos podem acessar somente serviços Web e DNS. #!/bin/bash # Limpa as regras existentes iptables -F # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall # Libera todos pacotes de fluxos estabelecidos iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT # Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna iptables -A FORWARD -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth1 -p tcp --dport 443 -m state --state NEW -j ACCEPT # Descarta demais pacotes iptables -A FORWARD -j DROP Versão alternativa, usando o módulo multiport: #!/bin/bash # Limpa as regras existentes iptables -F # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall # Libera todos pacotes de fluxos estabelecidos iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT # Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT # Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna iptables -A FORWARD -i eth1 -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT # Descarta demais pacotes iptables -A FORWARD -j DROP

Aula 33 - 07/03/2016: Firewall - continuação

[Util] Término da atividade da aula anterior. Trabalho O trabalho será feito utilizando a rede utilizada no trabalho anterior. Configuração para o Netkit (salvar em Lab.conf) # Global attributes: these values are obtained automatically from menu General->Preferences # 32 MB por VM global[mem]=32 # Não remove o diretório de trabalho ao final da execução global[clean]=False server1[type]=generic server2[type]=generic pc1[type]=generic pc2[type]=generic pc3[type]=generic r1[type]=gateway r2[type]=gateway # Rede 1: servidores + roteador r1 server1[eth0]=rede1:ip=192.168.1.1/24 server2[eth0]=rede1:ip=192.168.1.2/24 r1[eth0]=rede1:ip=192.168.1.254/24 # Rede 2: pc + roteador r2 r2[eth0]=rede2:ip=192.168.2.254/24 pc1[eth0]=rede2:ip=192.168.2.1/24 pc2[eth0]=rede2:ip=192.168.2.2/24 pc3[eth0]=rede2:ip=192.168.2.3/24 # Link PPP entre Rede 1 e Rede 2 (512 kbps) r1[eth1]=link:ip=10.0.0.1/30 r2[eth1]=link:ip=10.0.0.2/30 # Roteadores default dos servidores e pc server1[default_gateway]=192.168.1.254 server2[default_gateway]=192.168.1.254 pc1[default_gateway]=192.168.2.254 pc2[default_gateway]=192.168.2.254 pc3[default_gateway]=192.168.2.254 # Rotas estáticas nos roteadores r1[route]=192.168.2.0/24:gateway=10.0.0.2 r2[route]=192.168.1.0/24:gateway=10.0.0.1 # Ativando o servidor HTTP em server1 server1[services]=apache2 IMPLEMENTAR: 1) Ajustar política das chain de acordo com o necessário; 2) PC1 tem permissão para acessar quarquer coisa nos servidores; 3) PC2 pode fazer ligações VoIP apenas; 4) PC3 tem acesso HTTP e SSH apenas; 5) Roteadores r1 aceita acesso SSH apenas de PC1. Roteador r2 aceitam acesso SSH apenas de PC3; 6) Roteadores r1 e r2 não devem aceitar ping; 7) Roteadores r1 e r2 não podem iniciar tráfego VoIP. ENTREGAR: Relatório individual ou em grupo contendo contendo todas as regras implementadas e explicação de funcionamento. Data de entrega: 10/03/2016

Aula 34 - 09/03/2016: Firewall - continuação

Aula 35 - 14/03/2016: Recuperação
Material para prova de recuperação Asterisk e SIP Transparências VoIP Transparências Asterisk Conteúdo das aulas contidas na Wiki. Sobre SIP, ver capítulo 7 do Kurose. QoS e QoS em roteador Linux Transparências Arquivo:QoSLinux.pdf Conteúdo das aulas contidas na Wiki. Conteúdo sobre QoS do Capítulo 7 do Kurose.