Redes Multimídia (diário 2017-1)

Endereço encurtado: http://bit.ly/rmu20171
Presença

Redes Multimidia: Diário de Aula 2017-1

Professora: Simara Sonaglio
E-mail: simara.sonaglio@ifsc.edu.br
Encontros:
Atendimento paralelo:

• Arquivo:Plano-ensino-2017-1.pdf

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

• Manual de instalação Zoiper Linux
• Netkit: emulador de redes com máquinas virtuais Linux (UML)

Avaliações

• Trabalho 1: trabalho prático para ser apresentado e relatório de capturas de chamadas SIP;

• Trabalho 2: trabalho prático complementar a Trabalho 1 para ser apresentado;

• Trabalho 3: trabalho prático complementar a Trabalho 2 para ser apresentado.

Aluno(a)	Trabalho 1	Trabalho 2	Trabalho 3	Nota final
Alfredo	6,50	3,00	5,00	5,00
Alison	8,75	9,00	8,00	8,00
Giovanni	7,50	6,00	8,00	7,00
Maciel	9,25	8,50	8,00	8,00
Ramon	7,30	6,00	8,00	7,00
Valdo	7,50	8,00	7,00	8,00

Notas Trabalho 1

Aluno(a)	Prática	Relatório	Rec Relatório	Nota final
Alfredo	6,50	4,50	6,50	6,50
Alison	8,50	9,00		8,75
Giovanni	7,50	3,50	7,50	7,50
Maciel	9,50	9,00		9,25
Ramon	7,50	7,10		7,30
Valdo	9,50	5,50		7,50

Notas Trabalho 2

Aluno(a)	Trabalho 2	Rec extra	Rec	Nota final
Alfredo	3,00	0,00	3,00	3,00
Alison	9,00			9,00
Giovanni	2,00	6,00		6,00
Maciel	8,50			8,50
Ramon	2,00	0,00	6,00	6,00
Valdo	8,00			8,00

Notas Trabalho 3

Aluno(a)	Trabalho 2	Rec	Nota final
Alfredo	2,80	6,00	5,00
Alison	2,30	9,00	8,00
Giovanni	2,20	9,00	8,00
Maciel	2,50	9,00	8,00
Ramon	2,20	9,00	8,00
Valdo	3,00	7,00	6,00

Diário das aulas

13/02 - Apresentação da disciplina

Aula 1
Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório. Instalação do Asterisk apt-get update apt-get install asterisk</syntaxhighlight>

14/02 - Etapa Asterisk: Introdução, plano de discagem e contas SIP

Aula 2

Um PBX IP funciona como uma central telefônica, porém intermediando chamadas VoIP. Com isso, as chamadas são feitas de um telefone IP em direção ao PBX IP, que a encaminha ao telefone IP de destino de acordo com suas regras de discagem. A figura abaixo ilustra como funciona uma chamada VoIP típica através de um PBX IP. Nas nossas aulas faremos uso de um PBX IP Asterisk, que é um software desenvolvido pela Digium. O Asterisk roda em computadores do tipo PC que possuem sistema operacional baseado em Linux. Sua licença é livre, o que significa que não há custo de licenciamento para utilizá-lo. Uma visão geral sobre Asterisk PBX IP Asterisk Transparências Site oficial do Asterisk Asterisk Guru Dicas sobre Asterisk Livro online gratuito sobre Asterisk Introdução a VoIP e SIP Livro Asterisk: Guia de Configuração - 5a geração, de Flávio Gonçalves. Asterisk: uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada. Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais ˆ Transferência, música de espera, siga-me, etc. Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk) Exemplo de cenário de uso do Asterisk Instalação do Asterisk apt-get update apt-get install asterisk</syntaxhighlight> Canais SIP Cada telefone SIP deve ter seu identificador cadastrado no Asterisk. O identificador pode tanto ser um número, análogo a um ramal, ou uma string alfanumérica. No terminologia do Asterisk, cada telefone SIP é chamado de canal SIP, e deve estar declarado em /etc/asterisk/sip.conf: ; Canal 2000 (um exemplo) [2000] defaultuser=2000 ; o nome do usuário para fins de autenticação secret=kabrum type=friend ; pode efetuar e receber chamadas host=dynamic ; pode conectar-se a partir de qualquer endereço IP context=alunos ; o contexto do plano de discagem para chamadas originadas neste canal disallow=all allow=gsm ; habilita este codec para o João. allow=alaw ; outro codec allow=ulaw ; mais um codec qualify=yes; monitora o UAC ; Canal 1000 (outro exemplo) [1000] defaultuser=1000 ; o nome do usuário para fins de autenticação secret=blabla type=friend ; pode efetuar e receber chamadas host=dynamic ; pode conectar-se a partir de qualquer endereço IP context=alunos ; o contexto no plano de discagem para chamadas originadas neste canal disallow=all allow=gsm ; habilita este codec allow=alaw ; outro codec allow=ulaw ; mais um codec qualify=yes; monitora o UAC Plano de discagem O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração /etc/asterisk/extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo: Um exemplo de plano de discagem simples pode ser visto abaixo: [alunos]; o nome deste contexto # Chamadas para o número 101 são feitas via SIP para o canal "maria" exten=>101,1,Dial(SIP/maria) same=>n,Hangup() # Chamadas para "teste" serão atendidas com um som de beep, seguido # da reprodução do arquivo de som "hello-world", em seguida outro beep e # enfim se encerra a chamada. exten=>teste,1,Playback(beep) same=>n,Wait(1) same=>n,Playback(hello-world) same=>n,Wait(1) same=>n,Playback(beep) same=>n,Hangup A estrutura do plano de discagem é composta por extensões (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo: exten=>identificador,prioridade,aplicação identificador: o número ou usuário chamado prioridade: a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador. aplicação: uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação Dial determina que deve ser encaminhada a outro canal. Como o processamento de uma chamada usualmente envolve uma sequência de extensões, existe uma sintaxe opcional para simplificar a declaração: exten=>identificador,prioridade,aplicação same=>prioridade,aplicação same: declara uma nova extensão com mesmo identificador da extensão imediatamente anterior Por fim, a prioridade (que define a ordem com que as extensões são processadas) declarada com o valor n equivale à prioridade da extensão imediatamente anterior incrementada em uma unidade: exten=>101,1,Dial(SIP/101) same=>n,Hangup; a prioridade aqui terá o valor 2 Experimento: comunicação entre telefones IP ou softphones por meio de um PBX IP Para realizar esses exercícios você deve usar o Asterisk em uma máquina virtual. Para testar as chamadas, use um softphone em seu celular ou em um computador, e um telefone IP ou ATA. 1. Criar os seguintes canais SIP: 100 e 101 (escolha usuários e senhas para autenticação) 2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa). 3. Agora configure o softphone de forma que se registre no PBX Asterisk, usando uma das contas SIP criadas previamente. Faça o mesmo com o telefone IP ou ATA. 4. A partir do softphone faça uma chamada para a conta do telefone IP. Verifique se o telefone IP acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem. Em seguida faça uma chamada em sentido contrário. 5. Execute o comando rasterisk -vvv no computador do Asterisk. 6. Usando o comando sip show peers, visualize os estados dos canais SIP conhecidos pelo Asterisk. 7. Refaça uma chamada entre softphone e telefone IP, e observe o que aparece na tela do rasterisk. 8. Será possível verificar que chamadas estão em andamento no Asterisk usando o rasterisk ? Pesquise como se pode fazer isso. 9. Use o rasterisk para testar chamadas. Use o comando console dial canal_SIP@contexto para chamar um canal SIP (substitua canal_SIP pelo número a ser chamado). Ao final, execute console hangup. 10. Acrescente mais um canal SIP, editando o arquivo sip.conf. Configure o softphone para usar esse novo canal (ou o telefone IP para se associar também a esse canal SIP). 11. Teste chamadas entre os telefones usando esse novo número. Possíveis problemas Em cada softphone ou telefone IP crie uma conta SIP, que deve ser identificada por ramal@IP_do_PBX (ex: se o PBX tiver IP 192.168.2.110, as contas de alunos podem ser 100@192.168.2.110 e 101@192.168.2.110). Após definir as contas, verifique se os telefones indicaram que elas estão disponíveis (online). Você pode fazer essa verificação também no próprio Asterisk. Neste caso execute o seguinte comando para acessar o console do Asterisk: sudo rasterisk -vvv host*CLI> sip show peers host*CLI> sip show peers Name/username Host Dyn Nat ACL Port Status 101/101 192.168.2.10 D 11270 OK (6 ms) 102/102 192.168.2.210 D 63169 OK (12 ms) 2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline] Se algum dos telefones não aparecer como OK no console do Asterisk, verifique se o número de ramal e a senha configuradas no telefone são os mesmos declarados em /etc/asterisk/sip.conf. Outro teste que se pode fazer é acessar o console do Asterisk, e depois tentar ativar as contas SIP nos telefones (i.e. colocá-las para indisponível ou offline, e depois reativá-las). O Asterisk irá mostrar algumas linhas informativas sobre os registros dos telefones.. Se as contas SIP estão devidamente registradas no Asterisk, mas ainda assim as chamadas não são realizadas, o problema deve estar no plano de discagem. Neste caso, acesse o console do Asterisk e tente novamente fazer a chamada. Veja se o Asterisk informa na tela o motivo para a chamada não ser realizada. Em seguida, confira se seu plano de discagem (/etc/asterisk/extensions.conf) possui uma extensão que satisfaça a chamada que se deseja realizar. Isso é, se você estiver tentando chamar o ramal SIP 101@192.168.2.110, deve haver uma extensão assim: exten=>101,1,Dial(SIP/101) same=>n,Hangup DICAS ASTERISK Comandos válidos no CLI do Asterisk: Para entrar no CLI do Asterisk execute: rasterisk -vvv</syntaxhighlight> Recarregar as configurações do arquivo sip.conf: sip reload</syntaxhighlight> Recarregar as configurações do arquivo extensions.conf: dialplan reload</syntaxhighlight> Ver canais SIP criados: sip show peers</syntaxhighlight> Gerar uma ligação via console: console dial extensão@contexto</syntaxhighlight>

20/02 - Continuação Aula 2

Aula 3

21/02: Entroncamentos SIP no Asterisk

Aula 4

A empresa onde se deve implantar a infraestrutura telefônica possui uma matriz e uma filial. Ambas possuem seus próprios PBX e suas linhas telefônicas locais. Por padronização seus PBX possuem as mesmas funcionalidades. Por fim, chamadas entre ramais da matriz e filial da empresa são feitas por um tronco privativo implantado com VoIP. A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2 (porém este segundo está em desuso). 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 => 4000,1,Dial(SIP/ParaSul/4000) 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 => 2000,1,Dial(SIP/ParaNorte/2000) same=>n,Hangup Outra forma de fazer um entroncamento SIP é o seguinte: PBX sip.conf extensions.conf Central1 [central2] type=friend ;defaultuser=central1; Canal SIP criado na Central 1 username=central1 host=192.168.25.102 ;ip da Central 2 secret=123 context=alunos [alunos] ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 4000,1,Dial(SIP/central2/4000) same=>n,Hangup Central2 [central1] type=friend ;defaultuser=central2; Canal SIP criado na Central 2 username=central2 host=192.168.25.101 ;ip da Central 1 secret=123 context=alunos [alunos] ; ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 2000,1,Dial(SIP/central1/2000) same=>n,Hangup Atividade: estabelecendo chamadas entre diferentes PBX Asterisk Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Isso implica definir um plano de numeração para os ramais da empresa. Sendo assim: Defina esse plano de numeração Crie as regras de discagem entre ramais da empresa Teste as chamadas Investigue a comunicação através do tronco (use o wireshark)

06/03: O protocolo SIP

Aula 5

Transparências Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf Mensagens, Transações, Diálogos e Chamadas SIP Captura: com reinvite Captura: sem reinvite 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) Resposta Classe 1XX Informativas 2XX Sucesso 3XX Redirecionamento 4XX Falha na requisição 5XX Falha no servidor 6XX Falha global Tabela com as classes de respostas 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 |<---------------| |<---------------| | | | | Correção para o wireshark O wireshark instalado no Ubuntu 14.04, como nas VM do laboratório, possui um bug que impede que se visualize a análise do fluxo de chamadas VoIP. Nessa versão, quando se seleciona no menu Telephony->VoIP Calls, e em seguida clica-se em uma das chamadas apresentadas e depois o botão Flow, o wireshark termina a execução. A solução para esse problema envolve instalar uma versão mais recente do wireshark: sudo add-apt-repository ppa:wireshark-dev/stable sudo apt-get update sudo apt-get install wireshark-gtk ... e após a instalação execute wireshark-gtk. Atividades Nas análises pedidas a seguir, faça o seguinte: Desenhe um diagrama dos diálogos SIP identificados, destacando os agentes SIP envolvidos, métodos SIP e códigos de resposta. Investigue os cabeçalhos das mensagens SIP, identificando as informações que relacionam as mensagens de um mesmo diálogo. Diagnostique o resultado da chamada: se teve sucesso ou não (e qual foi o problema, caso tenha falhado). Descubra a duração das chamadas com base na captura. Capture os pacotes de uma chamada com sucesso entre dois ramais. Identifique a sequência de mensagens que formam o diálogo SIP em questão. Repita a captura, porém para uma chamada feita para um ramal que não exista (ou extensão inexistente). Repita a captura, porém para uma chamada feita para um ramal existe, mas que não esteja registrado. Repita a captura, porém para uma chamada feita para um uma extensão que seja atendida pela própria central. Capture os pacotes de uma chamada com sucesso entre dois ramais. Além de identificar a sequência de mensagens que formam o diálogo SIP, analise os parâmetros de midia da chamada. Analise estes arquivos de captura, e descreva as chamadas ali realizadas: Captura: com reinvite Captura: sem reinvite Configure uma extensão em sua central para receber uma chamada vinda de uma câmera IP (que será ativada pelos professores). Em seguida, capture uma chamada vinda da câmera, e analise como se constiui o diálogo SIP e a descrição de midia vindos da câmera. Que semelhanças (e diferenças) existem em relação a chamadas entre ramais ?

07/03: O transporte do audio nas chamadas VoIP

Aula 6

SDP (Session Description Protocol) RFC 4566: SDP Um bom texto sobre SDP Ao iniciar uma chamada com SIP, a negociação de midia a ser transmitida é especificada no corpo da mensagem INVITE. O formato da especificação é descrito pelo protocolo SDP (Session Description Protocol), contendo as seguintes informações: Endereço IP Perfil RTP (usualmente RTP/AVP) Número de port do protocolo de transporte (usualmente UDP) Tipo de midia (audio, video, e possivelmente outros) Esquema de codificação de midia (o tipo de codec a ser usado) Assunto da sessão (uma descrição) Horários de início e fim Identificação do contato da sessão Assim como SIP, SDP codifica suas informações em texto simples. Uma mensagem SDP é composta por linhas de texto chamadas de campos, cujos nomes são abreviados por uma única letra. Os campos de uma mensagem SDP são: Tabela de campos SDP Um exemplo de mensagem SDP segue abaixo: A descrição completa de cada campo, e os possíveis valores que ele pode assumir, pode ser lida nas referências (em especial, este capítulo de livro). 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 Perfil RTP/AVP, com codecs e seus códigos numéricos 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. Atividade Essa atividade busca ilustrar os fluxos RTP com um exemplo: Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário, inclusive do áudio. Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP. Procure no wireshark as mensagens SIP trocadas entre os softphones e o Asterisk. Observe os cabeçalhos Call-Id, From, To, Via, CSeq das mensagens SIP. Quais mantiveram seus valores ao longo de todas transações, e quais mudaram ? As mensagens SIP tinham por objetivo estabelecer uma chamada de áudio entre os softphones. Essa informação está no corpo das mensagens INVITE, o qual possui uma mensagem de outro protocolo chamado SDP. Observe as informações contidas na mensagem SDP, e identifique: O tipo de midia a ser transmitida O endereço IP, port e protocolo de transporte de midia a serem usados para essa transmissão. Os codecs que podem ser usados para a transmissão de midia. A negociação sobre a transmissão de midia se concretiza na mensagem 200 OK em resposta ao INVITE. Observe que ela também contém uma mensagem SDP. Observe as informações ali contidas e compare-as com as que havia no INVITE. Como essa resposta complementa o que foi informado no INVITE ? Uma vez estabelecida a chamada, ocorre a transmissão da midia. Qual o protocolo utilizado ? Que informações ele contém em seu cabeçalho ? Descubra essas informações observando o que mostra o wireshark. Experimente estabelecer chamadas com diferentes codecs, e observe a negociação realizada com SDP. Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Refaça os exercícios anteriores, agora ativando o recurso de Reinvite.

13/03: Continuação das atividades da Aula 6

Aula 7

14/03: VoIP e NAT

Aula 8

A existência de um ou mais tradutores NAT entre telefones dificulta o estabelecimento de chamadas. Isso porque o NAT modifica o endereço IP e port (UDP ou TCP) de origem de pacotes que viajam da rede interna para a externa, o que fica inconsistente com o que foi negociado na chamada com SDP. Há alguma abordagens para contornar esse problema: Informando o endereço IP e port UDP que de fato aparecerão para a rede externa: proposta do STUN e ICE, porém nem sempre funciona (STUN) ou é complicado (ICE). Usando gateway de midia: abordagem mais comum, por ser mais fácil de ser implantada e dar bons resultados. Para entendermos os problemas causados pelo NAT na telefonia IP, iremos primeiramente fazer uma investigação utilizando como base para isso todo o conhecimento sobre os protocolos SIP, SDP e RTP previamente adquiridos. Assim, iremos implementar os cenários descritos na Atividade 1 e posteriormente Atividade 2, fazer chamadas de teste, capturar os pacotes destas chamadas utilizando o Wireshark e posterior análise destes. Atividade 1- Softphone atrás de NAT A comunicação entre canais SIP internos a cada PABX IP de cada aluno deve estar funcionando corretamente (sinalização e áudio) tanto com REINVITE como SEM REINVITE; A comunicação entre canais SIP de diferentes PABX IP deve estar funcionando corretamente tanto com REINVITE como SEM REINVITE; Cada aluno deve montar uma estrutura de rede que será apresentada em aula utilizando AP TP-LINK; Fazer as devidas configurações para que tenha áudio nas comunicações entre os diferentes PABX IP. Solução utilizando o Asterisk Dicas sobre Asterisk + NAT O Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções: nat=yes qualify=yes directmedia=no Aqui tem uma boa explicação sobre o que fazem essas opções. Atividade 2- Asterisk atrás de NAT Configurar a rede indicada na figura acima. Para isso, utilizar uma VM Servidor como roteador com NAT habilitado; Abrir o Wireshark na máquina onde o Asterisk está instalado; Tentar registrar um usuário SIP usando o softphone mostrado na figura. Foi possível? A máquina Asterisk recebeu alguma solicitação? Fazer as configurações necessárias para que o Asterisk receba as as solicitações vindas do softphone; Uma vez o usuário estando registrado, fazer testes de chamadas e verificar se há áudio. Solução utilizando o Asterisk Redirecionamento de portas em Roteador Linux Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte: iptables -t nat -A PREROUTING -d ip_de_destino_do_pacote -p protocolo --dport porta_de_destino -j DNAT --to ip_servidor_interno:porta_servidor_interno </syntaxhighlight> Para vermos as regras de NAT criadas executamos o seguinte comando: iptables -t nat -L</syntaxhighlight> Configuração sip.conf Se for o Asterisk que está atrás de NAT, então deve-se configurar seu IP válido, de forma que o PBX possa informá-lo nas mensagens SDP para as streams de audio. Para isso, deve-se acrescentar em sip.conf na seção [general] [1]: [general] externip=IP_público ; devem-se informar as redes privativas onde está o Asterisk (pode haver mais de uma ... basta repetir o ; atributo localnet para cada subrede). Isso é importante para que o Asterisk saiba quando usar o IP ; público (para telefones fora de sua rede) ou privativo (telefones dentro de sua rede) nas mensagens ; SDP que especificam o IP e port UDP para as streams RTP. localnet=prefixo/máscara OBS: isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ... Dica para testar o áudio Para testar o áudio com apenas um softphone logado você pode criar uma extension no arquivo extensions.conf que toque uma música. Segue abaixo: exten=>999,1,Answer exten=>999,n,Playback(tt-monkeys) exten=>999,n,Hungup()</syntaxhighlight> Ativar NAT em Roteador Linux Configurar as máquinas servidoras para fazer NAT:iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE</syntaxhighlight> Lembre-se de adequar a interface (eth0, eth1, ...) para o seu caso e também a rede (10.0.2.0/24, 10.0.3.0/24. ...). Como configurar o cenário Na máquina Servidor executar os seguintes comandos: 1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua ethX: 2 - Configurar uma interface na rede externa: sudo ifconfig ethx 191.36.8.x/26 3 - Configurar o gateway default: route add default gw 191.36.8.254</syntaxhighlight> 4 - Editar o arquivo /etc/resolv.conf e acrescentar a seguinte linha: nameserver 200.135.37.65</syntaxhighlight> 5 - Configurar uma interface de rede para criar uma rede interna: sudo ifconfig ethx 192.168.x.y/24 6 - Tornar uma máquina Linux roteador: echo 1 > /proc/sys/net/ipv4/ip_forward 7 - Ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): iptables -t nat -A POSTROUTING -o ethx -j MASQUERADE 8 - Fazer o redirecionamento de portas no servidor para que as portas SIP 5060 e RTP de 10000 a 20000, devemos executar o seguinte: iptables -t nat -A PREROUTING -d ip_externo_servidor -p udp --dport 5060 -j DNAT --to ip_do_asterisk:5060 iptables -t nat -A PREROUTING -d ip_externo_servidor -p udp --dport 10000:20000 -j DNAT --to ip_do_asterisk </syntaxhighlight> Na máquina Gráfico executar os seguintes comandos: 1 - Executar o seguinte comando: sudo service network-manager stop</syntaxhighlight> 2 - Configurar a interface de rede eth0 conforme abaixo: sudo ifconfig ethx 1192.168.x.y/24 3 - Configurar uma rota default: sudo route add default gw 192.168.x.y 4 - Editar o arquivo /etc/resolv.conf e acrescentar a seguinte linha: nameserver 200.135.37.65</syntaxhighlight>

20/03: Continuação das atividades da Aula 8

Aula 9

21/03: Funções de PABX

Aula 10

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 quatro deles: extensões especiais, aplicações, padrões de extensões e variáveis. Aplicações As aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado. Lista completa de aplicações do Asterisk Dial Encaminha a chamada para um destino. Exemplo: exten=>_1XXXX,1,Dial(SIP/${EXTEN}) same=>n,hangup Background Toca um arquivo de som como música de fundo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer same=>n,Background(hello-world) same=>n,Hangup Playback Toca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer same=>n,Playback(hello-world) same=>n,Hangup Wait Força uma espera durante o processamento da chamada. Exemplo: exten=>666,1,Answer same=>n,Playback(hello-world) same=>n,Wait(1) same=>n,Playback(beep) same=>n,Hangup Answer e Hangup Answer atende uma chamada. Hangup termina uma chamada. Exemplo: exten=>666,1,Answer same=>n,Playback(hello-world) same=>n,Hangup GoTo Pula para um contexto (opcional), extensão, prioridade específica. Exemplo: exten=>100,1,GoTo(vendas,s,1) GoToIf Expressões no Asterisk Trata-se do comando GoTo condicional. Sua sintaxe é: GoToIf(condição?[rótulo se verdade]:[rótulo se falso]) Os rótulos podem assumir a forma: [[contexto],extensão,]prioridade Exemplo: [alunos] exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4) same=> n,Dial(SIP/6111,30) same=> n,Hangup same=> n,Answer same=> n,Playback(hello-world) same=> n,Hangup Set Modifica o valor de uma variável. Exemplo: exten=>666,1,Set(Tentativas=1) same=>2,Dial(SIP/666,10) same=>3,Set(Tentativas=${Tentativas}+1) same=>4,GoToIf($[${Tentativas} < 2]?2:5) same=>5,Hangup Log Grava um texto qualquer no log do Asterisk. Exemplo: exten=>666,1,Log(DEBUG,"Chamada para 666") same=>n,Dial(SIP/666,10) same=>n,Hangup NoOp Não faz nada, sendo útil para depurar o plano de discagem. Exemplo: exten=>100,1,NoOp(${CONTEXT}) Padrões de extensões Tutorial sobre padrões de extensões no plano de discagem Extensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim: exten=>_1XX,1,Dial(SIP/${EXTEN}) same=>n,Hangup A extensão _1XX contida na primeira linha está escrita como um padrão (pattern), pois inicia com o caractere _. Os caracteres que seguem _ indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer 1 seguido de dois dígitos quaisquer entre 0 e 9 (é esse o significado do caractere X). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ${EXTEN}, que pode assim ser usada dentro da regra de discagem. Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere X). A tabela abaixo lista esses caracteres: Caractere Descrição X Qualquer dígito entre 0 e 9 Z Qualquer dígito entre 1 e 9 N Qualquer dígito entre 2 e 9 [13-6] Qualquer dígito entre os colchetes (no exemplo, 1,3,4,5,6) . Qualquer sequência de um ou mais dígitos ! Qualquer sequência de zero ou mais dígitos Variáveis Variáveis do Asterisk O uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo extensions.conf. A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do c-shell, porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável. Para definir uma variável: VAR=valor Para obter o valor de uma variável: ${VAR} Existem três tipos de variáveis: Variáveis globais: Variáveis que estarão disponíveis a todos os canais e contextos em um plano de discagem. Essas devem ser declaradas dentro do contexto [globals] existente no arquivo extensions.conf ou utilizando a função GLOBAL() no plano de discagem. Variáveis do canal: Variáveis que estão associadas especificamente com uma unica ligação. São definidas durante a chamada e só estão disponíveis para os participantes desta chamada. O Asterisk já define algumas variáveis específicas ao canal (Ex: ${CALLERID(num)}). Variáveis de ambiente: São as variáveis obtidas do sistema operacional. Estas são referenciadas através do comando ENV. Ex: ${ENV(path)}. Abaixo se pode ver um exemplo de plano de discagem que usa variáveis: [globals] ; definicao de uma variavel global VENDAS=SIP/6112 [alunos] ; definicao de uma variavel global atraves do comando Global e aplicacao Set exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113) exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)}) ; definicao de uma variavel especifica ao canal exten=> 7777,1,Set(teste=1) exten=> 7777,n,NoOp(${teste}) exten=> 7777,n,Set(teste=$[${teste} + 1]) exten=> 7777,n,NoOp(${teste}) exten=> 7777,n,Hangup 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. Atividades Faça com que chamadas para números externos à sua central recebam o prefixo 048.exten=>_NXXXXXXX,1,Dial(SIP/qualquer_tronco_externo/048${EXTEN})</syntaxhighlight> Faça com que números externos sempre saiam pela operadora Pastel Telecom, que tem um prefixo 66. Ex: se a chamada for para 0144935221111, o número chamado deve ser 0664935221111.exten=>_0ZZZZZXXXXXXX,1,Dial(SIP/qualquer_tronco_externo/066${EXTEN:3})</syntaxhighlight> Façam com que chamada para celulares, que têm primeiro dígito entre 6 e 9, sejam sempre encaminhados por um determinado tronco.exten=>_[6-9]XXXXXXX,1,Dial(SIP/qualquer_tronco_gsm/${EXTEN})</syntaxhighlight> Faça com que chamadas que saiam de sua central tenha como identificador de chamada o número da central e o nome do originador da chamada. Dica: ver a variável predefinida CALLERID do Asterisk. Dica Alterar chamador e verificar alteração: exten=>_2XXX,1,set(CALLERID(name)=um_nome) exten=>_2XXX,n,set(CALLERID(num)=048${EXTEN}) exten=>_2XXX,n,NoOp(${CALLERID(all)}) exten=>_2XXX,n,Dial(SIP/${EXTEN}) ;Discar para a extensão normalmente </syntaxhighlight> Crie uma extensão que, caso não seja atendida em 15 segundos, uma gravação seja apresentada comunicando que o ramal chamado está indisponível. Dica:: ver os comandos Dial e Playback.exten=>_2XXX,1,Dial(SIP/${EXTEN},15) same=>n,Playback(audio_qualquer)</syntaxhighlight> Crie outra extensão que, se não for atendida em 15 segundos, seja encaminhada para outro ramal (ex: telefonista).exten=>2001,1,Dial(SIP/2001,15) same=>n,Dial(SIP/2000)</syntaxhighlight> Crie outra extensão cujas chamadas estejam limitadas em 60 segundos após o atendimento. Se esse tempo for excedido, dois beeps devem ser apresentados (um beep por segundo) e chamada é encerrada. Dica: ver o comando Dialexten=>_2XXX,1,Dial(SIP/${EXTEN},15,L(60000)) same=>n,Playback(beep) same=>n,wait(1) same=>n,Playback(beep)</syntaxhighlight> Modifique o exercício anterior para que os dois beeps sejam apresentados 10 segundos antes da chamada exceder o tempo limite de 60 segundos.exten=>_2XXX,1,Dial(SIP/${EXTEN},15,L(60000:50000:2000))</syntaxhighlight> Modifique a extensão do exercício 6 para que o encaminhamento para outro ramal ocorra somente se o primeiro ramal estiver ocupado. Se estiver indisponível, a chamada deve ser terminada. Dica: ver o comando GotoIf<exten=>101,1,Dial(SIP/101,15) exten=>101,n,Gotoif("${DIALSTATUS}"="BUSY"?nocupado:ocupado) exten=>101,n(ocupado),Dial(SIP/100) exten=>101,n(nocupado),Noop(O status é ${DIALSTATUS}) exten=>101,n,hangup</syntaxhighlight> Crie uma extensão que está associada a um grupo de ramais. Uma chamada para essa extensão é encaminhada simultaneamente para todos os ramais do grupo. O primeiro ramal que atender captura a chamada exten=>999,1,Dial(SIP/2000&SIP/2001) exten=>999,n,Hangup</syntaxhighlight> Crie uma extensão que, ao receber uma chamada, apresente uma mensagem dizendo digite um ramal, e em seguida espere até 10 segundos para que um ramal seja digitado. Se nenhum ramal for digitado, a chamada é desviada para a telefonista.exten=> 999,1,Answer exten=> 999,n,background(tt-monkeys) exten=> 999,n,waitexten(10) exten=> t,1,Dial(SIP/100) exten=> t,n,hangup</syntaxhighlight> Crie uma extensão que reproduza um áudio três vezes usando o conceito de contador (uma variável que controle a quantidade de repetições).exten=> 998,1,Set(cont=0) exten=> 998,n,NoOp(O valor de cont é igual a ${cont}!!!) exten=> 998,n(executa),playback(hello-world) exten=> 998,n,Set(cont=$[${cont}+1]) exten=> 998,n,NoOp(O valor de cont é igual a ${cont}!!!) exten=> 998,n,Gotoif($[${cont}<3]?executa:desliga) exten=> 998,n(desliga),Hangup</syntaxhighlight> Crie uma extensão que, ao receber uma chamada, apresente uma mensagem de voz informando a data e horário no seguinte formato: dia, mês, dia da semana, hora, minuto, segundo. exten=> 995,1,Answer same=>n,SayUnixTime(dBAHMS) same=>n,Hangup</syntaxhighlight> Crie uma extensão que somente pode receber chamadas dentro de determinados horários. Fora desses horários uma gravação deve ser reproduzida.Ver GotoIfTime Crie uma extensão que, enquanto se espera que a chamada seja atendida, o chamador escute uma música. Dica: ver a funcionalidade de música em espera (music on hold). Crie um serviço que possibilite saber se um determinado ramal SIP está disponível. Esse serviço deve retornar uma mensagem de voz informando o estado do ramal em questão (disponível, ocupado, indisponível).

27/03: Continuação Aula 10

Aula 11

28/03: Continuação Aula 10

Aula 12

03/04: Funções de PBX: URA

Aula 13

O que é uma URA (Unidade de Resposta Audível) ? Clique na imagem abaixo ... URA Tabajara 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,Playback(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, por exemplo, que atenda por 9005nome_de_um_arquivo. Ao chamar essa extensã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() same=>n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,0) same=>n,playback(/var/lib/asterisk/sounds/${EXTEN:4}) same=>n,hangup() Para 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 e variáveis, já estudados em aulas anteriores, e características (features). Hoje serão vistos alguns desses recursos, que usaremos para implantar uma URA. Atividade Reproduzir a URA apresentada acima e gravar áudio de boas vindas para ela; Acrescentar um segundo nível de atendimento à sua URA; Fazer com que caso seja digitado três vezes uma opção inválida, seja encerrada a chamada.

10/04: VoIP e NAT: problemas e uma possível solução

Aula 14

11/04: Transmissão de mídia

Aula 15

Alguns parâmetros de qualidade para chamadas de voz 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. A banda requerida depende do codec, podendo mesmo ser variável. 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. De forma geral, pode-se definir a qualidade de serviço (QoS) nestas cinco dimensões: Disponibilidade Largura de banda Latência (atraso fim-a-fim) Variação de atraso (jitter) Perda de pacotes Atrasos devido a transmissão Um comparativo de requisitos de QoS de algumas aplicações O ITU-T define recomendações para qualidade de serviço em telecomunicações, tais como a norma G.114, que trata de chamadas de voz. A tabela a seguir descreve parâmetros de qualidade para transmissão de voz e video: A próxima seção detalha os tipos de atraso que podem se manifestar em uma rede, e suas prováveis causas. 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). 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. Se cada pacote está sujeito a um atraso variável, o reprodutor de midia no receptor precisa de algum mecanismo para compensar essas variações e reproduzir a midia de forma contínua. Isso usualmente se faz com buffers de reproduçã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. 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 áudio.

17/04: Início do trabalho

Aula 16

Avalição Asterisk Cada aluno será responsável por um Asterisk. Cada central IP deverá atender os seguintes pontos: As contas SIP de cada central deverão ser criadas nas faixas 1XX para a Central 1, 2XX para a Central 2 e 3XX para a Central 3 e assim sucessivamente; Para ligação interna a cada central, os usuários deverão discar 11XX, 22XX e 33XX e assim sucessivamente. Por exemplo, ao discar 1100 a chamada deve ser encaminhada para a conta 100, ao discar para 1101 a chamada deve ser encaminhada para 101 e assim por diante; Cada central deverá ter um contexto chamado INTERNO, o qual será usado para que as chamadas internas a cada central sejam completadas; Todo o áudio das chamadas deverá passar por dentro da central; Todos os ramais devem se comunicar, inclusive devem ser capazes de ligar para a URA da mesma central; Cada ramal interno deverá ter um desvio se não atende para algum outro ramal da mesma central; Cada central deverá ter um número (ex: 1199) que será atendido por uma URA. Esta URA deverá atender aos seguintes pontos: Possuir mensagens de boas vindas e apresentação de opções de atendimento; Possuir ao menos duas opções de atendimento; Possuir ao menos dois níveis de atendimento; Ao menos uma destas opções deve se atendida por um grupo de ramais que irá ringar todos os ramais ao mesmo tempo; Caso o usuário digite uma opção inválida, a chamada deverá retornar ao menu da URA por mais duas vezes. Após isso a chamada será finalizada; Caso o usuário não digite nenhuma número, a chamada deverá retornar ao menu da URA por mais duas vezes. Após isso a chamada será finalizada; Cada central deverá ter um tronco SIP para as demais centrais. Este tronco SIP deve utilizar o contexto EXTERNO; Um ramal de uma central deve ser capaz de ligar para qualquer numeração em outra central. Demonstração de funcionamento: 24/04/2017 Avaliação protocolos A primeira avaliação envolve analisar um conjunto de chamadas entre agentes SIP e PBX Asterisk. Essas chamadas tiveram seus pacotes capturados e gravados em arquivos de captura compatíveis com Wireshark e tcpdump. Os arquivos de captura são estes: Arquivos de captura As capturas envolvem várias situações: chamadas normais com e sem directmedia chamadas para números que não existem chamadas através de nat chamadas com codecs incompatíveis chamadas sujeitas a atrasos, jitter e perdas registros com e sem sucesso O cenário onde as capturas foram realizadas pode ser visualizada nesta figura. As capturas foram realizadas na interface eth1 do gateway, e também na interface eth0 de fone1 (no caso das chamadas com perdas e atrasos). Esses arquivos devem ser analisados de forma a relatar o seguinte (dica: use o wireshark) : descrição das chamadas com sucesso (SIP, SDP e RTP) descrição das chamadas que falharam, com diagnóstico e proposta de solução análise, diagnóstico e proposta de solução das chamadas com problemas de áudio (caso existam) duração das chamadas, independente de serem bem sucedidas ou não perdas, jitter e outros fatores de degradação durante as transmissões de midia O relatório deve incluir todas as chamadas encontradas, as quais devem ser descritas por diagramas. Os diagramas devem mostrar a sinalização SIP e indicar em que momento houve a transmissão de audio com RTP. Os parâmetros envolvidos nas comunicações devem também ser informados: endereços IP e ports dos participantes (tanto para SIP quanto RTP), mensagens SIP e status de resposta, e codecs. Entrega:28/04/2017 Nota 50% Asterisk 50% Análise de capturas

18/04: Continuação do trabalho

Aula 17

24/04: Continuação do trabalho

Aula 18

25/04: Apresentação do trabalho

Aula 19

02/05: Firewall

Aula 20

Transparências 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 Regras úteis Inserir regra (e.g. bloquear icmp): iptables -A FORWARD -p icmp -j DROP</syntaxhighlight> Para remover uma regra substitua a opção -A da regra que você previamente criou por -D: iptables -D POSTROUTING -p icmp -j DROP</syntaxhighlight> Para apagar todas as regras de todas as chain, use: iptables -F</syntaxhighlight> Para apagar todas as regras de uma chain específica, use: iptables -F FORWARD</syntaxhighlight> Para apagar todas as regras: iptables -F</syntaxhighlight> Para listar as regras de filtragem de pacote: iptables -L</syntaxhighlight> Para listar as regras de filtragem de pacote e apresentar informações sobre o seu uso: iptables -L -v</syntaxhighlight> Para apagar uma regra de uma linha específica use o modelo iptables -D NOME-CHAIN num-linha. Exemplo: iptables -D FORWARD 3</syntaxhighlight> Para alterar a política de uma chain: iptables -P FORWARD ACCEPT</syntaxhighlight> 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 Como configurar o cenário Na máquina Servidor executar os seguintes comandos: 1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua interface da máquina real: 2 - Configurar esta interface de rede com um IP para rede interna: sudo ifconfig eth1 192.168.X.1/24 3 - Configurar o IP externo de acordo com a faixa do laboratório e seguindo o mesmo modelo acima. 4 - Configurar gateway: route add default gw 191.36.8.254</syntaxhighlight> 4 - Tornar uma máquina Linux roteador: echo 1 > /proc/sys/net/ipv4/ip_forward 5 - Ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 6 - Configurar DNS editando o arquivo /etc/resolv.conf Na máquina Gráfico executar os seguintes comandos: 1 - Configurar a interface de rede eth0 conforme abaixo: sudo ifconfig eth0 192.168.X.2/24 2 - Configurar uma rota default: sudo route add default gw 192.168.X.1 3 - Configurar DNS editando o arquivo /etc/resolv.conf 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

08/05: Firewall - continuação Aula 20

Aula 21

09/05: Firewall - exercícios

Aula 22

15/05: Firewall - exercícios

Aula 23

Ver capítulo 35 da apostila. Firewall com iptables - Guia do Linux 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. Configure seu servidor como roteador. Configure no Ubuntu Gráfico como roteador padrão seu servidor. Configure uma regra que impeça seu cliente (Ubuntu Gráfico) de acessar qualquer porta da máquina www.ifsc.edu.br. iptables -A FORWARD -d www.ifsc.edu.br -j DROP Repita a regra, mas agora mandando um aviso ao cliente. iptables -A FORWARD -d www.ifsc.edu.br -j REJECT Proíba o seu cliente de fazer ping para qualquer máquina, liberando todos os demais serviços. Limpando todas as regras: iptables -F Bloqueando o ping: iptables -A FORWARD -p icmp --icmp-type echo-request -j DROP Limpe as regras anteriores. iptables -F Permita que seu cliente acesse qualquer máquina na porta 80, mas somente nesta porta. iptables -A FORWARD -p tcp --dport 80 -j ACCEPT Limpe todas as regras. Mude a política para DROP e permita que o seu cliente acesse somente www.ifsc.edu.br. Limpando a política: iptables -P FORWARD DROP</syntaxhighlight> Liberando www.ifsc.edu.br: iptables -A FORWARD -d www.ifsc.edu.br -j ACCEPT</syntaxhighlight> De seu cliente, faça um ataque do tipo ping of death em seu servidor: ping -f IP-servidor Iniba ataques do tipo ping of death na chain INPUT do seu servidor. Teste novamente com seu cliente e tente perceber a diferença no comportamento dos dois ataques. OBS.: Não esquecer de prever regras de retorno!!! Como configurar o cenário Na máquina Servidor executar os seguintes comandos: 1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua interface da máquina real: 2 - Configurar esta interface de rede com um IP para rede interna: sudo ifconfig eth1 192.168.X.1/24 3 - Configurar o IP externo de acordo com a faixa do laboratório e seguindo o mesmo modelo acima. 4 - Configurar gateway: route add default gw 191.36.8.254</syntaxhighlight> 4 - Tornar uma máquina Linux roteador: echo 1 > /proc/sys/net/ipv4/ip_forward 5 - Ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 6 - Configurar DNS editando o arquivo /etc/resolv.conf Na máquina Gráfico executar os seguintes comandos: 1 - Configurar a interface de rede eth0 conforme abaixo: sudo ifconfig eth0 192.168.X.2/24 2 - Configurar uma rota default: sudo route add default gw 192.168.X.1 3 - Configurar DNS editando o arquivo /etc/resolv.conf

16/05: Firewall - exercícios

Aula 24
Montar o cenário utilizado nas aulas anteriores; Continuar exercícios das aulas anteriores; Colocar o seu Asterisk para funcionar na máquina gráfico. Assim sendo, o seu Asterisk estará atrás de NAT e será necessário fazer os devidos ajustes para que ele funcione corretamente (Aula 8).

22/05: Firewall - início do trabalho

Aula 25

O Trabalho 2 consiste em desenvolver o cenário e as regras de Firewall descritas a seguir: Desenvolver o cenário apresentado abaixo: No seu servidor SIP, utilizar a configuração feita no Trabalho 1. Configurar na máquina Firewall o redirecionamento das portas UDP SIP (5060) e RTP (10000-2000)para que seja possível registrar um softphone que esteja na rede externa em seu Servidor SIP. O procedimento para isso se encontra na Aula 8. Tratar os problemas ocasionados por NAT corretamente, para que haja áudio nas chamadas. O procedimento para isso se encontra na Aula 8. Após sua rede estar plenamente funcional, deverão ser criadas as regras de Firewall de acordo com o esquemático abaixo: A sua rede interna deverá utilizar a máquina PROF como DNS. No seu Firewall somente deverão ser permitidas requisições a este servidor DNS. A máquina do seu servidor SIP tem acesso a todos os serviços de rede oferecidos pela máquina PROF (estão descritos na figura), porém nada além disso. PC também tem acesso a qualquer um dos serviços na máquina PROF. Além disso, pode fazer acesso Web (HTTP e HTTPS) à qualquer página da internet. No entanto, não acessa nada além disso. A máquina firewall não aceita acesso via SSH da rede externa e via rede interna aceita acesso SSH apenas de PC. A máquina firewall não faz acesso Web. O seu Firewall deve possuir as regras necessárias para que a comunicação SIP com os servidores SIP dos colegas seja possível, ou seja, para que o entroncamento SIP funcione corretamente. Protocolos e portas a serem utilizadas DNS: protocolo UDP e porta 53; HTTP: protocolo TCP e porta 80; HTTPS: protocolo TCP e porta 443; SSH: protocolo TCP e porta 22; SIP: protocolo UDP e porta 5060; RTP: protocolo UDP e portas 10000-20000. Avaliação Data: 29/05. Apresentar o cenário devidamente configurado e as regras de Firewall aplicadas.

23/05: Firewall - continuação do trabalho

Aula 27

29/05: Firewall - continuação do trabalho

Aula 28

30/05: Firewall - continuação do trabalho

Aula 29

05/06: QoS - conceitos básicos

Aula 30

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.

06/06: Firewall - apresentação do trabalho

Aula 31

Recuperação extra firewall O cenário para desenvolvimento da atividade de recuperação sobre firewall está disponibilizado no item colapsado abaixo. Esta atividade será desenvolvida usando a ferramenta Netkit. Arquivo de configuração do Netkit # 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 # Máquinas Rede interna (Rede 1) pc1[type]=generic pc2[type]=generic sip1[type]=generic fw[type]=gateway # Rede 1: pc1 + sip1 + firewall fw pc1[eth0]=rede1:ip=192.168.1.1/24 pc2[eth0]=rede1:ip=192.168.1.2/24 sip1[eth0]=rede1:ip=192.168.1.3/24 fw[eth0]=rede1:ip=192.168.1.254/24 # Máquinas Rede externa (Rede 2) server1[type]=generic server2[type]=generic sip2[type]=generic # Rede 2: servers + sip2 + firewall fw server1[eth0]=rede2:ip=191.36.8.193/26 server2[eth0]=rede2:ip=191.36.8.194/26 sip2[eth0]=rede2:ip=191.36.8.195/26 fw[eth1]=rede2:ip=191.36.8.254/26 # Roteadores default pc1[default_gateway]=192.168.1.254 pc2[default_gateway]=192.168.1.254 sip1[default_gateway]=192.168.1.254 server1[default_gateway]=191.36.8.254 server2[default_gateway]=191.36.8.254 sip2[default_gateway]=191.36.8.254 # Ativando serviços server1[services]=apache2 server1[services]=ssh server2[services]=apache2 server2[services]=ssh fw[services]=ssh O cenário montado é apresentado na figura abaixo, informado-se quais serviços vão rodar em cada máquina e os IPs de cada uma. Deverão ser criadas regras de firewall que permitam o funcionamento da rede de acordo com os itens listados abaixo: A máquina PC1 deve acessar somente serviços disponibilizados pela máquina Server1; A máquina PC2 deve acessar somente serviços disponibilizados pela máquina Server2; A máquina firewall não aceita acesso via SSH da rede externa (191.36.8.192/26) e via rede interna (192.168.1.0/24) aceita acesso SSH apenas de PC1. A máquina firewall aceita ping da rede interna (192.168.1.0/24) e da rede externa (191.36.8.192/26) aceita ping apenas da máquina Server2; A máquina firewall não faz acesso Web e nem pode gerar trafego VoIP (SIP e RTP). O seu Firewall deve possuir as regras necessárias para que a comunicação SIP entre as máquinas Sip1 e Sip2 seja possível (SIP e RTP). Protocolos e portas a serem utilizadas HTTP: protocolo TCP e porta 80; SSH: protocolo TCP e porta 22; SIP: protocolo UDP e porta 5060; RTP: protocolo UDP e porta 4000; ICMP echo-request. Testes para SIP e HTTP no Netkit 1) 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 sip2 executa-se o siprtp em modo servidor: siprtp --ip-addr=191.36.8.195 Em sip1 executa-se o siprtp em modo cliente, de forma a efetuar uma chamada para sip2: siprtp --ip-addr=192.168.1.3 sip:0@191.36.8.195 Em sip1 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). 2) O acesso HTTP pode ser testado realizando-se uma transferência de arquivo com HTTP entre as máquinasserver e pc: Crie um arquivo de 16 MB em server: dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096 Inicie seu download em pc: wget http://ip-do-server-http/teste.img > log 2>&1 & 3) O acesso HTTP também pode ser testado utilizando-se o utilitário curl para acessar uma página Web padrão que existe nas máquinas server. Veja exemplo abaixo: curl 191.36.8.193 4) Para testar o SSH é necessário: Primeiramente configurar uma seha para o usuário Root nas máquinas Server: passwd root Nas máquinas PC acessar as máquinas Server da seguinte forma: ssh root@ip-do-server-ssh Avaliação Data: 28/06. Enviar um documento com TODAS as regras de firewall implantadas. Estas regras serão validadas no mesmo cenário. A falta de qualquer uma delas pode acarretar em mau funcionamento do seu firewall.

12/06: QoS em roteador Linux

Aula 32

QoS em um roteador Linux Arquivo:QoSLinux.pdf Transparências Lista de números de protocolos Linux Advanced Routing and Traffic Control Howto: quase tudo sobre disciplinas de filas (e mais outras coisas). Controle de tráfego com TC, HTB e Iptables 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 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

13/06: QoS em roteador Linux - continuação Aula 32

Aula 33

19/06: QoS - Trabalho

Aula 34

Trabalho O trabalho será feito utilizando a rede abaixo. 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 server1[services]=ssh server2[services]=ssh 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 tanto para PC1 como para PC2. 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. Avaliação Entregar relatório contendo os itens abaixo e também os shell script contendo as regras cridas: 1) As regras criadas/testadas e texto explicando cada uma delas 2) Testes executados a fim de comprovação do funcionamento Data de entrega: 28/06/2017

20/06: QoS - Trabalho

Aula 35

26/06: QoS - Trabalho

Aula 36

27/06: QoS - Trabalho

Aula 36

03/07: Recuperação

Aula 37
Recuperação Firewall Atividade: Refazer o trabalho sugerido na recuperação EXTRA Entregar: Script contendo as regras Recuperação QoS Atividade: Refazer o exercício 3 do trabalho Entregar: Script contendo as regras

04/07: Recuperação

Aula 38
Recuperação Firewall Atividade: Refazer o trabalho sugerido na recuperação EXTRA Entregar: Script contendo as regras Recuperação QoS Atividade: Refazer o exercício 3 do trabalho Entregar: Script contendo as regras