Mudanças entre as edições de "PJI4-2017-2"
(89 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
Linha 6: | Linha 6: | ||
= Projeto Integrador IV= | = Projeto Integrador IV= | ||
− | '''Professores:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]] ([[imagem:Facebook2.png|20px]] [http://www.facebook.com/Marcelo.Sobral.Ifsc Facebook]) e [[ | + | '''Professores:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]] ([[imagem:Facebook2.png|20px]] [http://www.facebook.com/Marcelo.Sobral.Ifsc Facebook]) e [[Usuário:Ederson.luiz|Ederson Luiz de Souza Santos]] ([mailto:ederson.luiz@ifsc.edu.br ederson.luiz@ifsc.edu.br]) |
<br>'''Encontros:''' 3a feira/19:00, 6a feira/19:00 | <br>'''Encontros:''' 3a feira/19:00, 6a feira/19:00 | ||
<br>'''Atendimento paralelo:''' 3a e 6a feira 18:30 h | <br>'''Atendimento paralelo:''' 3a e 6a feira 18:30 h | ||
Linha 28: | Linha 28: | ||
** [https://en.wikipedia.org/wiki/PacketCable ... e sim PacketCable] | ** [https://en.wikipedia.org/wiki/PacketCable ... e sim PacketCable] | ||
* [http://thevoipreport.com/article/cold-hard-voip-stats/ Estatísticas sobre VoIP no mundo] | * [http://thevoipreport.com/article/cold-hard-voip-stats/ Estatísticas sobre VoIP no mundo] | ||
− | + | * [https://www.cisco.com/c/en/us/support/docs/voice/digital-cas/5717-e1-r2-sig.html Sinalização R2 (E1)] | |
=== Provedores VoIP no Brasil === | === Provedores VoIP no Brasil === | ||
* [https://www.falemaisvoip.com.br/o-que-e-voip/ FaleMaisVoIP] | * [https://www.falemaisvoip.com.br/o-que-e-voip/ FaleMaisVoIP] | ||
Linha 414: | Linha 414: | ||
secret=123 | secret=123 | ||
context=alunos | context=alunos | ||
+ | insecure=invite,port | ||
</syntaxhighlight> ||<syntaxhighlight lang=text> [alunos] | </syntaxhighlight> ||<syntaxhighlight lang=text> [alunos] | ||
; Ligando para a outra central e, na sequência, o "ramal" de destino | ; Ligando para a outra central e, na sequência, o "ramal" de destino | ||
Linha 427: | Linha 428: | ||
secret=123 | secret=123 | ||
context=alunos | context=alunos | ||
+ | insecure=invite,port | ||
</syntaxhighlight> ||<syntaxhighlight lang=text> [alunos] | </syntaxhighlight> ||<syntaxhighlight lang=text> [alunos] | ||
; | ; | ||
Linha 1 048: | Linha 1 050: | ||
{{collapse top | Aula 13}} | {{collapse top | Aula 13}} | ||
+ | * [http://tele.sj.ifsc.edu.br/~msobral/pji4/portao.tgz Programas para abrir o portão]: | ||
+ | ** ''porta2.py:'' programa que abre o portão. Deve ser executado sem argumentos. Abre o portão se receber um comando por meio da rede. | ||
+ | ** ''cmd.py'': programa que envia um comando pela rede para abrir o portão. Deve ser executado no PBX IP. | ||
+ | |||
+ | |||
+ | A abertura do portão pode ser feita com dois programas: | ||
+ | # Um programa executado no painel, que abre o portão se receber uma mensagem vinda da rede | ||
+ | # Um programa executado no PBX, o qual envia uma mensagem para o painel para abrir o portão | ||
+ | |||
+ | O programa que envia a mensagem contendo o comando de abertura do portão deve ser executado no PBX quando um morador pressionar uma tecla específica em seu interfone. Somente quando uma chamada entre interfone e painel do portão estiver em andamento esse programa pode ser executado. Para que isso funcione, o PBX deve ser capaz de interpretar uma notificação de dígito pressionado vinda do interfone. O Asterisk é capaz desse tipo de ação por meio de ''features'', as quais estão configuradas no arquivo [https://www.voip-info.org/wiki/view/Asterisk+config+features.conf ''features.conf'']. | ||
+ | |||
+ | Uma ''feature'' associa uma sequência de um ou mais dígitos a uma ação a ser executada no PBX. Algumas ''features'' são predefinidas, tais como transferência e captura de chamada. Novas ''features'' podem ser definidas na seção ''applicationmap'' do arquivo ''features.conf''. Uma nova ''feature'' associa uma sequência de dígitos a uma aplicação típica de plano de discagem. Para maiores informações, abra esse arquio e leia a explicação contida na seção ''applicationmap''. | ||
+ | |||
+ | '''Dica:''' a execução de um programa no PBX pode ser feita com a aplicação ''System''. | ||
+ | |||
+ | O exemplo a seguir mostra a definição de uma nova ''feature'' chamada ''chaveia''. Essa ''feature'' associa a tecla 0 (zero) à aplicação ''Playback(tt-monkeys)'': | ||
+ | |||
+ | chaveia => 0,self,Playback,tt-monkeys | ||
+ | |||
+ | A definição de uma ''feature'' segue então o formato: | ||
+ | |||
+ | nome_da_feature => sequência,canal,aplicação,argumentos da aplicação | ||
+ | |||
+ | Sendo que: | ||
+ | * ''sequência:'' a sequência de dígitos desta ''feature'' | ||
+ | * ''canal:'' canal em que a aplicação será executada: | ||
+ | ** ''peer'': no canal oposto a quem digitou a sequência | ||
+ | ** ''self:'' no canal de quem digitou a sequência | ||
+ | * ''aplicação'': a aplicação de plano de discagem a ser executada | ||
+ | * ''argumentos'': os argumentos da aplicação, caso existam | ||
+ | |||
+ | Além disso, para que uma ''feature'' esteja disponível em uma chamada, a variável de canal ''DYNAMIC_FEATURES'' deve estar definida. Por exemplo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | [default] | ||
+ | exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN}) | ||
+ | same=>n,Set(DYNAMIC_FEATURES=chaveia) | ||
+ | same=>n,Dial(SIP/${EXTEN},30) | ||
+ | same=>n,hangup() | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O exemplo acima possibilita que o canal originador da chamada ative a ''feature chaveia''. Porém no caso do porteiro VoIP não é isso que se deve fazer. As chamadas se originam do painel para algum morador, e por isso não pode ser o canal originador quem abre o portão. Se assim fosse, o próprio painel liberaria o portão ! A solução é liberar a execução da ''feature'' somente no canal chamado (interfone). O Asterisk não tem um jeito direto de fazer isso, então é necessário o pequeno truque mostrado a seguir: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | [macaquinhos] | ||
+ | exten=>s,1,noop(ativa feature para tocar macaquinhos) | ||
+ | same=>n,Set(DYNAMIC_FEATURES=chaveia) | ||
+ | same=>n,Return | ||
+ | |||
+ | [default] | ||
+ | exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN}) | ||
+ | same=>n,Dial(SIP/${EXTEN},30,U(macaquinhos)) | ||
+ | same=>n,hangup() | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | No exemplo acima, usa-se o conceito de subrotina para ativar a ''feature'' no canal chamado. A opção '''U(macaquinhos)''' da aplicação ''Dial'' faz com que a subrotina ''macaquinhos'' seja executada no canal chamado quando atender a chamada. Uma subrotina se assemelha a um contexto que possui somente a extensão ''s''. A chamada é processada nessa extensão até que apareça a aplicação ''Return'', que termina a subrotina. Com isso consegue-se ativar a ''feature'' somente no interfone. | ||
+ | |||
{{collapse bottom | Aula 13}} | {{collapse bottom | Aula 13}} | ||
Linha 1 413: | Linha 1 472: | ||
# Repita a captura, porém para uma chamada feita para um ramal existente, mas que não esteja registrado. | # Repita a captura, porém para uma chamada feita para um ramal existente, 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. | # Repita a captura, porém para uma chamada feita para um uma extensão que seja atendida pela própria central. | ||
− | |||
# Analise estes arquivos de captura, e descreva as chamadas ali realizadas: | # Analise estes arquivos de captura, e descreva as chamadas ali realizadas: | ||
#* [http://tele.sj.ifsc.edu.br/~msobral/pji4/ComReinviteRTP.pcap Captura: com reinvite] | #* [http://tele.sj.ifsc.edu.br/~msobral/pji4/ComReinviteRTP.pcap Captura: com reinvite] | ||
#* [http://tele.sj.ifsc.edu.br/~msobral/pji4/SemReinvite.cap Captura: sem reinvite] | #* [http://tele.sj.ifsc.edu.br/~msobral/pji4/SemReinvite.cap 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 ? | ||
+ | # 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. | ||
+ | --> | ||
{{collapse bottom|Aula 14}} | {{collapse bottom|Aula 14}} | ||
Linha 1 525: | Linha 1 585: | ||
#* Com que frequência esses relatórios são transmitidos ? | #* Com que frequência esses relatórios são transmitidos ? | ||
#* Que informações esses relatórios contêm ? | #* Que informações esses relatórios contêm ? | ||
+ | |||
+ | ==== 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: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | sudo add-apt-repository ppa:wireshark-dev/stable | ||
+ | sudo apt-get update | ||
+ | sudo apt-get install wireshark-gtk | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ... e após a instalação execute ''wireshark-gtk''. | ||
+ | |||
+ | <!-- <syntaxhighlight lang=bash> | ||
+ | sudo apt-get install bison flex libgtk-3-dev libnl-3-dev libnl-genl-dev libpcap-dev libcap-dev libssl-dev | ||
+ | wget https://2.na.dl.wireshark.org/src/wireshark-1.12.13.tar.bz2 | ||
+ | tar xjf wireshark-1.12.13.tar.bz2 | ||
+ | cd wireshark-1.12.13 | ||
+ | ./configure --with-qt=no --with-gtk3=yes | ||
+ | make | ||
+ | sudo make install | ||
+ | </syntaxhighlight> | ||
+ | --> | ||
{{collapse bottom | Aula 15}} | {{collapse bottom | Aula 15}} | ||
+ | |||
+ | = 03/10: Investigando os protocolos envolvidos nas chamadas = | ||
+ | |||
+ | {{collapse top | Aula 16}} | ||
+ | == Sinalização com SIP == | ||
+ | |||
+ | As chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando [[PJI4-2017-2#20.2F02:_O_protocolo_SIP|protocolo SIP]]. Elas podem ser enquadradas em dois casos: | ||
+ | # Chamada com intermediação de gateway de midia | ||
+ | # Chamada com intermediação de gateway de midia, porém usando re-INVITE | ||
+ | |||
+ | Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso. | ||
+ | |||
+ | === 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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 |<---------------| | ||
+ | |<---------------| | | ||
+ | | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === 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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 |<---------------| | ||
+ | |<---------------| | | ||
+ | | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === Atividade === | ||
+ | |||
+ | # Execute o wireshark no hospedeiro, e deixe-o capturando datagramas UDP (especifique isso em ''Capture->options''). | ||
+ | # Realize uma chamada entre dois softphones, usando as contas do seu servidor Asterisk. | ||
+ | # Observe as mensagens trocadas entre softphones e Asterisk (use menu ''Telephony->VoIP Calls'' e depois ''Graph''). Em particular, observe quem é o receptor e transmissor de cada mensagem SIP e também dos pacotes de midia (protocolo RTP). | ||
+ | # Edite o arquivo ''sip.conf'' do seu Asterisk, e defina a opção ''directmedia=yes'' (isso deve estar no perfil que você definiu para as contas). Faça o Asterisk reler o ''sip.conf'': <syntaxhighlight lang=bash> | ||
+ | rasterisk | ||
+ | > sip reload | ||
+ | </syntaxhighlight> | ||
+ | # Refaça a chamada entre os softphones, e observe no wireshark as mensagens SIP e pacotes RTP. O que mudou em relação à chamada anterior ? | ||
+ | # Em qual caso, dentre os apresentados no início da aula, cada chamada se enquadra ? O que se pode concluir quanto ao papel do Asterisk em cada caso ? | ||
+ | |||
+ | |||
+ | {{collapse bottom | Aula 16}} | ||
+ | |||
+ | = 06/10: VoIP e NAT= | ||
+ | |||
+ | {{collapse top | Aula 17}} | ||
+ | |||
+ | 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. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Atividade 1- Softphone atrás de NAT== | ||
+ | |||
+ | [[Imagem:Cenário1-Aula7.png|400px]] | ||
+ | |||
+ | #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. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | |||
+ | ==Solução utilizando o Asterisk== | ||
+ | |||
+ | * [http://www.smartvox.co.uk/astfaq_configbehindnat.htm 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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | nat=yes | ||
+ | qualify=yes | ||
+ | directmedia=no | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | [http://www.voip-info.org/wiki/view/Asterisk+sip+nat Aqui] tem uma boa explicação sobre o que fazem essas opções. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Atividade 2- Asterisk atrás de NAT== | ||
+ | |||
+ | [[Imagem:Cenário1-Aula8.png|400px]] | ||
+ | |||
+ | #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. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Solução utilizando o Asterisk== | ||
+ | |||
+ | <br> | ||
+ | '''Redirecionamento de portas em Roteador Linux''' | ||
+ | |||
+ | Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte: <code> 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: <code> iptables -t nat -L</syntaxhighlight> | ||
+ | |||
+ | <br> | ||
+ | '''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] [http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf#SIPConfigurationgeneral]: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | [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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | '''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 ... | ||
+ | |||
+ | <br> | ||
+ | |||
+ | '''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: | ||
+ | |||
+ | <code> 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:<code>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. ...). | ||
+ | |||
+ | == STUN: Session Traversal Utilities for NAT == | ||
+ | |||
+ | * [http://tools.ietf.org/html/rfc5389 RFC 5389] | ||
+ | |||
+ | |||
+ | '''''Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...''''' | ||
+ | |||
+ | |||
+ | O estabelecimento de uma chamada VoIP implica iniciar e manter duas streams de áudio (uma em cada sentido da comunicação). Cada stream usa o protocolo RTP, cujas PDUs são transportadas dentro de datagramas UDP. Portanto, cada telefone IP precisa alocar um port UDP, por onde serão recebidas as PDUs RTP. | ||
+ | |||
+ | [[imagem:Voip-call.png|600px]] | ||
+ | <br>''Diagrama que mostra uma chamada VoIP típica intermediada por um PBX. A sinalização se faz através do PBX, mas as streams de áudio RTP são estabelecidas diretamente entre os telefones VoIP.'' | ||
+ | |||
+ | |||
+ | As informações necessárias para transmitir as PDUs da stream RTP são informadas no momento em que se inicia a chamada. Um dos telefones IP usa o protocolo SIP para solicitar uma chamada com outro telefone (mensagem INVITE). Dentro dessa mensagem INVITE é encapsulada uma mensagem SDP, que contém as informações necessárias para criar uma stream de áudio, tais como codecs aceitos, e endereço IP e port UDP onde o telefone iniciador da chamada espera receber as PDUs RTP. Se o telefone chamado aceitar a chamada, sua resposta SIP terá status ''200 OK'', e encapsulará uma mensagem SDP contendo a identificação dos codecs que aceita utilizar, além de seu endereço IP e port UDP onde espera receber as PDUs RTP. Assim, com base nas informações contidas nas mensagens SDP, os telefones IP podem estabelecer as streams de áudio em ambas direções. A figura abaixo ilustra uma mensagem SDP encapsulada em uma mensagem SIP INVITE. | ||
+ | |||
+ | |||
+ | [[imagem:Sdp.png|800px]] | ||
+ | <br>''O endereço IP e o port UDP para estabelecer a stream RTP são informados dentro da mensagem SDP, quando o telefone VoIP tenta iniciar uma chamada com SIP (mensagem INVITE). A lista de codecs da mensagem SDP foi omitida por simplicidade.'' | ||
+ | |||
+ | |||
+ | Mas como essas streams de áudio podem ser estabelecidas se existir um ou mais gateways NAT entre os telefones VoIP ? A mensagem SDP com a descrição dos dados de uma stream é preenchida usando o endereço IP e port UDP do telefone VoIP. No entanto, a existência de um gateway NAT faz com que o endereço IP e port UDP desse telefone VoIP sejam diferentes para quem estiver fora de sua rede. O correto seria ter na mensagem SDP o endereço IP e port UDP que serão usados após passar o NAT - quer dizer, os valores que serão visíveis para o outro telefone VoIP. Para isso foi criado o serviço STUN (''Session Traversal Utilities for NAT''), que possibilita que um telefone VoIP (ou qualquer outro cliente) descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade. | ||
+ | |||
+ | [[imagem:STUN.png|600px]] | ||
+ | <br>''Cenário em que se poderia usar STUN'' | ||
+ | |||
+ | |||
+ | O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (''binding request''), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (''binding response'') contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio. | ||
+ | |||
+ | |||
+ | [[imagem:Stun-diagram.png|600px]] | ||
+ | <br>''Exemplo de mensagens trocadas com STUN'' | ||
+ | |||
+ | |||
+ | '''Deve-se notar que o STUN não faz milagre !''' Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Como será visto em uma [[RMU-2012-1#11.2F04:_Firewall|aula futura]], isso só é possível se o NAT for do tipo [http://en.wikipedia.org/wiki/Full_cone_NAT ''full cone''], [http://en.wikipedia.org/wiki/Restricted_cone_NAT ''restricted cone''] ou [http://en.wikipedia.org/wiki/Port_restricted_cone_NAT ''port restricted cone'']. Quer dizer, se o NAT for do tipo [http://en.wikipedia.org/wiki/Symmetric_NAT simétrico], o STUN não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT ''port restricted cone'') ... | ||
+ | |||
+ | === Servidores STUN === | ||
+ | |||
+ | Existe uma implementação de um [http://www.vovida.org/applications/downloads/stun/ servidor STUN para Linux] (disponível no Ubuntu via apt). Basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja ''do outro lado'' do NAT. No laboratório de Programação foi ativado um servidor STUN no computador dos professores, e ele atende em '''192.168.1.231'''. Esse servidor atende apenas a necessidade dos experimentos dentro do laboratório. No caso geral, quando o servidor STUN deve possuir endereços IP válidos, existem servidores públicos, conforme mostrado na listagem abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | provserver.televolution.net | ||
+ | sip1.lakedestiny.cordiaip.com | ||
+ | stun1.voiceeclipse.net | ||
+ | stun01.sipphone.com | ||
+ | stun.callwithus.com | ||
+ | stun.counterpath.net | ||
+ | stun.endigovoip.com | ||
+ | stun.ekiga.net (alias for stun01.sipphone.com) | ||
+ | stun.ideasip.com (no XOR_MAPPED_ADDRESS support) | ||
+ | stun.internetcalls.com | ||
+ | stun.ipns.com | ||
+ | stun.noc.ams-ix.net | ||
+ | stun.phonepower.com | ||
+ | stun.phoneserve.com | ||
+ | stun.rnktel.com | ||
+ | stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support) | ||
+ | stunserver.org see their usage policy | ||
+ | stun.sipgate.net | ||
+ | stun.sipgate.net:10000 | ||
+ | stun.voip.aebc.com | ||
+ | stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support) | ||
+ | stun.voxalot.com | ||
+ | stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support) | ||
+ | stun.xten.com | ||
+ | numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID) | ||
+ | stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | [http://www.voip-info.org/wiki/view/STUN Maiores detalhes sobre servidores STUN] | ||
+ | |||
+ | {{collapse bottom | Aula 17}} | ||
+ | |||
+ | = 10/10: Qualidade da comunicação = | ||
+ | |||
+ | {{collapse top | Aula 18}} | ||
+ | * [https://www.voip-info.org/wiki-QoS Alguns parâmetros de qualidade para chamadas de voz] | ||
+ | |||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | [[imagem:Rmu-tabela-qos.png]] | ||
+ | <br>''Um comparativo de requisitos de QoS de algumas aplicações'' | ||
+ | |||
+ | |||
+ | O [https://www.itu.int/ ITU-T] define recomendações para qualidade de serviço em telecomunicações, tais como a norma [https://www.itu.int/rec/T-REC-G.114/en G.114], que trata de chamadas de voz. A tabela a seguir descreve parâmetros de qualidade para transmissão de voz e video: | ||
+ | |||
+ | [[imagem:PJI4-Qos-itut.png|800px]] | ||
+ | |||
+ | |||
+ | 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. | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Atraso | ||
+ | !Descrição | ||
+ | !Tipo | ||
+ | !Expressão<br>(F: tamanho de um pacote em bytes,<br>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) || <math>A_t = \frac{F}{B}</math> | ||
+ | |- | ||
+ | |''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 || <math>A_p</math> | ||
+ | |- | ||
+ | |''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 || <math>A_x</math> | ||
+ | |- | ||
+ | |''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 || <math>A_q = \sum_{F \in Fila} \frac{F}{B}</math> | ||
+ | |} | ||
+ | |||
+ | |||
+ | 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: | ||
+ | |||
+ | [[imagem:Componentes-atraso.png]] | ||
+ | |||
+ | {|border="1" cellpadding="2" | ||
+ | |- | ||
+ | |''Atrasos de transmissão nos links WAN:''||<math>A_{wan}=\frac{1500 \cdot 8}{10 \cdot 10^{6}}=1,2 \cdot 10^{-3} s</math> | ||
+ | |- | ||
+ | |''Atrasos de transmissão nos links LAN:''||<math>A_{lan}=\frac{1500 \cdot 8}{1 \cdot 10^{9}}=12 \cdot 10^{-6} s</math> | ||
+ | |- | ||
+ | |''Atraso de enfileiramento em roteador: melhor caso<br>(fila vazia)'' || <math>A_q=0~s</math> | ||
+ | |- | ||
+ | |''Atraso de enfileiramento em roteador: pior caso<br>(fila cheia):''|| <math>A_q=100 \cdot \frac{1500 \cdot 8}{10 \cdot 10^{6}} = 120 \cdot 10^{-3} s</math> | ||
+ | |} | ||
+ | |||
+ | O menor atraso pode ser calculado assim: | ||
+ | |||
+ | <math>A_{min}=4 \cdot A_{lan} + 4 \cdot A_{wan} + 4 \cdot A_p = 12,848 \cdot 10^{-3} s</math> | ||
+ | |||
+ | |||
+ | ... e o maior atraso possível é: | ||
+ | |||
+ | <math>A_{max}=4 \cdot A_{lan} + 4 \cdot A_{wan} + 4 \cdot A_p + 4 \cdot A_q = 492,848 \cdot 10^{-3} s</math> | ||
+ | |||
+ | 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é <math>A_{max} - A_{min} = 480 ms</math>. 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. | ||
+ | |||
+ | == Atividade == | ||
+ | |||
+ | * [https://wiki.linuxfoundation.org/networking/netem Curiosidade: como emular atrasos, jitter e perdas em um roteador Linux] | ||
+ | |||
+ | |||
+ | 1. Deve-se implantar esta rede: | ||
+ | |||
+ | [[imagem:Cenário1-Aula7.png]] | ||
+ | |||
+ | |||
+ | 2. Os PBX devem estar configurados para intermediar o áudio das chamadas (''directmedia=no''). | ||
+ | |||
+ | 3. Devem ser realizadas chamadas entre softphones, dando atenção à qualidade do áudio. ''OBS:'' nos PBX devem-se capturar os pacotes das chamadas para posterior análise. | ||
+ | |||
+ | 4. Após realizar as chamadas, devem-se analisar suas respectivas capturas. A análise deve se concentrar em informações que forneçam uma medida de qualidade de serviço. ''Dica:'' vejam o menu ''Telephony->RTP''. | ||
+ | |||
+ | 5. Os passos 3 e 4 devem ser repetidos conforme orientação dos professores. Os casos a serem analisados envolvem: | ||
+ | * Experimentar diferentes valores de atraso fim-a-fim | ||
+ | * Experimentar diferentes valores de variação de atraso (''jitter'') | ||
+ | * Experimentar diferentes taxas de perda de pacotes | ||
+ | |||
+ | |||
+ | {| border=1 | ||
+ | !Atraso (ms) | ||
+ | !Jitter (ms) | ||
+ | !Perdas (%) | ||
+ | !Qualidade | ||
+ | |- | ||
+ | |50 ||0 ||0 || Boa | ||
+ | |- | ||
+ | |150 ||0 ||0 || Boa | ||
+ | |- | ||
+ | |400 ||0 ||0 || Razoável | ||
+ | |- | ||
+ | |600 ||0 ||0 || Ruim | ||
+ | |- | ||
+ | |150 ||20 ||0 || Boa | ||
+ | |- | ||
+ | |150 ||50 ||0 || Razoável (falhas quase imperceptíveis) | ||
+ | |- | ||
+ | |150 ||100 ||0 || Ruim (falhas intermitentes, som atrasa e acelera) | ||
+ | |- | ||
+ | |150 ||200 ||0 || Ruim (falhas intermitentes, som atrasa e acelera) | ||
+ | |- | ||
+ | |150 ||20 ||1 || Boa | ||
+ | |- | ||
+ | |150 ||20 ||2 || Boa | ||
+ | |- | ||
+ | |150 ||20 ||4 || Boa (???) | ||
+ | |- | ||
+ | |150 ||20 ||10 || Razoável (falhas intermitentes e breves) | ||
+ | |- | ||
+ | |400 ||50 ||10 || Ruim (falhas frequentes, corta o som) | ||
+ | |} | ||
+ | |||
+ | '''OBS:''' em todos os casos, a conversa esteve compreensível. Mesmo quando ruim, era possível entender a maior parte da conversa. | ||
+ | {{collapse bottom | Aula 11}} | ||
+ | |||
+ | = 17/10: Conexão com a PSTN e PABX legado = | ||
+ | |||
+ | * [https://avaliacao.ifsc.edu.br/sad/ Avaliação docente] | ||
+ | |||
+ | {{collapse top | Aula 19 }} | ||
+ | |||
+ | Além de interligar a portaria aos interfones e softphones dos moradores, o porteiro VoIP pode se integrar a uma rede telefônica privativa preexistente. Por exemplo, o porteiro VoIP pode ser instalado em uma empresa que possui uma rede telefônica própria, formada por ramais e troncos para a rede telefônica pública. Nesse caso, os ramais da empresa teriam papel similar aos interfones. Para que o porteiro VoIP possa ser usado nesses cenários, ele deve ser capaz de se integrar a redes telefônicas convencionais. | ||
+ | |||
+ | == Integração de Asterisk a redes telefônicas convencionais ou móveis == | ||
+ | |||
+ | A [https://en.wikipedia.org/wiki/Public_switched_telephone_network rede pública de telefonia comutada] (do inglês Public switched telephone network ou PSTN) é o termo usado para identificar a rede telefônica mundial comutada por circuitos destinada ao serviço telefônico. A PSTN é administrada pelas operadoras de serviço telefônico e inicialmente foi projetada como uma rede de linhas fixas e analógicas, porém atualmente é digital. Interligada a ela existe também a Rede Móvel, que inclui dispositivos móveis como os telefones celulares. Através dessas redes podem ser realizadas chamadas locais (chamada realizada na mesma cidade/região), longa distância (chamada realizada para outra cidade/região) ou internacionais (chamada realizada para outros países). | ||
+ | |||
+ | Além da PSTN, existem também as Centrais Privadas de Comutação Telefônica ([https://en.wikipedia.org/wiki/Business_telephone_system#Private_branch_exchange PABX ou, simplesmente, PBX]). Redes telefônicas formadas por PABXs operam de forma similiar a PSTN, porém são restritas ao ambiente de uma empresa ou organização. Os PABXs tem a função de interligar os telefones dos usuários da empresa (ramais) e também conectar-se a Central Pública (PSTN) através de uma ou mais linhas telefônicas (linhas tronco). | ||
+ | |||
+ | Ambos, PSTN e PABX convencional, operam de forma similar e fazem uso de comutação de circuitos. Mais recentemente, surgiu o conceito de PBX IP que funciona como uma central telefônica convencional (PABX), 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. O PBX IP, diferentemente da PSTN e do PABX convencional, não utiliza a comutação de circuitos, mas sim opera sobre a rede de dados utilizando comutação de pacotes. | ||
+ | |||
+ | O Asterisk é uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada. Para funcionar puramente como um PABX IP, o Asterisk não necessita de nenhum item adicional. Basta tão somente instalá-lo em um computador e fazer as devidas configurações. Porém, se é desejado que o Asterisk se comunique com a PSTN ou com PABX convencional, são necessários placas ou ''gateways'' que façam a interface com o mundo da telefonia baseada em comutação de circuitos. Abaixo seguem como exemplo algumas placas que podem ser adicionas à máquina onde foi instalado o Asterisk: | ||
+ | |||
+ | |||
+ | *Placa FXO/FXS | ||
+ | |||
+ | [[Imagem:fxo-fxs.png|600px]] | ||
+ | |||
+ | |||
+ | *Placa E1 | ||
+ | |||
+ | [[Imagem:e1.png|400px]] | ||
+ | |||
+ | |||
+ | *Placa GSM | ||
+ | |||
+ | [[Imagem:gsm.png|400px]] | ||
+ | |||
+ | |||
+ | Com o uso dessas placas é possível integrar o Asterisk em diversos cenários, como estes: | ||
+ | |||
+ | |||
+ | *Cenário 1 | ||
+ | [[Imagem: cenário1.png|400px]] | ||
+ | |||
+ | |||
+ | *Cenário 2 | ||
+ | [[Imagem: cenário2.png|400px]] | ||
+ | |||
+ | |||
+ | |||
+ | *Cenário 3 | ||
+ | [[Imagem: cenário3.png|400px]] | ||
+ | |||
+ | |||
+ | Além da inserção de placas na máquina onde está instalado o Asterisk, é possível utilizar ''gateways'' VoIP que fazem a interface entre a PSTN e PABX convencionais legados e o Asterisk. Com estes ''gateways'' não é necessária a inserção de placas na máquina do Asterisk. Exemplos de interligações que podem ser feitas usando ''gateways'' VoIP podem ser vistos abaixo: | ||
+ | |||
+ | *Cenário 1 com ''Gateway'' VoIP | ||
+ | [[Imagem: gateway1.png|400px]] | ||
+ | |||
+ | |||
+ | *Cenário 2 com ''Gateway'' VoIP | ||
+ | [[Imagem: gateway2.png|400px]] | ||
+ | |||
+ | ==Refazendo o Asterisk para conectá-lo com a PSTN == | ||
+ | |||
+ | # Remova a versão do Asterisk instalada pelo Ubuntu: <syntaxhighlight lang=bash> | ||
+ | sudo apt-get remove asterisk | ||
+ | </syntaxhighlight> | ||
+ | # Atualize os pacotes de software do Ubuntu: <syntaxhighlight lang=bash> | ||
+ | sudo apt-get update | ||
+ | </syntaxhighlight> | ||
+ | # Instale estes pacotes de software: <syntaxhighlight lang=bash> | ||
+ | sudo apt-get install -y libncurses-dev libssl-dev libsqlite3-dev libxml2-dev build-essential | ||
+ | </syntaxhighlight> | ||
+ | # Baixar a [http://tele.sj.ifsc.edu.br/~msobral/pji4/asterisk-11.1.1.tar.gz versão do Asterisk] sob medida para o ''channel driver'' Khomp. | ||
+ | # Descompacte o arquivo ''asterisk-11.1.1.tar.gz''. | ||
+ | # Entre no diretório ''asterisk-11.1.1''. | ||
+ | # Execute estes comandos: <syntaxhighlight lang=bash> | ||
+ | ./configure --prefix=/usr/local | ||
+ | make | ||
+ | sudo make install | ||
+ | sudo make samples | ||
+ | sudo make config | ||
+ | </syntaxhighlight> | ||
+ | # Para facilitar a edição dos arquivos de configuração, faça o seguinte: <syntaxhighlight lang=bash> | ||
+ | cd /etc | ||
+ | sudo mv asterisk asterisk.orig | ||
+ | sudo ln -s /usr/local/etc/asterisk | ||
+ | </syntaxhighlight> | ||
+ | # Copie os arquivos de configuração originais do Asterisk que você editou até o momento: <syntaxhighlight lang=bash> | ||
+ | sudo cp asterisk.orig/extensions.conf asterisk/ | ||
+ | sudo cp asterisk.orig/sip.conf asterisk/ | ||
+ | sudo cp asterisk.orig/voicemail.conf asterisk/ | ||
+ | </syntaxhighlight> | ||
+ | # Execute este comando para que o Asterisk consiga ser executado: <syntaxhighlight lang=bash> | ||
+ | sudo -s | ||
+ | echo /usr/local/lib > /etc/ld.so.conf.d/asterisk.conf | ||
+ | ldconfig | ||
+ | exit | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==Instalando o ''Channel Driver'' da Khomp== | ||
+ | |||
+ | # Baixe o [http://tele.sj.ifsc.edu.br/~msobral/pji/khomp/channel_4.3_009_x86-64.sh.gz arquivo do channel driver da Khomp]. Em seguida descompacte-o (ele deve estar em ''Downloads''). | ||
+ | # Execute estes comandos para instalar o channel driver: <syntaxhighlight lang=bash> | ||
+ | cd Downloads | ||
+ | gunzip channel_4.3_007_x86-64.sh.gz | ||
+ | sudo bash channel_4.3_007_x86-64.sh | ||
+ | </syntaxhighlight> | ||
+ | # Copie o channel driver da Khomp para o diretório correto do Asterisk (no caso da instalação que fizemos): <syntaxhighlight lang=bash> | ||
+ | sudo cp /usr/lib/asterisk/modules/chan_khomp.so /usr/local/lib/asterisk/modules/ | ||
+ | </syntaxhighlight> | ||
+ | # Inicie o Asterisk: <syntaxhighlight lang=bash> | ||
+ | sudo /etc/init.d/asterisk start | ||
+ | </syntaxhighlight> | ||
+ | # Acesse a [http://127.0.0.1:14100/ interface de administração da Khomp], e prossiga na instalação do módulo EBS. | ||
+ | ## Entre com usuário ''admin'' e senha ''khomp'' | ||
+ | ## Vá em ''Configuração'', e em seguida clique no botão ''Procurar'' | ||
+ | ## Selecione o dispositivo encontrado, e clique em ''Adicionar'' | ||
+ | ## Defina um endereço IP para o dispositivo, e ative os links E1 em modo R2. Ao final clique em ''Salvar'', e depois ''Aplicar''. | ||
+ | ## Vá em ''Monitoração'', e em seguida em ''Serviços''. Ali confira se o ''Khomp API Server'' está ativado. Caso não, clique na opção para ativá-lo (ícone com um triângulo ao lado da palavra ''Inativo''). | ||
+ | ## Se o Asterisk estiver inativo, reinicie-o. | ||
+ | ## Vá em ''Dispositivos'', e confira se o dispositivo foi reconhecido e está em estado ativado (''Up''). | ||
+ | ## Você pode ver os canais existentes no seu módulo EBS clicando em ''Canais''. O número de cada canal (encontrado na primeira coluna da tabela) deve ser usado para identificá-lo no plano de discagem do Asterisk. | ||
+ | |||
+ | == Fazendo chamadas através de canais Khomp == | ||
+ | |||
+ | * [http://tele.sj.ifsc.edu.br/~msobral/pji4/khomp-docs/ Documentação do Khomp] | ||
+ | |||
+ | |||
+ | Canais Khomp devem ser identificados no plano de discagem com esta notação, sendo ''X'' o número do módulo EBS (por ordem em que foi adicionado) e ''Y'' o número do canal. No exemplo a seguir, a extensão 9 é encaminhada pelo canal 60 do módulo 0: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | exten=>9,1,Dial(Khomp/bXcY) | ||
+ | same=>n,hangup | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==Atividades== | ||
+ | |||
+ | Uma vez adicionado o módulo Khomp e este estando com status UP, pode-se fazer as configurações para que as chamadas sejam roteadas através dele. | ||
+ | |||
+ | #Para fazer ligação para um ramal conectado já na placa FXS é necessário criar uma extensão no plano de discagem conforme o exemplo: <code> exten=>777,1,Dial(Khomp/b0c60,20,t) | ||
+ | exten=>777,n,hangup</syntaxhighlight> Onde b0 indica o módulo e c60 indica o canal; | ||
+ | # Para fazer ligação a partir deste ramal, é necessário em primeiro lugar criar um contexto de entrada no arquivo khomp.conf: <code> context-fxs = khomp-DD-CC</syntaxhighlight> Onde DD é o módulo Khomp (ex. 00) e CC é o canal (ex. 60); | ||
+ | # Também é possível criar um único contexto que sirva para todos os ramais da placa FXS: <code> context-fxs-alt = khomp-DD </syntaxhighlight> Onde DD indica o módulo Khomp | ||
+ | #Após alterar o khomp.conf, é necessário criar um contexto com o mesmo nome no arquivo extensions.conf. Exemplo, se você criou o contexto ''context-fxs-alt = khomp-00'', você deve criar este contexto no extensions.conf para tratar as chamadas entrantes dos ramais analógicos; | ||
+ | #Se você quer configurar os links E1, a configuração de saída de chamada sobre o link E1 deverá ser feita no arquivo extensions.conf de forma semelhante ao feito com os ramais. No entanto, agora é necessário informar para qual número você pretende discar via E1. Exemplo a seguir onde se disca para o número 100 via E1: <code>exten=>555,1,Dial(Khomp/b0c30-59/100) | ||
+ | exten=>555,n,hangup </syntaxhighlight> | ||
+ | #Para receber chamadas via E1 é necessário também configurar o khomp.conf e criar um contexto para o link E1 desejado: <code>context-digital = khomp-DD-LL</syntaxhighlight> Onde DD é o módulo e LL é o link. | ||
+ | #Após alterar o khomp.conf, é necessário criar um contexto com o mesmo nome no arquivo extensions.conf. | ||
+ | #Para fazer chamadas via FXO, a configuração de saída de chamada sobre o link E1 deverá ser feita no arquivo extensions.conf de forma semelhante ao feito com os ramais. No entanto, agora é necessário informar para qual número você pretende discar via FXO. Exemplo a seguir onde se disca para o número 100 via FXO: <code>exten=>555,1,Dial(Khomp/b0c68/100) | ||
+ | #Para receber chamadas via FXO é necessário também configurar o khomp.conf e criar um contexto para a linha analógica: <code>context-fxo = khomp-DD-CC</syntaxhighlight> Onde DD é o módulo Khomp (ex. 00) e CC é o canal (ex. 68); | ||
+ | #Após alterar o khomp.conf, é necessário criar um contexto com o mesmo nome no arquivo extensions.conf e neste contexto deve ser criada uma exten s para encaminhar todas as chamadas para um atendedor fixo. Exemplo: <code>[khomp-00-68] | ||
+ | exten=>s,1,Dial(SIP/1000) | ||
+ | same=>n,hangup</syntaxhighlight> | ||
+ | |||
+ | {{collapse bottom | Aula 19}} | ||
+ | |||
+ | = 20/10: Conexão com a PSTN e PABX legado (continuação) = | ||
+ | |||
+ | {{collapse top | Aula 20 }} | ||
+ | {{collapse bottom | Aula 20}} | ||
+ | |||
+ | = 24/10: Conexão com a PSTN e PABX legado (continuação) = | ||
+ | |||
+ | {{collapse top | Aula 21 }} | ||
+ | {{collapse bottom | Aula 21}} | ||
+ | |||
+ | = 27/10: Conexão com a PSTN e PABX legado (continuação) = | ||
+ | |||
+ | {{collapse top | Aula 22 }} | ||
+ | {{collapse bottom | Aula 22}} | ||
+ | |||
+ | = 31/10: Etapa 2: conclusão = | ||
+ | |||
+ | {{collapse top | Aula 23 }} | ||
+ | A conclusão da etapa 2 envolve estender o porteiro VoIP para que ele se integre com uma rede telefônica privativa existente no condomínio ou empresa. Essa rede telefônica se compõe dos ramais de empresa ou dos interfones do condomínio. | ||
+ | |||
+ | O porteiro VoIP deve ser capaz de explorar essa rede telefônica. Na versão do porteiro realizada na etapa 1, era possível contatar um morador por meio de seu celular. Nesse caso, a chamada era feito com VoIP. Na etapa 2, o porteiro deve ser capaz de tentar contatar números telefônicos externos, caso nenhum ranal SIP tenha sido configurado para aquele contato, ou se o ramal SIP configurado estiver indisponível. Assim incrementam-se as possibilidades de comunicação entre o sistema do porteiro VoIP e os condôminos ou funcionários de empresas. | ||
+ | |||
+ | A rede telefônica existente se compõe de um PBX, ramais analógicos e troncos analógicos, digitais (E1) ou móveis (GSM) com uma operadora. Assim, a central do porteiro VoIP deve se integrar com esse PBX por meio de alguma tecnologia dentre aquelas estudadas. | ||
+ | |||
+ | |||
+ | O resultado dessa atividade final é: | ||
+ | * '''Documentação a ser entregue em formato PDF até 10/11 com:''' | ||
+ | ** O modelo do serviço a ser provido, com os detalhes sobre como a central do poretiro está implantada, como ela está interligada com o PBX, o plano de numeração para portaria e clientes, serviços extras existentes e outras funcionalidades que forem utilizadas. | ||
+ | ** O modelo da central do condomínio, com todos os detalhes sobre como elas são configuradas, incluindo os troncos para interligação com operadora | ||
+ | * '''Protótipo:''' | ||
+ | ** Implantação da central do porteiro e do PBX | ||
+ | |||
+ | |||
+ | * [https://moodle.sj.ifsc.edu.br/mod/assign/view.php?id=3724 Entrega via Moodle] | ||
+ | |||
+ | |||
+ | '''OBS:''' a operadora de Telecom será implantada pelos professores. | ||
+ | {{collapse bottom | Aula 23}} | ||
+ | |||
+ | = 7/11: Etapa 2: conclusão = | ||
+ | |||
+ | {{collapse top | Aula 24 }} | ||
+ | {{collapse bottom | Aula 24}} | ||
+ | |||
+ | = 10/11: Etapa 2: conclusão = | ||
+ | |||
+ | {{collapse top | Aula 25 }} | ||
+ | {{collapse bottom | Aula 25}} | ||
+ | |||
+ | = 14/11: Etapa 2: conclusão = | ||
+ | |||
+ | {{collapse top | Aula 26 }} | ||
+ | {{collapse bottom | Aula 26}} | ||
+ | |||
+ | = 17/11: Etapa 3: integração com serviços de rede = | ||
+ | |||
+ | {{collapse top | Aula 27}} | ||
+ | |||
+ | Existem serviços de rede essenciais para o provedor, e que devem ser integrados à infraestrutura existente. São eles: | ||
+ | * DNS | ||
+ | * WWW | ||
+ | * ??? | ||
+ | |||
+ | Na aula de hoje será feita uma revisão sobre DNS, e em seguida sua implantação para o provedor. | ||
+ | |||
+ | {{collapse top|Revisão sobre DNS}} | ||
+ | '''DNS ''(Domain Name System)''''' é uma base de dados distribuída e hierárquica. Nela se armazenam informações para mapear nomes de máquinas da Internet para endereços IP e vice-versa, informação para roteamento de email, e outros dados utilizados por aplicações da Internet. | ||
+ | |||
+ | A informação armazenada no DNS é identificada por nomes de domínio que são organizados em uma árvore, de acordo com as divisões administrativas ou organizacionais. Cada nodo dessa árvore, chamado de ''domínio'', possui um rótulo. O nome de omínio de um nodo é a concatenação de todos os rótulos no caminho do nodo até a raiz. Isto é representado como uma ''string'' de rótulos listados da direita pra esquerda e separados por pontos (ex: ifsc.edu.br, sj.ifsc.edu.br). Um rótulo precisa ser único somente dentro do domínio pai a que pertence. | ||
+ | |||
+ | Por exemplo, um nome de domínio de uma máquina no IFSC pode ser ''mail.ifsc.edu.br'', em que ''br'' é o domínio do topo da hierarquia ao qual ''mail.sj.ifsc.edu.br'' pertence. | ||
+ | Já ''edu'' é um subdomíno de ''br'', ''ifsc'' um subdomínio de ''edu'', e ''mail'' o nome da máquina em questão. | ||
+ | |||
+ | Por razões administrativas, o espaço de nomes é dividido em áreas chamadas de ''zonas'', cada uma iniciando em um nodo e se estendendo para baixo para os nodos folhas ou nodos onde outras zonas iniciam. Os dados de cada zona são guardados em um ''servidor de nomes'', que responde a consultas sobre uma zona usando o protocolo DNS. | ||
+ | |||
+ | Clientes buscam informação no DNS usando uma biblioteca de resolução (''resolver library''), que envias as consultas para um ou mais servidores de nomes e interpreta as respostas. | ||
+ | |||
+ | [[Imagem:hierarquia-DNS.gif|400px]] | ||
+ | |||
+ | (tirado do [http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch01.html#id2546234 manual do BIND9]) | ||
+ | |||
+ | Ver também o [http://my.safaribooksonline.com/0-596-00158-4/dns4-CHP-2 livro sobre DNS e BIND] da O'Reilly. | ||
+ | |||
+ | == Registros DNS == | ||
+ | |||
+ | Cada rótulo na hierarquia DNS possui um conjunto de informações associadas a si. Essas informações são guardas em registros | ||
+ | de diferentes tipos, dependendo de seu significado e propósito. Cada consulta ao DNS retorna assim as informações do registro pedido associado ao rótulo. Por exemplo, para ver o registro de endereço IP associado a www.ifsc.edu.br pode-se executar esse comando (o resultado teve alguns comentários removidos): | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | msobral@dell-iron:~$ dig sj.ifsc.edu.br mx | ||
+ | |||
+ | ;; QUESTION SECTION: | ||
+ | ;sj.ifsc.edu.br. IN MX | ||
+ | |||
+ | ;; ANSWER SECTION: | ||
+ | sj.ifsc.edu.br. 3600 IN MX 10 hendrix.sj.ifsc.edu.br. | ||
+ | |||
+ | ;; AUTHORITY SECTION: | ||
+ | sj.ifsc.edu.br. 3600 IN NS ns.pop-udesc.rct-sc.br. | ||
+ | sj.ifsc.edu.br. 3600 IN NS ns.pop-ufsc.rct-sc.br. | ||
+ | sj.ifsc.edu.br. 3600 IN NS hendrix.sj.ifsc.edu.br. | ||
+ | |||
+ | ;; ADDITIONAL SECTION: | ||
+ | hendrix.sj.ifsc.edu.br. 3600 IN A 200.135.37.65 | ||
+ | ns.pop-ufsc.rct-sc.br. 11513 IN A 200.135.15.3 | ||
+ | ns.pop-udesc.rct-sc.br. 37206 IN A 200.135.14.1 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo: | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Nome | ||
+ | !TTL | ||
+ | !Classe | ||
+ | !Registro | ||
+ | !Conteúdo do registro | ||
+ | |- | ||
+ | |hendrix.sj.ifsc.edu.br.||3600||IN||A||200.135.37.65 | ||
+ | |- | ||
+ | |sj.ifsc.edu.br.||3600||IN||NS||hendrix.sj.ifsc.edu.br. | ||
+ | |- | ||
+ | |sj.ifsc.edu.br.||3600||IN||MX||10 hendrix.sj.ifsc.edu.br. | ||
+ | |} | ||
+ | |||
+ | Obs: ''TTL'' é o tempo de validade (em segundos) da informação retornada do servidor de nomes, e ''classe'' é o tipo de endereço (no caso IN equivale a endereços Internet). | ||
+ | |||
+ | Os tipos de registros mais comuns são: | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Registro | ||
+ | !Descrição | ||
+ | !Exemplo | ||
+ | |- | ||
+ | |A || Endereço (Address) || www.sj.ifsc.edu.br IN A 200.135.37.66 | ||
+ | |- | ||
+ | |NS|| Servidor de nomes (Name Server) || sj.ifsc.edu.br IN NS hendrix.sj.ifsc.edu.br. | ||
+ | |- | ||
+ | |CNAME || Apelido (Canonical Name) || mail.sj.ifsc.edu.br IN CNAME hendrix.sj.ifsc.edu.br. | ||
+ | |- | ||
+ | |MX || Roteador de email (Mail Exchanger) || sj.ifsc.edu.br IN MX mail.sj.ifsc.edu.br. | ||
+ | |- | ||
+ | |SOA || dados sobre o domínio (Start of Authority)||sj.ifsc.edu.br IN SOA hendrix.sj.ifsc.edu.br. root.sj.ifsc.edu.br. 2009120102 1200 120 604800 3600 | ||
+ | |- | ||
+ | |PTR || Ponteiro para nome (Pointer) || 65.37.135.200.in-addr.arpa IN PTR hendrix.sj.ifsc.edu.br. | ||
+ | |- | ||
+ | |TXT || Texto genérico (Text) || sj.ifsc.edu.br IN TXT "v=spf1 a mx ~all" | ||
+ | |} | ||
+ | |||
+ | Uma zona assim é composta de um conjunto de registros com todas as informações dos domínios nela contidos. O conteúdo de uma zona, contendo o domínio ''example.com'', pode ser visualizado abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | example.com 86400 IN SOA ns1.example.com. hostmaster.example.com. ( | ||
+ | 2002022401 ; serial | ||
+ | 10800 ; refresh | ||
+ | 15 ; retry | ||
+ | 604800 ; expire | ||
+ | 10800 ; minimum | ||
+ | ) | ||
+ | IN NS ns1.example.com. | ||
+ | IN NS ns2.smokeyjoe.com. | ||
+ | IN MX 10 mail.another.com. | ||
+ | IN TXT "v=spf1 mx -all" | ||
+ | |||
+ | ns1 IN A 192.168.0.1 | ||
+ | www IN A 192.168.0.2 | ||
+ | ftp IN CNAME www.example.com. | ||
+ | |||
+ | bill IN A 192.168.0.3 | ||
+ | fred IN A 192.168.0.4 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | == Atividade == | ||
+ | |||
+ | O objetivo é montar a seguinte estrutura: | ||
+ | |||
+ | [[imagem:Dns-ex1.png|800px]] | ||
+ | |||
+ | Vamos configurar e testar um servidor DNS. Para tanto montaremos a estrutura indicada no diagrama, onde cada máquina será um servidor DNS, com um domínio próprio e, ao mesmo tempo, será cliente do servidor DNS da máquina 192.168.2.101. Esta, por sua vez, será servidor um servidor master do domínio redes.edu.br e servidor escravo, recebendo automaticamente uma cópia das zonas dos servidores masters, de todos os demais domínios criados. Esta, será também a única máquina com servidor DNS com zona reversa. Sendo assim todos os domínios, diretos e reversos, serão visíveis por meio deste servidor. | ||
+ | |||
+ | # Entendendo o serviço DNS. Antes de qualquer reconfiguração faça testes usando a ferramenta “dig”: <syntaxhighlight lang=bash> | ||
+ | dig -x 200.135.37.65; | ||
+ | dig www.das.ufsc.br; | ||
+ | dig +trace www.polito.it; | ||
+ | dig @200.135.37.65 www.polito.it.</syntaxhighlight> | ||
+ | # Siga o roteiro da apostila e inicialize o servidor DNS, criando o domínio redesX.edu.br (onde X é o último dígito do ip de sua máquina). Por questões práticas, acima mencionadas, não crie zona reversa. | ||
+ | # O servidor DNS deverá responder pelos nomes: da própria máquina (etiqueta), www, ftp e mail, todos apontando para o mesmo IP. | ||
+ | # No ''/etc/resolv.conf'' declare nameserver 192.168.2.101. | ||
+ | # Faça testes “pingando” nos nomes, ex: <syntaxhighlight lang=bash> | ||
+ | ping www.redes4.edu.br | ||
+ | ping m4.redes4.edu.br | ||
+ | ping www.redes3.edu.br | ||
+ | </syntaxhighlight> | ||
+ | # Teste o DNS reverso. | ||
+ | # Faça testes usando a ferramenta “dig”: <syntaxhighlight lang=bash> | ||
+ | dig -x número.do.ip | ||
+ | dig maquina.dominio.extensao.br; | ||
+ | dig +trace maquina.dominio.extensao.br; | ||
+ | dig @servidor.de.nomes maquina.dominio.extensao.br. | ||
+ | </syntaxhighlight> | ||
+ | {{collapse bottom|Revisão sobre DNS}} | ||
+ | |||
+ | O provedor deve ter seu domínio DNS, mas os clientes não possuem domínios próprios. No entanto, cada cliente possui uma identificação única no domínio do provedor, o que é útil para identificá-los nas URI SIP. | ||
+ | |||
+ | == Integração com o DNS == | ||
+ | |||
+ | 1. No arquivo <tt>/etc/bind/named.conf.local</tt> será criado o domínio <tt>nome-provedor.com.br</tt> e seu reverso: | ||
+ | ... | ||
+ | zone "nome-provedor.com.br" { | ||
+ | type master; | ||
+ | file "/etc/bind/nome-provedor.com.br"; | ||
+ | }; | ||
+ | zone "10.in-addr.arpa" { | ||
+ | type master; | ||
+ | file "/etc/bind/10.in-addr.arpa"; | ||
+ | }; | ||
+ | |||
+ | |||
+ | 2. Próxima etapa: as informações específicas de domínio em <tt>/etc/bind/nome-provedor.com.br</tt>: | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( | ||
+ | 2010033101 ; serial | ||
+ | 1d ; refresh | ||
+ | 1h ; retry | ||
+ | 1w ; expire | ||
+ | 1d ; negative cache ttl | ||
+ | ) | ||
+ | @ IN NS ns1 | ||
+ | ns1 IN A IP-maquina-ns1 | ||
+ | www IN CNAME ns1 | ||
+ | servidor IN CNAME ns1 | ||
+ | |||
+ | * A primeira linha ($TTL) indica o tempo que os registros permanecem no cache do DNS sem atualização e é obrigatória, normalmente é dada em segundos, mas pode ser dada em horas, dias, semanas; | ||
+ | |||
+ | * A segunda linha: início da configuração da zona de domínio, contém inicialmente o nome da zona (representado por um sinal de @ o que equivale ao nome da zona de domínio). A sigla IN indicando que se refere a Internet, a sigla SOA indicando que se trata do início do documento, o nome do servidor primário DNS e o e-mail do administrador; | ||
+ | |||
+ | * Depois há uma série de números, que obrigatoriamente devem ser informados, esses números indicam respectivamente: | ||
+ | #O número de série da zona de domínio, normalmente iniciando com o ano, seguido do mês, dia e um número sequencial qualquer. | ||
+ | #Período de refresh para servidores slave. | ||
+ | #Período de espera até uma nova tentativa de refresh em caso de erro. | ||
+ | #Período de expiração para servidores slave e | ||
+ | #TTL default para os RR que não possuem valor especificado. | ||
+ | |||
+ | * Em seguida informamos os nameservers (NS), no caso ns1; | ||
+ | * Podemos informar também um registro do tipo MX (Mail Exchanger) que se trata do servidor de e-mail no recebimento de e-mails; | ||
+ | * E por último foram feitas as associações entre nomes de máquinas e seus respectivos IP’s. | ||
+ | |||
+ | 3. Configuração do DNS reverso, arquivo <tt>/etc/bind/10.in-addr.arpa</tt>: | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( | ||
+ | 2010033101 ; serial | ||
+ | 1d ; refresh | ||
+ | 1h ; retry | ||
+ | 1w ; expire | ||
+ | 1d ; negative cache ttl | ||
+ | ) | ||
+ | @ IN NS ns1.nome-provedor.com.br. | ||
+ | 1.0.0 IN PTR ns1 | ||
+ | 4. Utilitário para testar o arquivo que contém o conteúdo de uma zona: named-checkzone nome_do_dominio arquivo_da_zona ==> Aponta possíveis erros no arquivo de configuração.<code> named-checkzone nome-provedor.com.br /etc/bind/nome-provedor.com.br</syntaxhighlight> | ||
+ | 5. Utilitário para testar a configuração do BIND: <code> named-checkconf -z </syntaxhighlight> | ||
+ | 6. Como este serviço pode rodar com má configuração, é interessante (re)iniciar o serviço com um monitor dos registros em uma janela: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | tail -f /var/log/syslog | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 7. E em outra janela reiniciar o serviço: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/bind9 restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==O registro SRV== | ||
+ | |||
+ | Um registro de serviço (SRV) é um tipo relativamente novo de registro DNS que fornece informações sobre serviços disponíveis. Definido na RFC 2782, é frequentemente utilizado por protocolos mais recentes (SIP é um deles). Se você quiser suporte a pesquisas SIP em seu domínio, você precisará de um registro SRV para responder a estas pesquisas adequadamente. | ||
+ | |||
+ | Quando uma conexão SIP faz uma pesquisa em leif@shifteight.org, o registro SRV pode responder que o serviço solicitado (SIP) é encontrado no servidor pbx.shifteight.org. | ||
+ | |||
+ | A maioria dos servidores DNS executa o BIND (Berkeley Internet Name Daemon). O registro BIND para uma entrada SRV para SIP será algo como abaixo: | ||
+ | |||
+ | <code>_sip._udp.shifteight.org. 86400 IN SRV 0 0 5060 pbx.shifteight.org.</syntaxhighlight> | ||
+ | |||
+ | {| border="1" | ||
+ | !Nome | ||
+ | !Descrição | ||
+ | !Exemplo | ||
+ | |- | ||
+ | |Serviço ||Nome simbólico do serviço || _sip. | ||
+ | |- | ||
+ | |Proto ||protocolo de transporte || _udp. | ||
+ | |- | ||
+ | |Nome ||nome de domínio para este registro ||shifteight.org. | ||
+ | |- | ||
+ | |TTL ||Time to Live || 86400 | ||
+ | |- | ||
+ | |Classe ||Campo classe do DNS ||IN | ||
+ | |- | ||
+ | |Prioridade ||Prioridade do host || 0 | ||
+ | |- | ||
+ | |Peso ||Peso relativo do registro || 0 | ||
+ | |- | ||
+ | |Porta ||Porta TCP ou UDP || 5060 | ||
+ | |- | ||
+ | |Alvo || Nome da máquina que prove o serviço || pbx.shifteight.org. | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | ==Testes== | ||
+ | |||
+ | # Altere o arquivo /etc/resolv.conf<code> | ||
+ | nameserver IP-do-seu-DNS | ||
+ | </syntaxhighlight> | ||
+ | #Utilize o comando ''dig'' para testes diversos ao seu domínio. Abaixo alguns exemplos:<code>dig -x 150.162.12.25 ; consulta ao DNS reverso | ||
+ | dig www.das.ufsc.br ; consulta ao DNS direto | ||
+ | dig +trace www.polito.it ; consulta ao DNS direto mostrando toda a árvore de DNS consultados | ||
+ | dig @200.135.37.65 www.polito.it ; consulta ao servidor DNS 200.135.37.65</syntaxhighlight> | ||
+ | #Você também pode fazer testes de ping à maquinas configuradas no seu domínio. | ||
+ | #Você pode testar o registro SRV usando o comando: <code>dig SRV _sip._udp.nome-provedor.com.br</syntaxhighlight> | ||
+ | #Como resultado, você deve ver algo do gênero:<code> ;; ANSWER SECTION: | ||
+ | _sip._udp.nome-provedor.com.br. 14210 IN SRV 0 0 5060 maquina.nome-provedor.com.br.</syntaxhighlight> | ||
+ | # Configure as contas em seus softphones para que se registrem em domínios identificados pelo nome de domínio DNS. Isso faz com que o softphone faça consulta pelo registro SRV correspondente. | ||
+ | # Configure a central do provedor para que faça chamadas para URI SIP que contêm identificador de domínio (ex: 32334545@cliente1.provedor.com.br). | ||
+ | |||
+ | {{collapse bottom | Aula 27}} | ||
+ | |||
+ | = 21/11: Etapa 2: atividades da avaliação = | ||
+ | |||
+ | {{collapse top | Aula 28}} | ||
+ | {{collapse bottom}} | ||
+ | |||
+ | = 24/11: Etapa 2: atividades de avaliação = | ||
+ | |||
+ | {{collapse top | Aula 29}} | ||
+ | {{collapse bottom | Aula 29}} | ||
+ | |||
+ | = 28/11: Etapa 3: Integração com serviços de rede: WWW = | ||
+ | |||
+ | {{collapse top | Aula 30}} | ||
+ | |||
+ | Uma empresa pode implantar outros serviços úteis tanto para os clientes quanto para suas equipes de suporte e gerência. Um dos serviços mais difundidos e utilizados é WWW, em que documentos, recursos genéricos ou mesmo aplicações são disponibilizados segundo um modelo cliente-servidor. Exemplos de uso desse serviço são: | ||
+ | * Sítios Web | ||
+ | * Repositórios de arquivos | ||
+ | * Aplicações web | ||
+ | |||
+ | Hoje será feita uma revisão sobre o serviço WWW. Em seguida, algumas aplicações para esse serviço na rede do porteiro serão identificadas. | ||
+ | |||
+ | <!-- | ||
+ | - página do provedor, com informações para consulta pelos clientes | ||
+ | - repositório de manuais | ||
+ | - área de armazenamento de arquivos da equipe de suporte (com acesso via [https://sourceforge.net/projects/wbftp/ webftp]) | ||
+ | - sistema de chamados | ||
+ | - sistema de monitoramento de recursos (ex: [http://www.cacti.net/ Cacti]) | ||
+ | - sistema de monitoramento para fins de disponibilidade e emissão de alertas (ex: [https://www.nagios.org/ nagios]) | ||
+ | - sistemas documentação da rede (ex: [https://netbox.readthedocs.io/en/latest/ Netbox]) | ||
+ | --> | ||
+ | |||
+ | == WWW e protocolo HTTP == | ||
+ | |||
+ | WWW (''World Wide Web'') é um sistema de documentos em hipermidia que são ligados e acessados na Internet ([http://pt.wikipedia.org/wiki/Www FONTE: Wikipedia]). Tendo início em 1990 como uma aplicação experimental desenvolvida por [http://pt.wikipedia.org/wiki/Tim_Berners-Lee Tim Berners-Lee], que então trabalhava no [http://pt.wikipedia.org/wiki/CERN CERN], na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. | ||
+ | |||
+ | Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo [http://pt.wikipedia.org/wiki/HTTP HTTP (Hypertext Transfer Protocol)] é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. | ||
+ | |||
+ | === Mensagens de pedido HTTP === | ||
+ | |||
+ | Mensagens HTTP de pedido possuem a seguinte estrutura: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | Método URI HTTP/versão_do_protocolo | ||
+ | Cabeçalho1: valor do cabeçalho1 | ||
+ | Cabeçalho2: valor do cabeçalho2 | ||
+ | Cabeçalho3: valor do cabeçalho3 | ||
+ | CabeçalhoN: valor do cabeçalhoN | ||
+ | |||
+ | corpo da mensagem | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | A primeira linha usa o campo ''método'' para indicar o tipo de pedido a ser realizado. O ''método'' HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são: | ||
+ | * '''GET''': obtém um documento. | ||
+ | * '''POST''': envia algum conteúdo e obtém como resposta um documento. | ||
+ | * '''HEAD''': obtém informações sobre um documento. | ||
+ | |||
+ | O campo [http://pt.wikipedia.org/wiki/URI URI (Uniform Resource Indicator)] identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (''pathname''), porém possui algumas extensões para poder enviar informação adicional. | ||
+ | |||
+ | Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. | ||
+ | |||
+ | Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | GET /wiki/ HTTP/1.1 | ||
+ | Host: wiki.sj.ifsc.edu.br | ||
+ | User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 | ||
+ | Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 | ||
+ | Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 | ||
+ | Accept-Encoding: gzip, deflate | ||
+ | Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4 | ||
+ | Connection: keep-alive | ||
+ | If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === Mensagens de resposta HTTP === | ||
+ | |||
+ | Mensagens HTTP de resposta possuem a seguinte estrutura: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | HTTP/versão_do_protocolo status info | ||
+ | Cabeçalho1: valor do cabeçalho1 | ||
+ | Cabeçalho2: valor do cabeçalho2 | ||
+ | Cabeçalho3: valor do cabeçalho3 | ||
+ | CabeçalhoN: valor do cabeçalhoN | ||
+ | |||
+ | corpo da mensagem | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são: | ||
+ | * '''200 OK''': pedido atendido com sucesso. | ||
+ | * '''302 Moved Temporarily''': o pedido pode ser atendido em outra URL. | ||
+ | * '''401 Authorization Required''': acesso negado, pois exige-se autenticação. | ||
+ | * '''403 Forbidden''': acesso negado em definitivo. | ||
+ | * '''404 Not Found''': documento não encontrado. | ||
+ | |||
+ | Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | HTTP/1.1 200 OK | ||
+ | Date: Thu, 23 May 2013 20:43:31 GMT | ||
+ | Server: Apache | ||
+ | Last-Modified: Fri, 10 May 2013 14:09:58 GMT | ||
+ | ETag: "757236-40-4dc5db8df272a" | ||
+ | Accept-Ranges: bytes | ||
+ | Content-Length: 64 | ||
+ | Vary: Accept-Encoding | ||
+ | Connection: close | ||
+ | Content-Type: text/plain; charset=UTF-8 | ||
+ | |||
+ | Este é um pequeno arquivo de teste, sem informação útil ... | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | '''Exemplos''' | ||
+ | |||
+ | [https://dl.dropboxusercontent.com/u/50936332/capturaHTTP01.cap Captura de página somente HTML] | ||
+ | |||
+ | [https://dl.dropboxusercontent.com/u/50936332/capturaHTTP02.cap Captura de página HTML com uma figura] | ||
+ | |||
+ | [https://dl.dropboxusercontent.com/u/50936332/capturaHTTP03.cap Captura de página HTML com duas figuras] | ||
+ | |||
+ | |||
+ | ==Apache== | ||
+ | |||
+ | Ver capítulo 26 da [[Media:Gerencia_de_redes.pdf|apostila]]. | ||
+ | |||
+ | O servidor [http://httpd.apache.org/ABOUT_APACHE.html Apache] (''Apache server'') é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (''National Center for Supercomputing Applications''), Universidade de Illinois. Ele descende diretamente do [http://en.wikipedia.org/wiki/NCSA_HTTPd NCSA httpd], um servidor web criado e mantido por essa organização. Seu nome vem justamente do reaproveitamento do ''NCSA httpd'' (e do fator de tê-lo tornado modular) fazendo um trocadilho com a expressão "''a patchy httpd'' (um httpd remendável). Para ter ideia de sua popularidade, em maio de 2010, o Apache serviu aproximadamente 54,68% de todos os sites e mais de 66% dos milhões de sites mais movimentados. O servidor é compatível com o protocolo HTTP versão 1.1. Suas funcionalidades são mantidas através de uma estrutura de módulos, podendo inclusive o usuário escrever seus próprios módulos — utilizando a API do software. É disponibilizado em versões para os sistemas Windows, Novell Netware, OS/2 e diversos outros do padrão POSIX (Unix, GNU/Linux, FreeBSD, etc). | ||
+ | |||
+ | Um servidor web é capaz de atender requisições para transferência de documentos. Essas requisições são feitas com o protocolo HTTP (''HyperText Transfer Protocol''), e se referem a documentos que podem ser de diferentes tipos. Uma requisição HTTP simples é mostrada abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | GET / HTTP/1.1 Host: www.ifsc.edu.br | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Para o servidor Web, os principais componentes de uma requisição HTTP são o método HTTP a executar e o localizador do documento a ser retornado (chamado de URI - ''Uniform Resource Indicator''). No exemplo acima, a requisição pede o método ''GET'' aplicado à URI ''/''. O resultado é composto do status do atendimento, cabeçalhos informativos e o conteúdo da resposta. No exemplo, o status é a primeira linha (''HTTP/1.1 200 OK''), com os cabeçalhos logo a seguir. Os cabeçalhos terminam ao aparecer uma linha em branco, e em seguida vem o conteúdo (ou corpo) da resposta. | ||
+ | |||
+ | Todo documento possui um especificador de tipo de conteúdo, chamado de [http://en.wikipedia.org/wiki/Internet_media_type ''Internet media Type'']. O cabeçalho de resposta ''Content-type'' indica o ''media type'', para que o cliente HTTP (usualmente um navegador web) saiba como processá-lo. No exemplo acima, o documento retornado é do tipo ''text/html'', o que indica ser um texto HTML. Outros possíveis ''media types'' são: ''text/plain'' (texto simples), ''application/pdf'' (um texto PDF), ''application/x-gzip'' (um conteúdo compactado com gzip). | ||
+ | |||
+ | Um documento no contexto do servidor web é qualquer conteúdo que pode ser retornado como resposta a uma requisição HTTP. No caso mais simples, um documento corresponde a um arquivo em disco, mas também podem ser gerados dinamicamente. Existem diversas tecnologias para gerar documentos, tais como PHP, JSP, ASP, CGI, Python, Perl, Ruby, e possivelmente outras. Todas se caracterizam por uma linguagem de programação integrada intimamente ao servidor web, obtendo dele informação sobre como gerar o conteúdo da resposta. Atualmente, boa parte dos documentos que compõem um site web são gerados dinamicamente, sendo PHP, JSP e ASP as tecnologias mais usadas. | ||
+ | |||
+ | == Informações gerais sobre Apache no Ubuntu == | ||
+ | |||
+ | * Instalação: <syntaxhighlight lang=bash> | ||
+ | sudo apt-get install apache2 | ||
+ | </syntaxhighlight> | ||
+ | * Arquivos de configuração ficam em ''/etc/apache2'': | ||
+ | ** ''apache2.conf:'' a configuração inicia aqui | ||
+ | ** ''Diretório sites-available:'' configurações de hosts virtuais | ||
+ | ** ''Diretório sites-enabled:'' hosts virtuais atualmente ativados | ||
+ | * Para iniciar o Apache: <syntaxhighlight lang=bash> | ||
+ | sudo service apache2 start | ||
+ | </syntaxhighlight> | ||
+ | * ''Para testar o Apache:'' com um navegador acesse a URL http://seu-IP. | ||
+ | |||
+ | == Uma configuração básica == | ||
+ | |||
+ | O servidor Apache precisa de algumas informações básicas para poder ativar um site: | ||
+ | |||
+ | * ''Qual seu nome de servidor:'' seu nome DNS , como ''www.redesX.edu.br'' | ||
+ | * ''Em que portas ele atende requisições:'' as portas TCP onde ele recebe requisições HTTP. Por default é a porta 80, mas outras portas podem ser especificadas. | ||
+ | * ''Onde estão os documentos que compõem o site hospedado:'' o caminho do diretório onde estão esses documentos | ||
+ | * ''Quem pode acessar os documentos:'' restrições baseadas em endereços IP de clientes e/ou nomes de usuários e grupos. | ||
+ | |||
+ | |||
+ | '''IMPORTANTE''': Em um mesmo servidor Apache é possível hospedar diversas páginas Web diferentes, para isso é utilizado o conceito de Virtual Hosts que o Apache possui. Estas páginas diferentes (ou Virtual Hosts) podem ser baseados em endereços de IP ou portas diferentes ou baseados em nomes. Abaixo veremos um exemplo de configuração de cada um destes tipos: | ||
+ | |||
+ | |||
+ | '''Virtual Host baseado em endereço IP ou porta''' | ||
+ | |||
+ | Neste caso, para distinguir uma página Web da outra é utilizado um endereço de IP ou portas diferentes para cada um. Em caso de um servidor que possua mais de um endereço IP configurado, é possível associar cada Virtual Host a um destes IPs. Já se o servidor possui apenas um endereço IP, é possível distinguir cada Virtual Host por um número diferente de porta. | ||
+ | |||
+ | |||
+ | '''Exemplo baseado em porta diferente:''' | ||
+ | |||
+ | Deve-se criar um arquivo '''/etc/apache2/sites-available/nome_pagina.conf''', com o seguinte conteúdo: <syntaxhighlight lang=text> | ||
+ | # O nome de servidor | ||
+ | ServerName www.prj.edu.br | ||
+ | # As portas onde se atendem requisições HTTP | ||
+ | Listen 8080 | ||
+ | # Onde estão os documentos desse site | ||
+ | DocumentRoot /var/www/html/prj | ||
+ | # As restrições de acesso aos documentos | ||
+ | <Directory /var/www/html/prj> | ||
+ | Options Indexes | ||
+ | DirectoryIndex index.html index.php | ||
+ | order allow,deny | ||
+ | allow from all | ||
+ | </Directory> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | '''Virtual Host baseado em nome''' | ||
+ | |||
+ | Neste caso, para distinguir uma página Web da outra é verificado o parâmetro '''ServerName''' declarado dentro do arquivo de configuração de cada página Web. | ||
+ | |||
+ | |||
+ | '''Exemplo baseado em nome diferente:''' | ||
+ | |||
+ | Deve-se criar um arquivo '''/etc/apache2/sites-available/nome_pagina.conf''', com o seguinte conteúdo: <syntaxhighlight lang=text> | ||
+ | <VirtualHost *:80> | ||
+ | # Onde estão os documentos desse site | ||
+ | DocumentRoot /var/www/html/prj2 | ||
+ | |||
+ | # O nome de servidor | ||
+ | ServerName www.redes2.edu.br | ||
+ | |||
+ | # As restrições de acesso aos documentos | ||
+ | <Directory /var/www/html/prj2> | ||
+ | Options Indexes | ||
+ | DirectoryIndex index.html index.php | ||
+ | order allow,deny | ||
+ | allow from all | ||
+ | </Directory> | ||
+ | </VirtualHost> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==Atividade== | ||
+ | |||
+ | Na atividade abaixo, defina um servidor WWW chamado ''www.<seu_domínio>.br'', que atende requisições no ''port'' 8080. | ||
+ | |||
+ | # Crie o nome ''www.<seu_domínio>.br'' no seu servidor DNS. Associe um registro A a esse nome, para que aponte o endereço IP do servidor WWW a ser implantado. | ||
+ | #Crie o arquivo ''/etc/apache2/sites-available/seu_dominio.conf'' com o seguinte conteúdo: <syntaxhighlight lang=text> | ||
+ | # O nome de servidor | ||
+ | ServerName www.<seu_domínio>.br | ||
+ | # As portas onde se atendem requisições HTTP | ||
+ | Listen 8080 | ||
+ | # Onde estão os documentos desse site | ||
+ | DocumentRoot /var/www/html/prj | ||
+ | # As restrições de acesso aos documentos | ||
+ | <Directory /var/www/html/prj> | ||
+ | Options Indexes | ||
+ | DirectoryIndex index.html index.php | ||
+ | order allow,deny | ||
+ | allow from all | ||
+ | </Directory> | ||
+ | </syntaxhighlight> | ||
+ | #Crie um link simbólico para o arquivo acima:<syntaxhighlight lang=text> | ||
+ | ln -s /etc/apache2/sites-available/seu_dominio.conf /etc/apache2/sites-enabled/ </syntaxhighlight> | ||
+ | #Crie o diretório /var/www/html/prj | ||
+ | #Dentro do diretório criado acima, crie um arquivo de nome index.html com o seguinte conteúdo:<syntaxhighlight lang=text> | ||
+ | <html><body><h1>Meu porteiro</h1> | ||
+ | <p>Esta é minha pagina.</p> | ||
+ | </body></html> | ||
+ | </syntaxhighlight> | ||
+ | #Restarte o Apache: <syntaxhighlight lang=text> | ||
+ | service apache2 restart </syntaxhighlight> | ||
+ | #Com o navegador acesse a página do seu provedor. Ex: <nowiki>http://www.<seu_dominio>.br:8080/</nowiki> | ||
+ | #Crie uma página personalizada e coloque em /var/www/html/pessoal/index.html. Acesse <nowiki>http://www.<seu_dominio>.br:8080/pessoal</nowiki> e visualize-a. | ||
+ | |||
+ | Obs.: Para criar páginas HTML um pouco mais completas você pode ler o tutorial disponível [http://pt-br.html.net/tutorials/html/ aqui] | ||
+ | |||
+ | == Configuração no Servidor da equipe== | ||
+ | |||
+ | # No servidor, instale o Apache e crie uma página básica para a sua equipe; | ||
+ | # Implante um repositório de arquivos, onde ficam organizados documentos e manuais de sua empresa para acesso público | ||
+ | # Implante um repositório de arquivos onde a equipe técnica do provedor possa transferir arquivos (upload e download). Os acessos devem ser feitos via web e devidamente autenticados. ''Dica: veja a integração entre WWW e FTP.'' | ||
+ | # Teste o funcionamento do repositório de arquivos. | ||
+ | |||
+ | {{collapse bottom | Aula 30}} | ||
+ | |||
+ | = 01/12: Etapa 3: monitoramento da rede do porteiro = | ||
+ | |||
+ | {{collapse top | Aula 31}} | ||
+ | O monitoramento da rede e dos serviços é essencial para garantir a disponibilidade do porteiro. Quando problemas ocorrem, tais como quedas de links ou de servidores, a equipe técnica deve ser notificada o mais rápido possível para que possa repará-los. Devido à complexidade da estrutura do porteiro, são necessárias ferramentas para auxiliar em seu monitoramento. | ||
+ | |||
+ | [http://en.wikipedia.org/wiki/Network_management_system NMS (Network Management System)] é um sistema (incluindo hardware e software) onde se executam softwares para gerenciar uma rede de computadores. Um termo parecido para NMS é ''Network Monitoring System'', que se trata de um tipo específico de software para monitorar elementos de rede e seus serviços (ex: HTTP, SMTP, LDAP, DNS). | ||
+ | |||
+ | [[Imagem:NMS-1.jpg|800px]] | ||
+ | |||
+ | |||
+ | * [http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems Tabela comparativa entre sistemas de monitoramento de rede] | ||
+ | |||
+ | Existem muitos sistemas de monitoramento de rede, uma vez que o acompanhamento eficiente da saúde da rede é uma tarefa fundamental da gerência. Em uma grande rede, composta de muitos servidores, equipamentos de rede e diversos serviços, a equipe responsável precisa de ferramentas de auxílio ao acompanhamento de seu bom funcionamento. Essas ferramentas devem idealmente não somente mostrar se os componentes da rede estão funcionando como esperado, mas também alertar os responsáveis quando identificar algo errado. Além disso, como existe dependência tanto entre serviços de rede quanto entre equipamentos (e entre ambos), essas ferramentas devem senão apontar a causa raiz dos problemas, ao menos localizar os prováveis candidatos. Finalmente, é desejável que esses sistemas identifiquem e mostrem tendências de eventos na rede, a partir do histórico de funcionamento de seus componentes. São portanto muitos requisitos para os NMS, os quais não são totalmente atendidos por todos os softwares existentes. | ||
+ | |||
+ | '''''Alguns NMS interessantes:''''' | ||
+ | * [http://en.wikipedia.org/wiki/Zabbix Zabbix] | ||
+ | * [http://www.nagios.org Nagios] | ||
+ | * [http://www.cacti.net Cacti] | ||
+ | |||
+ | == Monitoramento com Cacti == | ||
+ | |||
+ | [http://www.cacti.net Cacti] é um coletor de dados e gerador automático de gráficos para fins de monitoramento e histórico de desempenho. Os dados devem ser numéricos, para possibilitar a geração de gráficos. Uma interface web possibilita a administração e visualização dos gráficos, como se pode ver abaixo: | ||
+ | |||
+ | |||
+ | [[Imagem:cacti1.png]] [[imagem:cacti2.png]] | ||
+ | |||
+ | |||
+ | No cacti os dados são coletados e armazenados numa base de dados especial ([http://oss.oetiker.ch/rrdtool/ RRD]). Quando solicitado, esses dados são apresentados em gráficos. Para cumprir essas tarefas, os seguintes elementos são definidos (nesta ordem): | ||
+ | # '''Dispositivos (Devices):''' equipamentos de onde se coletarão os dados. Cada equipamento pode ter uma ou mais fontes de dados (''Data Source''). | ||
+ | # '''Fontes de Dados (Data Sources):''' os atributos ou variáveis de um dispositivo cujos valores serão coletados. A coleta pode ser feita por diferentes mecanismos, como SNMP e execução de programas ou scripts. | ||
+ | # '''Gráficos (Graphs):''' os gráficos a serem gerados a partir de cada fonte de dados. Diferentes gráficos podem ser definidos para uma mesma fonte de dados, dependendo do que se deseja mostrar (valores médios ou máximos, por exemplo). | ||
+ | |||
+ | Muitos exemplos e tipos de dispositivos ou fontes de dados estão predefinidos no Cacti. Por exemplo, existem todas as definições para obter estatísticas de interfaces de rede usando SNMP. Como o cacti é muito flexível, podem-se criar novos tipos de fontes de dados, bastando definir como os dados devem ser coletados. | ||
+ | |||
+ | Mas afinal o que é SNMP ??? Basicamente, SNMP é um protocolo de gerenciamento de redes que possibilita, dentre outras coisas, obter informações sobre elementos de rede. Porém primeiro será instalado o Cacti, e depois isso será investigado com maiores detalhes ... | ||
+ | |||
+ | === Instalando o cacti === | ||
+ | |||
+ | No Ubuntu a instalação se mostra muito simplificada, pois o sistema de pacotes já configura todos os detalhes do cacti após a instalação. Se for instalado a partir do código fonte serão necessárias a configuração do banco de dados MySQL (para guardar informações administrativas. como definições de dispositivos, fontes de dados e gráficos) e a instalação de algumas extensões PHP. | ||
+ | |||
+ | # Instale o banco de dados mysql: <syntaxhighlight lang=bash> | ||
+ | sudo apt install -y mysql-server | ||
+ | </syntaxhighlight>... e fique atento à senha do administrador do banco. Você precisará dela durante a instalação do Cacti. | ||
+ | # Instale o cacti: <syntaxhighlight lang=bash> | ||
+ | sudo apt install -y cacti | ||
+ | </syntaxhighlight> | ||
+ | # Serão apresentadas telas com questões sobre a configuração do Cacti: | ||
+ | ## Selecione '''Sim''' para ''Configurar a base de dados para cacti com dbconfig-common?'' | ||
+ | ## Forneça a senha do administrador do MySQL (ela deve ter sido definida quando da instalação do banco de dados) | ||
+ | ## Forneça uma senha que será usada pelo usuário do cacti no banco de dados. Essa será a senha do cacti (não deve ser a do administrador). | ||
+ | ## Selecione o uso do Apache. | ||
+ | # Com um navegador acesse a URL ''http://IP_do_seu_host/cacti''. Ali você deve dar continuidade ao processo de instalação: | ||
+ | ## Selecione "New Install" | ||
+ | ## Verifique na próxima tela se todas as opções mostradas estão corretas (se aparece '''''OK''''' em verde ao lado). | ||
+ | ## Clique em ''Finish'', e na tela a seguir forneça o usuário ''admin'' e senha ''admin''. | ||
+ | |||
+ | == Atividades == | ||
+ | |||
+ | # Crie gráficos para monitorar a CPU, memória, discos, processos e usuários do servidor onde reside o Cacti. | ||
+ | #* Visualize os gráficos criados. | ||
+ | # Crie gráficos para as interfaces de rede do servidor onde reside o gráfico, usando SNMP (obs: use o host template ''ucd/net SNMP Host'' ao criar um ''device''). | ||
+ | #* Para realizar esta atividade, primeiro instale um agente SNMP: <syntaxhighlight lang=bash> | ||
+ | sudo apt install snmpd | ||
+ | </syntaxhighlight> | ||
+ | #* Habilite a consulta a dados via SNMP vinda de localhost. Descomente a seguinte linha em /etc/snmp/snmpd.conf: <syntaxhighlight lang=text> | ||
+ | rocommunity public localhost | ||
+ | </syntaxhighlight> | ||
+ | #* Reinicie o agente SNMP: <syntaxhighlight lang=bash> | ||
+ | sudo service snmp restart | ||
+ | </syntaxhighlight> | ||
+ | #* Finalmente, crie gráficos para as interfaces de rede do seu computador no Cacti. | ||
+ | # '''CURIOSIDADE:''' É possível coletar qualquer dado e graficá-lo. | ||
+ | #* As coletas dependem de um [http://www.cacti.net/downloads/docs/html/data_input_methods.html#NEW_DATA_INPUT_METHOD método de entrada de dados (Data Input Method)]; O ideal é criar um [http://www.cacti.net/downloads/docs/html/making_scripts_work_with_cacti.html script para a coleta dos dados]'' | ||
+ | #* Deve-se primeiro criar um ''Data Input Method'', em seguida um ''Data Template'', depois um ''Graph Template'' e finalmente um ''New Graph''. | ||
+ | |||
+ | {{collapse bottom | Aula 31}} | ||
+ | |||
+ | = 05/12: Etapa 3: monitoramento de eventos e geração de alertas na rede = | ||
+ | |||
+ | {{collapse top | Aula 32}} | ||
+ | Cacti é útil para registrar a atividade e acompanhar o uso de recursos na rede, porém não para identificar automaticamente situações que requeiram atenção da equipe técnica. O monitoramente de recursos para geração de alertas pode ser realização por outras ferramentas de gerenciamento, tais como [http://www.nagios.org/ Nagios]. | ||
+ | |||
+ | Basicamente, o Nagios é uma plataforma configurável de monitoramento de serviços e equipamentos de rede, capaz de emitir alertas e de efetuar ações de recuperação de falhas. Cada serviço ou tipo de equipamento pode ser monitorado com um plugin especializado, que assim efetua testes de disponibilidade sob medida. Por exemplo, um plugin de monitoramento do serviço HTTP (Web) pode tentar buscar uma ou mais páginas, e analisar tanto o status da resposta do servidor quanto o tempo que levou para obtê-la. A dependência entre os serviços pode ser configurada, de forma que ao se detectarem falhas por diferentes plugins, o Nagios possa apontar a causa raiz do problema. | ||
+ | |||
+ | * [http://www.nagios.org/documentation Documentação oficial do Nagios] | ||
+ | |||
+ | O ponto de partida do Nagios é a descrição da rede e de todos os serviços a serem monitorados. Cada monitoramento de serviço ou equipamento precisa ser parametrizado (por exemplo, quais os atrasos de resposta aceitáveis para o roteador de um link), para que se possam identificar as situações anômalas. Essas informações residem na configuração do Nagios, e precisam ser criadas manualmente. | ||
+ | |||
+ | '''OBS:''' existem outros sistemas de monitoramento e alerta, tais como [http://www.zabbix.org Zabbix] e [https://pandorafms.org/en/ PandoraFMS]. Algumas comparações entre esses sistemas podem ser encontradas, tais como: | ||
+ | * [https://www.lume.ufrgs.br/bitstream/handle/10183/66105/000870983.pdf Um TCC que compara Nagios e Zabbix] | ||
+ | * [https://blog.pandorafms.org/zabbix-vs-nagios-vs-pandorafms-an-in-depth-comparison/ Uma comparação entre Nagios, Zabbix e PandoraFMS] | ||
+ | |||
+ | |||
+ | == Instalação == | ||
+ | |||
+ | # Instale o Nagios: <syntaxhighlight lang=bash> | ||
+ | sudo apt install nagios3 | ||
+ | </syntaxhighlight> | ||
+ | # Dentro de ''/etc/nagios3'' há vários arquivos de configuração, iniciando com ''nagios.cfg''. Esse arquivo contém a configuração global, e a informação de que outros arquivos devem ser incluídos. As configurações específicas ficam em arquivos dentro de ''/etc/nagios3/conf.d''. Cada elemento monitorado é definido por um ''objeto'', havendo basicamente ''hosts'' (equipamentos) e ''services'' (serviços que residem nos equipamentos). Por exemplo, o arquivo ''localhost-nagios2.cfg'' ali existente inicia assim: <syntaxhighlight lang=text> | ||
+ | define host{ | ||
+ | use generic-host ; Name of host template to use | ||
+ | host_name localhost | ||
+ | alias localhost | ||
+ | address 127.0.0.1 | ||
+ | } | ||
+ | |||
+ | # Define a service to check the disk space of the root partition | ||
+ | # on the local machine. Warning if < 20% free, critical if | ||
+ | # < 10% free space on partition. | ||
+ | |||
+ | define service{ | ||
+ | use generic-service ; Name of service template to use | ||
+ | host_name localhost | ||
+ | service_description Disk Space | ||
+ | check_command check_all_disks!20%!10% | ||
+ | } | ||
+ | |||
+ | |||
+ | |||
+ | # Define a service to check the number of currently logged in | ||
+ | # users on the local machine. Warning if > 20 users, critical | ||
+ | # if > 50 users. | ||
+ | |||
+ | define service{ | ||
+ | use generic-service ; Name of service template to use | ||
+ | host_name localhost | ||
+ | service_description Current Users | ||
+ | check_command check_users!20!50 | ||
+ | } | ||
+ | |||
+ | |||
+ | # Define a service to check the number of currently running procs | ||
+ | # on the local machine. Warning if > 250 processes, critical if | ||
+ | # > 400 processes. | ||
+ | |||
+ | define service{ | ||
+ | use generic-service ; Name of service template to use | ||
+ | host_name localhost | ||
+ | service_description Total Processes | ||
+ | check_command check_procs!250!400 | ||
+ | } | ||
+ | |||
+ | |||
+ | |||
+ | # Define a service to check the load on the local machine. | ||
+ | |||
+ | define service{ | ||
+ | use generic-service ; Name of service template to use | ||
+ | host_name localhost | ||
+ | service_description Current Load | ||
+ | check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0 | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | # Edite o arquivo ''/etc/apache2/sites-enabled/000-default'' para incluir a configuração da interface web do Nagios. Acrescente esta linha dentro da declaração de VirtualHost: <syntaxhighlight lang=text> | ||
+ | Include /etc/nagios3/apache2.conf | ||
+ | </syntaxhighlight>... e, em seguida, reinicie o apache. | ||
+ | # Acesse a interface web do Nagios pela URL ''http://IP_do_seu_host/nagios3''. Após autenticar o usuário ''nagioasdmin'' deve aparecer a seguinte tela:<br><br>[[imagem:Nagios1.png|600px]] | ||
+ | |||
+ | == Exemplos de configurações == | ||
+ | |||
+ | A configuração do Nagios fica no diretório ''/etc/nagios3''. Todos os arquivos mencionados abaixo se referem a esse diretório, salvo se for indicado o contrário. O arquivo de configuração principal se chama ''nagios.cfg'', que contém opções globais e inclusões de outros arquivos com configurações específicas. Em particular, arquivos que tratam de objetos monitorados e informacões relacionadas (hosts, serviços, comandos e templates). ficam dentro do subdiretório ''objects''. | ||
+ | |||
+ | === Definições de hosts === | ||
+ | |||
+ | Para configurar o Nagios, devem-se primeiro criar definições de ''hosts'' (equipamentos monitorados). Esas definições ficam em algum arquivo dentro do subdiretório ''conf.d'', o qual deve estar incluído em ''nagios.cfg'' (veja o exemplo contido em ''localhost_nagios2.cfg''). Cada ''host'' definido é automaticamente monitorado com PING, de forma a verificar se está no ar. Um ''host'' é declarado como a seguir: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | define host{ | ||
+ | use generic-host ; Nome do template de host a ser usado | ||
+ | ; Este host irá herdar toas a variáveis que estão definidas | ||
+ | ; no template linux-server (ou que foram herdadas por ele). | ||
+ | host_name gateway ; nome do host na rede | ||
+ | alias Gateway do Lab. ; Descrição do host | ||
+ | address 192.168.2.1 | ||
+ | parents localhost ; qual o próximo host em direção ao Nagios | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O uso de templates simplifica a definição de ''hosts'', pois evita a repetição de muitas opções comuns (veja como seria a [http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#host definição completa de um ''host'']). Os templates estão nos arquivos ''generic-host_nagios2.cfg'' e ''generic-service_nagios2.cfg''. | ||
+ | |||
+ | A opção ''parents'' tem grande importância para possibilitar que o Nagios faça a distinção entre hosts ou serviços falhos ou inalcançáveis. O primeiro caso trata de serviços cujos testes programados falharam, e o segundo caso são aqueles que não podem ser testados, porque dependem de um ''host'' intermediário (um gateway) que falhou. Assim pode-se evitar a emissão de alertas para todos os serviços, concentrando-os na causa raiz do problema. | ||
+ | |||
+ | === Definições de serviços === | ||
+ | |||
+ | Em cada ''host'' devem ser criadas definições de serviços a serem monitorados. Cada serviço possui um comando de verificação específico, para que o teste seja mais fidedigno. Duas definições de serviços são mostradas abaixo (para IMAP e DNS): | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | define service{ | ||
+ | use generic-service ; Nome do template de serviço a ser usado | ||
+ | host_name localhost ; Host onde reside o serviço | ||
+ | service_description IMAP | ||
+ | check_command check_imap ; Comando para verificar o serviço | ||
+ | notifications_enabled 0 ; Notificações desabilitadas | ||
+ | } | ||
+ | |||
+ | define service{ | ||
+ | use generic-service | ||
+ | host_name localhost | ||
+ | service_description DNS | ||
+ | check_command check_dns | ||
+ | notifications_enabled 0 | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Assim como no caso de ''hosts'', usam-se templates para evitar a repetição de opções de uso comum (ver [http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#service definição completa de um serviço]). | ||
+ | |||
+ | === Definições de comandos === | ||
+ | |||
+ | * [http://nagios-plugins.org/doc/man/index.html Documentação sobre todos os comandos] | ||
+ | |||
+ | |||
+ | Os comandos de verificação de serviço são programas especializados, e que são fornecidos pelo pacote [http://nagiosplugins.org/ nagios-plugins] (que foi instalado junto com o Nagios). A lista de plugins segue abaixo: | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Plugin | ||
+ | !Descrição | ||
+ | |- | ||
+ | |'''''check_apt''''' || This plugin checks for software updates on systems that use package management systems based on the apt-get(8) command found in Debian GNU/Linux | ||
+ | |- | ||
+ | |'''''check_breeze''''' || This plugin reports the signal strength of a Breezecom wireless equipment | ||
+ | |- | ||
+ | |'''''check_by_ssh''''' || Esse pug-in usa SSH para executar comandos no servidor remoto | ||
+ | |- | ||
+ | |'''''check_clamd''''' || This plugin tests CLAMD connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_cluster''''' || Plugin servidor/serviço de cluster para nagios 2 | ||
+ | |- | ||
+ | |'''''check_dhcp''''' || Esse plug-in testa a disponibilidade dos servidores DHCP na rede. | ||
+ | |- | ||
+ | |'''''check_dig''''' || Este plug-in testa o serviço de DNS no computador especificado usando dig | ||
+ | |- | ||
+ | |'''''check_disk''''' || Este plug-in verifica a quantidade de espaço utilizado no sistema de arquivos montado e gera um alerta caso o espaço livre seja menos que um dos valores limites | ||
+ | |- | ||
+ | |'''''check_disk_smb''''' || Perl Check SMB Disk plugin for Nagios | ||
+ | |- | ||
+ | |'''''check_dns''''' || Esse complemento utiliza o programa nslookup para obter o endereço IP do host/domínio consultado. Um servidor DNS opcional pode ser especificado. Se um servidor DNS não é especificado, o(s) servidor(es) padrão(es) no arquivo /ect/resolv.conf serão utilizados. | ||
+ | |- | ||
+ | |'''''check_dummy''''' || Este plugin irá simplesmente retornar ao estado correspondente para o valor numérico do <estado> do argumento com texto opcional | ||
+ | |- | ||
+ | |'''''check_file_age''''' || testa o tamanho de um arquivo, ou há quanto tempo ele existe (sua idade). | ||
+ | |- | ||
+ | |'''''check_flexlm''''' || Check available flexlm license managers | ||
+ | |- | ||
+ | |'''''check_ftp''''' || This plugin tests FTP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_hpjd''''' || Esse plug-in testa o ESTADO de uma impressora HP com um cartão JetDirect. Net-snmp deve estar instalado no computador com o plug-in. | ||
+ | |- | ||
+ | |'''''check_http''''' || Esse plug-in testa o serviço HTTP no servidor especificado. Pode testar servidores normais (http) e seguros (https), seguir redirecionamentos, pesquisar por strings e expressões regulares, verifica tempo de conexões, e reporta sobre tempo de expiração de certificados. | ||
+ | |- | ||
+ | |'''''check_icmp''''' || Testa um host com PING. | ||
+ | |- | ||
+ | |'''''check_ide_smart''''' || This plugin checks a local hard drive with the (Linux specific) [http://smartlinux.sourceforge.net/smart/index.php SMART interface]. | ||
+ | |- | ||
+ | |'''''check_ifoperstatus''''' || Checks the operational status of a particular network interface on the target host. | ||
+ | |- | ||
+ | |'''''check_ifstatus''''' || Checks the operational status of a particular network interface on the target host. | ||
+ | |- | ||
+ | |'''''check_imap''''' || This plugin tests IMAP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_ircd''''' || Perl Check IRCD plugin for Nagios | ||
+ | |- | ||
+ | |'''''check_load''''' || Este plug-in testa a média de carga do sistema atual. | ||
+ | |- | ||
+ | |'''''check_log''''' || Log file pattern detector plugin for Nagios. | ||
+ | |- | ||
+ | |'''''check_mailq''''' || Checks the number of messages in the mail queue (supports multiple sendmail queues, qmail). | ||
+ | |- | ||
+ | |'''''check_mrtg''''' || Este plug-in irá verificar tanto o valor médio ou máximo de um das duas variáveis gravadas em um arquivo de log MRTG. | ||
+ | |- | ||
+ | |'''''check_mrtgtraf''''' || Este plug-in irá verificar a entrada/saída das taxas de transferência de um roteador, switch, etc registrado em um log do MRTG. Se a entrada do novo registro é mais velha que <expire_minutes>, um estado AVISO é retornado. Se tanto as taxas de entrada ou de saída excederem o limite <icl> ou <ocl> (em Bytes/seg), resulta em um estado CRÍTICO. Se qualquer uma das taxas de ultrapassar o limite <iwl> ou <owl> (em Bytes/seg), resulta em um estado AVISO. | ||
+ | |- | ||
+ | |'''''check_nagios''''' || This plugin checks the status of the Nagios process on the local machine The plugin will check to make sure the Nagios status log is no older than the number of minutes specified by the expires option. It also checks the process table for a process matching the command argument. | ||
+ | |- | ||
+ | |'''''check_nntp''''' || This plugin tests NNTP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_nt''''' || This plugin collects data from the NSClient service running on a Windows NT/2000/XP/2003 server. | ||
+ | |- | ||
+ | |'''''check_ntp''''' || This plugin checks the selected ntp server | ||
+ | |- | ||
+ | |'''''check_ntp_peer''''' || This plugin checks the selected ntp server | ||
+ | |- | ||
+ | |'''''check_ntp_time''''' || This plugin checks the clock offset with the ntp server | ||
+ | |- | ||
+ | |'''''check_nwstat''''' || This plugin attempts to contact the MRTGEXT NLM running on a Novell server to gather the requested system information. | ||
+ | |- | ||
+ | |'''''check_oracle''''' || Check Oracle Database status. | ||
+ | |- | ||
+ | |'''''check_overcr''''' || This plugin attempts to contact the Over-CR collector daemon running on the remote UNIX server in order to gather the requested system information. | ||
+ | |- | ||
+ | |'''''check_ping''''' || Use ping to check connection statistics for a remote host. | ||
+ | |- | ||
+ | |'''''check_pop''''' || This plugin tests POP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_procs''''' || Checks all processes and generates WARNING or CRITICAL states if the specified metric is outside the required threshold ranges. The metric defaults to number of processes. Search filters can be applied to limit the processes to check. | ||
+ | |- | ||
+ | |'''''check_real''''' || This plugin tests the REAL service on the specified host. | ||
+ | |- | ||
+ | |'''''check_rpc''''' || Check if a rpc service is registered and running using ''rpcinfo -H host -C rpc_command'' | ||
+ | |- | ||
+ | |'''''check_sensors''''' || This plugin checks hardware status using the lm_sensors package. | ||
+ | |- | ||
+ | |'''''check_smtp''''' || This plugin will attempt to open an SMTP connection with the host. | ||
+ | |- | ||
+ | |'''''check_snmp''''' || Check status of remote machines and obtain system information via SNMP | ||
+ | |- | ||
+ | |'''''check_ssh''''' || Try to connect to an SSH server at specified server and port | ||
+ | |- | ||
+ | |'''''check_swap''''' || Check swap space on local machine. | ||
+ | |- | ||
+ | |'''''check_tcp''''' || This plugin tests TCP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_time''''' || This plugin will check the time on the specified host. | ||
+ | |- | ||
+ | |'''''check_udp''''' || This plugin tests UDP connections with the specified host (or unix socket). | ||
+ | |- | ||
+ | |'''''check_ups''''' || This plugin tests the UPS service on the specified host. Network UPS Tools from www.networkupstools.org must be running for this plugin to work. | ||
+ | |- | ||
+ | |'''''check_users''''' || This plugin checks the number of users currently logged in on the local system and generates an error if the number exceeds the thresholds specified. | ||
+ | |- | ||
+ | |'''''check_wave''''' || Checks the strength of received signal in a wireless interface. | ||
+ | |} | ||
+ | |||
+ | |||
+ | Cada plugin possui seus argumentos de linha de comando, que são usados para passar parâmetros de execução. A explicação detalhada pode ser obtida executando-se o programa do plugin e passando a opção ''-h'': | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | msobral@ger:~$ cd /usr/lib/nagios/plugins | ||
+ | msobral@ger:/usr/lib/nagios/plugins$ ./check_dns -h | ||
+ | check_dns v1.5 (nagios-plugins 1.5) | ||
+ | Copyright (c) 1999 Ethan Galstad <nagios@nagios.org> | ||
+ | Copyright (c) 2000-2008 Nagios Plugin Development Team | ||
+ | <nagiosplug-devel@lists.sourceforge.net> | ||
+ | |||
+ | Esse complemento utiliza o programa nslookup para obter o endereço IP do host/domínio consultado. | ||
+ | Um servidor DNS opcional pode ser especificado. | ||
+ | Se um servidor DNS não é especificado, o(s) servidor(es) padrão(es) no arquivo /ect/resolv.conf serão utilizados. | ||
+ | |||
+ | |||
+ | Uso: | ||
+ | check_dns -H host [-s server] [-a expected-address] [-A] [-t timeout] [-w warn] [-c crit] | ||
+ | |||
+ | Opções: | ||
+ | -h, --help | ||
+ | Imprime uma tela de ajuda detalhada | ||
+ | -V, --version | ||
+ | Imprime informação da versão | ||
+ | --extra-opts=[seção][@arquivo] | ||
+ | Ler opções de um arquivo ini. Veja http://nagiosplugins.org/extra-opts | ||
+ | para exemplos de utilização. | ||
+ | -H, --hostname=HOST | ||
+ | O nome ou endereço que você deseja consultar | ||
+ | -s, --server=HOST | ||
+ | Servidor DNS opcional que você que utilizar para fazer consultas | ||
+ | -a, --expected-address=IP-ADDRESS|HOST | ||
+ | ENDEREÇO-IP opcional que você espera o servidor DNS retornar. SERVIDOR deve acabar com | ||
+ | um ponto (.). Essa opção pode ser repetida várias vezes (Retorna OK se qualquer | ||
+ | corresponde ao valor). Se vários endereços são retornados de uma vez, você tem que combinar | ||
+ | a cadeia completa de endereços separados por vírgulas (ordenados alfabeticamente) | ||
+ | -A, --expect-authority | ||
+ | Opcionalmente a espera pelo servidor DNS deve ser autorizada para a pesquisa | ||
+ | -w, --warning=seconds | ||
+ | Retorna um aviso se o tempo decorrido exceder o valor. Padrão off | ||
+ | -c, --critical=seconds | ||
+ | Retorno crítico se o tempo decorrido exceder o valor. Padrão off | ||
+ | -t, --timeout=INTEIRO | ||
+ | Segundos antes da conexão expirar (padrão: 10) | ||
+ | |||
+ | Enviar e-mail para nagios-users@lists.sourceforge.net se você tiver dúvidas | ||
+ | quanto ao uso deste software. Para enviar correções ou sugerir melhorias, | ||
+ | enviar e-mail para nagiosplug-devel@lists.sourceforge.net | ||
+ | |||
+ | msobral@ger:/usr/lib/nagios/plugins$ | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Nem todos os plugins acima são adicionados automaticamente à configuração do Nagios na instalação. O arquivo ''commands.cfg'' contém os comandos preconfigurados. Assim, caso seja necessário adicionar um plugin que ainda não esteja ali (ex: ''check_dns''), deve-se criar uma definição de comando: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | define command{ | ||
+ | command_name check_dns | ||
+ | command_line $USER1$/check_dns -H www.google.com.br -s $HOSTADDRESS$ | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O importante acima é a definição de como o plugin deve ser executado, incluindo os parâmetros que devem ser passados. Alguns parâmetros são predefinidos pelo Nagios, estando disponíveis em macros: | ||
+ | |||
+ | * '''''$HOSTADDRESS$: ''''' o endereço do ''host'' onde reside o serviço a ser testado. | ||
+ | * '''''$ARG1$: ''''' o primeiro argumento incluído na definição de serviço. | ||
+ | * '''''$ARG2$: ''''' o segundo argumento incluído na definição de serviço. | ||
+ | * '''''$ARGn$: ''''' o n-ésimo argumento incluído na definição de serviço. | ||
+ | |||
+ | Para exemplificar como passar parâmetros para os plugins, veja o caso de um teste do tipo PING: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | define service{ | ||
+ | host_name linuxbox | ||
+ | service_description PING | ||
+ | check_command check_ping!200.0,80%!400.0,40% | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O comando ''check_ping'' deve ser chamado com dois argumentos (separados por ''!''): ''200.0,80%'' e ''200.0,80%''. A definição do comando ''check_ping'', por sua vez, os utiliza da seguinte forma: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | define command{ | ||
+ | command_name check_ping | ||
+ | command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | == Ativando as novas configurações == | ||
+ | |||
+ | Sempre que modificar a configuração o Nagios deve ser reiniciado: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | sudo service nagios3 reload | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Caso ocorra um erro, e o nagios não inicie, significa que existe um ou mais erros nos arquivos de configuração. Para encontrá-los execute o nagios com a opção ''-v'', que faz uma verificação desses arquivos: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | $ cd /etc/nagios3 | ||
+ | $ nagios3 -v nagios.cfg | ||
+ | Total Warnings: 3 | ||
+ | Total Errors: 0 | ||
+ | |||
+ | Things look okay - No serious problems were detected during the pre-flight check | ||
+ | |||
+ | </syntaxhighlight> | ||
+ | |||
+ | == Atividades == | ||
+ | |||
+ | # Instale o Nagios na mesma máquina onde está o Cacti. | ||
+ | # Crie uma configuração inicial para monitorar os serviços em seu servidor (HTTP, DNS, Asterisk) e o gateway do provedor, e um servidor web externo. | ||
+ | # Crie uma dependência entre o gateway e o servidor web externo: para chegar a esse servidor é necessário que o gateway esteja ativo. | ||
+ | # Veja o que o Nagios reporta quando o gateway fica fora do ar (o professor irá simular isso). | ||
+ | # Estenda a configuração do Nagios para monitorar a conectividade da rede do provedor. Quer dizer, ele deve monitorar a conectividade com a Internet e quando ela ficar fora do ar deve indicar se o problema está no provedor ou se é externo. | ||
+ | # Configure o envio de alertas para a queda do serviço de email ou web. Esses alertas devem ser enviados por email para o administrador da rede (ou por SMS). | ||
+ | # Crie um monitoramento de serviço para monitorar a quantidade de chamadas VoIP em andamento estabelecidas no PBX do provedor. | ||
+ | # Integre o Cacti ao Nagios, de forma que se associem os gráficos gerados pelo Cacti aos equipamentos monitorados pelo Nagios. | ||
+ | |||
+ | {{collapse bottom | Aula 32}} | ||
+ | |||
+ | = 08/12: Etapa 3: SNMP = | ||
+ | |||
+ | {{collapse top | Aula 33}} | ||
+ | * [http://en.wikipedia.org/wiki/Snmp Artigo na Wikipedia sobre SNMP] | ||
+ | * [http://www.teleco.com.br/tutoriais/tutorialmodelotmn/pagina_1.asp Tutorial sobre gerência de redes] | ||
+ | * Ver RFCs relacionadas: | ||
+ | ** [http://www.javvin.com/protocol/rfc1157.pdf RFC 1157 - SNMP] | ||
+ | ** [http://www.javvin.com/protocol/rfc1156.pdf RFC 1156 - MIB] | ||
+ | ** [http://www.javvin.com/protocol/rfc34218.pdf RFC 3418 - MIB para SNMPv2] | ||
+ | ** [http://en.wikipedia.org/wiki/RMON Artigo na Wikipedia sobre RMON (Remote Monitoring)] | ||
+ | ** [http://tools.ietf.org/html/rfc3577 RFC 3577 - Uma introdução a MIB RMON] | ||
+ | ** [http://tools.ietf.org/html/rfc2819 RFC 2819 - RMON1 MIB] | ||
+ | ** [http://tools.ietf.org/html/rfc2021 RFC 2021 - RMON2 MIB] | ||
+ | ** [http://tools.ietf.org/html/rfc2613 RFC 2613 - Extensões da RMON MIB para redes comutadas] | ||
+ | |||
+ | |||
+ | O modelo SNMP (''Simple Network Management Protocol'') foi o primeiro modelo de gerenciamento não proprietário desenvolvido pelo [http://www.ietf.org/ IETF] (Internet Engineering Task Force), apresentando facilidade de implementação e possibilitando o gerenciamento de sistemas heterogêneos. Ele consiste em um esquema centralizado de gerência baseado num modelo Agente/Gerente, utilizando o protocolo de gerenciamento SNMP. | ||
+ | |||
+ | Desde o lançamento da primeira versão, na década de 80, o SNMP mantém-se como um protocolo simples de gerenciamento e é amplamente utilizado no gerenciamento de sistemas na Internet. Por isso, esse modelo também é denominado de Modelo de Gerenciamento da Internet . | ||
+ | |||
+ | * [http://www.tcpipguide.com/free/t_TCPIPNetworkManagementFrameworkandProtocolsSNMPand.htm Modelo SNMP no TCP Guide] | ||
+ | |||
+ | O modelo SNMP, e a maior parte dos sistemas de gerenciamento disponíveis, se baseia no modelo Agente/Gerente, que normalmente é formado pelos seguintes elementos: | ||
+ | |||
+ | * '''Agente:''' Programa executado nos elementos de rede a serem gerenciados. Tem como função responder as solicitações vindas do Gerente e gerar mensagens a cada alteração de status de um determinado objeto; | ||
+ | * '''Gerente:''' Programa executado em um elemento de rede que realiza a interface entre o usuário final é o sistema de gerenciamento, ou seja, realiza a conversão das solicitações do usuário em ações que serão executadas na rede; | ||
+ | * '''Protocolo de Gerenciamento:''' Protocolo que normaliza a troca de informações entre um gerente e um agente. É o elemento principal de uma rede de gerenciamento. Esta troca de informações pode acontecer de duas formas: Interações comando/resposta do Gerente para o Agente (o Gerente faz uma solicitação e o Agente responde) e apenas envio de informações do Agente para o Gerente sem a solicitação prévia (também conhecido como mensagens do tipo TRAP); | ||
+ | * '''MIB (Management Information Base):''' Por último, a MIB é uma base de dados localizada no Agente que contém as informações e a estrutura dos objetos que podem ser gerenciados pelo Gerente. Esses objetos a serem gerenciados podem ser, por exemplo, uma interface serial ou uma fonte em um roteador. | ||
+ | |||
+ | |||
+ | Há dois tipos de dispositivos no modelo SNMP: | ||
+ | * '''Nodo gerenciado:''' equipamento na rede que possui o software necessário para ser gerenciado (o agente). | ||
+ | * '''Estação de gerenciamento de rede (NMS - Network Management Station):''' um equipamento que possui o software para gerenciar os ''nodos gerenciados'' (o gerente). | ||
+ | |||
+ | |||
+ | Note que esse modelo trata da execução de operações de gerência sobre os nodos gerenciados, que são equipamentos que desempenham alguma função de comunicação na rede, tal como um roteador, switch, servidor, ou um simples computador desktop. Do ponto de vista da gerência de redes, cada nodo gerenciado se constitui de um conjunto de objetos passíveis de serem gerenciados, os quais descrevem atributos de componentes do nodo gerenciado. Por exemplo, objetos relacionados com uma interface de rede podem ser sua descrição, endereço, contadores de pacotes recebidos e enviados, contadores de erros de recepção e transmissão, entre outros. As operações de gerência, portanto, são traduzidas para leituras ou modificações dos valores desses objetos. | ||
+ | |||
+ | |||
+ | == O protocolo SNMP == | ||
+ | |||
+ | O protocolo SNMP serve para transmitir as informações das operações de gerência entre gerente e agentes. Ele usa o protocolo UDP, com port padrão 161. Há quatro comandos básicos (SNMPv1) que operam em modo comando-resposta originado no gerente (com exceção de TRAP): | ||
+ | |||
+ | * '''GET:''' lê um ou mais valores de atributos de um objeto em um elemento de rede. Implementado com as PDUs GetRequest e GetResponse. | ||
+ | * '''SET:''' modifica um ou mais valores de atributos de um objeto em um elemento de rede. Implementado com as PDUs SetRequest e SetResponse. | ||
+ | * '''GET-NEXT:''' lê iterativamente um ou mais valores de atributos de um objeto em um elemento de rede. Implementado com as PDUs GetNextRequest e GetResponse. | ||
+ | * '''TRAP:''' notifica o gerente sobre a modificação de um atributo vigiado. Implementado com a PDU Trap. | ||
+ | |||
+ | |||
+ | * Maiores detalhes sobre PDUs SNMP: | ||
+ | ** [http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat.htm Formatos de mensagens SNMP] | ||
+ | ** [http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat-3.htm A PDU Trap] | ||
+ | |||
+ | == Nomenclatura de objetos na MIB == | ||
+ | |||
+ | Todos os objetos acessados pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o Gerente e o Agente devem concordar sobre os nomes e significados das operações GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como MIB (do inglês: Management Information Base). O padrão SNMP não define o MIB, mas apenas o formato e o tipo de codificação das mensagens. A especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, são especificados por RFCs próprios. | ||
+ | |||
+ | Cada variável em uma MIB se chama objeto da MIB, e é definida usando a linguagem de descrição de dados SMI. Um dispositivo de rede pode ter muitos objetos, que correspondem aos diferentes elementos de hardware e software nele contidos. Para possibilitar que novos objetos de MIB sejam facilmente definidos, grupos de objetos de MIB relacionados estão definidos em RFCs separadas chamados de módulos MIB. | ||
+ | |||
+ | * [http://en.wikipedia.org/wiki/Management_information_base Texto sobre MIB na wikipedia] | ||
+ | * [http://cooperati.com.br/2011/09/20/o-protocolo-snmp/ Outro texto] | ||
+ | |||
+ | [[Imagem:Snmp-mib-hierarchy.gif|600px]] | ||
+ | <br>''Resumo da hierarquia da MIB'' | ||
+ | |||
+ | |||
+ | Um objeto ou ramo da MIB é identificado por seu caminho desde a raiz (chamado de ''OID: Object Identifier''), com uma notação parecida com um caminho de um arquivo em um diretório: | ||
+ | |||
+ | .iso.org.dod.internet.mgmt.mib-2.application | ||
+ | |||
+ | |||
+ | Na verdade, um OID se constitui de uma sequência de números que identificam o caminho na MIB. Os nomes são apenas uma forma de torná-los mais facilmente compreensíveis por um ser humano. Assim, o OID acima em notação numérica é: | ||
+ | |||
+ | .1.3.6.1.2.1.27.1.1.8.2 | ||
+ | |||
+ | |||
+ | Usualmente, caso o OID não inicie com um ponto assume-se que ele esteja abaixo de ''.iso.org.dod.internet.mgmt.mib. (1.3.6.1.2.1)''. Assim, o OID a seguir: | ||
+ | |||
+ | system.syslocation.0 | ||
+ | |||
+ | ... corresponde na verdade ao OID: | ||
+ | |||
+ | .iso.org.dod.internet.mgmt.mib.system.syslocation.0 | ||
+ | |||
+ | == Software net-snmp == | ||
+ | |||
+ | O projeto [http://www.net-snmp.org net-snmp] provê uma implementação de um agente SNMP e de utilitários para fazer operações sobre MIBs (assim, fornece também a base para a implementação de um gerente). Para instalá-lo deve-se executar: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | sudo apt install -y snmpd | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Esse pacote contém os seguintes programas: | ||
+ | * [http://manpages.ubuntu.com/manpages/trusty/man8/snmpd.8.html snmpd]: o agente SNMP | ||
+ | * [http://manpages.ubuntu.com/manpages/trusty/en/man1/snmpwalk.1.html snmpwalk]: navegação por uma MIB (modo texto) | ||
+ | * [http://manpages.ubuntu.com/manpages/trusty/en/man1/snmpget.1.html snmpget]: lê valores de OID de uma MIB | ||
+ | * [http://manpages.ubuntu.com/manpages/trusty/en/man1/snmpset.1.html snmpset]: modifica valores de um OID em uma MIB | ||
+ | * ... e outros mais específicos (ver a documentação) | ||
+ | |||
+ | |||
+ | Para configurar o agente SNMP, pode-se editar manualmente o arquivo ''/etc/snmp/snmpd.conf'', ou executar o utilitário [http://manpages.ubuntu.com/manpages/trusty/en/man1/snmpconf.1.html snmpconf]. | ||
+ | |||
+ | O agente SNMP vem preconfigurado para atender somente requisições vindas de localhost (127.0.0.1). Edite o arquivo ''/etc/snmp/snmpd.conf'', e modifique a variável ''agentAddress'' para que ele aceite requisições vindas de outras interfaces. Ela pode ficar desta forma: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | agentAddress udp:0.0.0.0:161 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | == Atividades == | ||
+ | # Use o utilitário snmpwalk para mostrar os OIDs presentes por default na instalação do snmpd. Use-o da seguinte forma: <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v1 -c public 127.0.0.1 | ||
+ | </syntaxhighlight>Experimente usá-lo também assim: <syntaxhighlight lang=bash> | ||
+ | snmpwalk -v1 -c public -Of 127.0.0.1 | ||
+ | # ... ou assim: | ||
+ | snmpwalk -v1 -c public -Ofn 127.0.0.1 | ||
+ | </syntaxhighlight> | ||
+ | # ... ou direcionado a outros agentes (tais como o WOM 5000, que está em 192.168.1.254). | ||
+ | # Configure seu agente SNMP para ativar as MIBs IP e TCP. Em seguida use novamente o snmpwalk para visualizar os OIDs. | ||
+ | # Experimente usar [http://tele.sj.ifsc.edu.br/~msobral/pji2/mibbrowser.zip este navegador de MIB] (''MIB browser''), que acessa os valores dos objetos de forma gráfica. | ||
+ | # Usando o utilitário snmpset modifique o valor do OID system.sysContact.0 (corresponde ao nome do técnico responsável pelo nodo gerenciado). | ||
+ | |||
+ | {{collapse bottom | Aula 33}} | ||
+ | |||
+ | = 11/12: Etapa 3: A rede completa com monitoramento e alertas = | ||
+ | |||
+ | {{collapse top | Aula 34}} | ||
+ | |||
+ | {{collapse bottom | Aula 34}} | ||
+ | |||
+ | = 15/12: Etapa 3: Avaliação final = | ||
+ | |||
+ | {{collapse top | Aula 35}} | ||
+ | A avaliação final envolve implantar esta rede: | ||
+ | |||
+ | |||
+ | [[imagem:PJI4-Avaliacao2b-20172.jpg]] | ||
+ | |||
+ | |||
+ | Deve-se usar OBRIGATORIAMENTE um telefone IP. Tanto o celular quanto o telefone IP podem ser registrados em quaisquer dos PBX, e em diferentes combinações, para realizar as atividades a seguir. | ||
+ | |||
+ | Nessa rede, deve-se fazer o seguinte: | ||
+ | *Ramais no PBX1 possuem prefixo 48 e números de 4 dígitos. Ex: 481000 | ||
+ | *Ramais no PBX2 possuem prefixo 84 e números de 4 dígitos. Ex: 845566 | ||
+ | *Prefixos são opcionais no caso de chamadas entre ramais de um mesmo PBX. Assim, tanto faz serem omitidos ou não. | ||
+ | *Chamadas entre ramais de diferentes PBX obrigatoriamente devem incluir o prefixo | ||
+ | * O servidor de monitoramento deve: | ||
+ | **Monitorar a vazão da interface WAN da rede do PBX1 | ||
+ | **Monitorar a vazão e quantidade de pacotes do telefone IP | ||
+ | **Monitorar a vazão e quantidade de pacotes do PBX2 | ||
+ | **Monitorar se PBX1, PBX2, telefone IP e roteador sem-fios estão ativos e alcançáveis | ||
+ | **Monitorar se o Asterisk está ativado no PBX1 e no PBX2 | ||
+ | |||
+ | |||
+ | Com base nessa rede, devem-se demonstrar: | ||
+ | *Chamadas entre ramais de um mesmo PBX | ||
+ | *Chamadas entre ramais de diferentes PBX (e em ambos sentidos) | ||
+ | *A análise com wireshark de uma chamada com sucesso: mostrar a sequência de mensagens trocadas na sinalização, os codecs negociados, os endereços IP e portas da stream de audio | ||
+ | *A análise com wireshark de uma chamada com falha: | ||
+ | *Realizar uma chamada para um ramal não registrado, e pela análise de mensagens de sinalização no wireshark fazer o diagnóstico da chamada (mostrar que informações do diálogo indicam o status da chamada) | ||
+ | *Realizar uma chamada para um ramal com número inválido, e pela análise de mensagens de sinalização no wireshark fazer o diagnóstico da chamada | ||
+ | *Relatórios de vazão e pacotes para os equipamentos em que se monitoram essas grandezas | ||
+ | *Demonstração de alertas para equipamentos e sistemas monitorados | ||
+ | |||
+ | |||
+ | '''Prazo para conclusão e apresentação:''' ''19/12'' | ||
+ | |||
+ | {{collapse bottom | Aula 35}} | ||
+ | |||
+ | = 18/12: Etapa 3: Avaliação final = | ||
+ | |||
+ | {{collapse top | Aula 36}} | ||
+ | {{collapse bottom | Aula 36}} |
Edição atual tal como às 14h55min de 15 de junho de 2018
Endereço encurtado: http://bit.ly/pji4-20172
Projeto Integrador IV
Professores: Marcelo Maia Sobral ( Facebook) e Ederson Luiz de Souza Santos (ederson.luiz@ifsc.edu.br)
Encontros: 3a feira/19:00, 6a feira/19:00
Atendimento paralelo: 3a e 6a feira 18:30 h
Coordenadoria pedagógica (Graciane): graciane@ifsc.edu.br (3381-2890, 3381-2842)
Objetivo Geral
- Implantar um PABX IP integrado com serviços de telefonia fixa e móvel convencionais.
- Prover a infraestrutura de rede necessária para o adequado funcionamento deste PABX IP.
- Integrar os serviços de telefonia com outros serviços de rede.
Links interessantes
- VoIP Hacking Techniques
- Asterisk não é um SIP proxy
- FoneRNP
- SwitchVox: PBX virtual
- Net Fone da Embratel é VoIP, mas não usa SIP]
- Estatísticas sobre VoIP no mundo
- Sinalização R2 (E1)
Provedores VoIP no Brasil
Avaliações
Aluno(a) | Avaliação 1 | Avaliação 2 | Avaliação 3 | Avaliação 4 | Nota final |
---|
Resumo de comandos da CLI para o Asterisk
- O Asterisk pode ser carregado de duas formas:
- foreground: utilizado para depurar problemas na inicialização do Asterisk, quando ele não puder ser inicializado.
- background: modo padrão de inicialização
- Conectar à CLI do Asterisk carregado
asterisk -r rasterisk
- Comandos na CLI
- Saindo da CLI sem interromper o processo
exit
- Carrega canais SIP previamente registrados
sip reload
- Mostra canais SIP registrados
sip show peers
- Carrega plano de discagem
dialplan reload
- Mostra a extensão criada no plano de discagem
dialplan show default
- Finalizando processo no Asterisk
sudo core stop now
- Ver aplicações disponíveis no Asterisk
core show applications
- Saindo da CLI sem interromper o processo
- Iniciando Asterisk em modo Background
sudo service asterisk start
- Carregar o Asterisk em modo ForeGround
sudo asterisk -gc
28/07: Apresentação da disciplina
Aula 1 |
---|
PBX IPUm 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.
PBX IP Asterisk
Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais
Plano de discagemO 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:
[default]; o nome deste contexto ... default é o contexto predefinido do Asterisk
# 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
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
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
Canais SIPCada 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=maria ; 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
insecure=port,invite ;
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=joao ; 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
insecure=port,invite ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (templates): ; Perfil alunos
[alunos](!); a sequência "(!)" define isto como um perfil
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
defaultuser=maria ; o nome do usuário para fins de autenticação
secret=kabrum
; Canal joao
[joao](alunos)
defaultuser=joao ; o nome do usuário para fins de autenticação
secret=blabla
Experimento: comunicação entre telefones IP ou softphones por meio de um PBX IP
2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa). 3. Configure os softphones de forma que se registrem no PBX Asterisk, usando as contas SIP criadas previamente. 5. A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone de destino 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. 6. Execute o comando rasterisk -vvv no computador do Asterisk. 7. Usando o comando sip show peers, visualize os estados dos canais SIP conhecidos pelo Asterisk. 8. Refaça uma chamada entre os softphones, e observe o que aparece na tela do rasterisk. 9. Será possível verificar que chamadas estão em andamento no Asterisk usando o rasterisk ? Pesquise como se pode fazer isso. 10. Use o rasterisk para testar chamadas. Use o comando console dial canal_SIP para chamar um canal SIP (substitua canal_SIP pelo número a ser chamado). Ao final, execute console hangup. 11. Acrescente mais um canal SIP, editando o arquivo sip.conf. Configure um dos softphones para usar esse novo canal. 12. Teste chamadas entre os softphones usando esse novo número. Possíveis problemas
DICASComandos válidos no CLI do Asterisk:
|
02/08: Interligação de PBX Asterisk
Aula 2 | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Supondo que cada cliente do provedor tenha seu próprio PBX, pode ser necessário interligar suas centrais com o PBX do provedor. 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.
Tronco SIPEm 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 (mais detalhes sobre esses protocolos serão vistos em aulas posteriores). A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
Atividade: estabelecendo chamadas entre diferentes PBX AsteriskNesta 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:
Padrões de extensõesExtensõ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:
VariáveisO 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.
Existem três tipos de variáveis:
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 especiaisAlém das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
|
11/08: Projeto 1: continuação sobre entroncamento
Aula 3 |
---|
15/08: Projeto 1: Planejamento da Portaria Eletrônica
Aula 4 |
---|
|
18/08: Projeto 1: Funções de PABX
Aula 5 |
---|
Funções usando o plano de discagemPara 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çõesAs 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. DialEncaminha a chamada para um destino. Exemplo: exten=>_1XXXX,1,Dial(SIP/${EXTEN})
same=>n,hangup
BackgroundToca 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
PlaybackToca 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
WaitForç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 HangupAnswer atende uma chamada. Hangup termina uma chamada. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
GoToPula para um contexto (opcional), extensão, prioridade específica. Exemplo: exten=>100,1,GoTo(vendas,s,1)
GoToIfTrata-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
SetModifica 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
LogGrava 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
NoOpNão faz nada, sendo útil para depurar o plano de discagem. Exemplo: exten=>100,1,NoOp(${CONTEXT})
Atividades
|
22/08: Projeto 1: Funções de PABX (continuação)
Aula 6 |
---|
25/08: Projeto 1: Funções de PABX (continuação)
Aula 7 |
---|
29/08: Projeto 1: Funções de PBX: URA e correio de voz
Aula 8 |
---|
Hoje serão vistas duas funcionalidades de uma central que podem ser aplicadas à portaria eletrônica:
URAO que é uma URA (Unidade de Resposta Audível) ? Clique na imagem abaixo ... 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 => 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
Correio de voz
|
01/09: Outras funções de PBX
- Revisar o planejamento do projeto: muita coisa foi vista desde a escrita do plano de trabalho. A luz da sua compreensão atual sobre o que se consegue fazer com um PBX Asterisk, revise o seu plano.
Aula 9 |
---|
Após experimentar a implantação de um correio de voz e uma URA, podem-se conhecer outras possíveis funções de PBX existentes no Asterisk, tais como:
Essas funções podem ser úteis na infraestrutura de telefonia a ser implantada na primeira etapa do projeto. Como exemplo, algumas delas são apresentadas a seguir. Música de esperaO Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo mpg123. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte. A partir da versão 1.2 do Asterisk se sugere não mais usar o mpg123. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, wav ou pcm (μLaw). A ferramenta ffmpeg pode ser usada para converter arquivos MP3 para WAV ou PCM. # convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
musica.pcm -map 0:0 -map 0:0
Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo musiconhold.conf: # configuracao no arquivo musiconhold.conf
[alunos]
mode=files
directory=/var/lib/asterisk/moh
sort=random
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima
Para testar a música em espera no plano de discagem, pode-se usar a aplicação MusicOnHold: exten=>667,1,Set(CHANNEL(musicclass)=alunos)
same=>n,Answer
same=>n,MusicOnHold()
same=>n,Dial(SIP/667)
same=>n,Hangup
Filas de atendimentoAmplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo queues.conf: [fila-suporte]
musicclass=default
strategy=ringall; roundrobin, rrmemory
timeout=10
wrapuptime=30
periodic-announce = em-breve
periodic-announce-frequency=60
member=>SIP/6111
member=>SIP/6112
No plano de discagem a fila de atendimento pode ser usada da seguinte forma: [suporte]
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
exten=> s,2,Playback(bem-vindo)
exten=> s,3,Queue(fila-suporte)
Captura de chamadasA captura possibilita que se puxe uma chamada de um colega no mesmo grupo de chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo features.conf).
Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro callgroup), e de que grupos se pode capturar chamadas (parâmetro pickupgroup). No caso de canais SIP isso fica em sip.conf: [joaozinho]
callgroup=1
pickupgroup=1,2
...
Estacionamento de chamadasO estacionamento de chamadas é feito no arquivo features.conf fazendo uso dos seguintes parâmetros:
Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas: [vendas]
include=>parkedcalls
exten=>6200,1,Dial(SIP/6200,30,tT)
exten=>6200,n,Hangup
Atividades
|
05/09: Projeto 1: outras funções de PBX
Aula 10 |
---|
12/09: Projeto 1: Implantação do protótipo do porteiro IP
Aula 11 |
---|
Nesta primeira etapa da disciplina, introduziu-se um PBX IP e suas funções. Esse estudo não foi exaustivo, pelo contrário. Houve a preocupação de realizar um primeiro contato com a tecnologia, principalmente quanto à lógica envolvida em sua utilização. Essa investigação preliminar foi fundamental para se criar uma base de conhecimento necessária à realização do projeto do Porteiro IP. Uma possível estrutura para o sistema do Porteiro IP está ilutsrada a seguir. Nessa figura se podem ver a central que comandas as funções do porteiro, o painel com teclado, microfone e falante, combinado a uma fechadura elétrica para portão, para uso de pessoas que desejam entrar no condomínio, e os interfones e telefones celulares dos moradores.
|
15/09: Projeto 1: Implantação do protótipo
Aula 12 |
---|
19/09: Projeto 1: Implantação e conclusão do protótipo
Aula 13 |
---|
O programa que envia a mensagem contendo o comando de abertura do portão deve ser executado no PBX quando um morador pressionar uma tecla específica em seu interfone. Somente quando uma chamada entre interfone e painel do portão estiver em andamento esse programa pode ser executado. Para que isso funcione, o PBX deve ser capaz de interpretar uma notificação de dígito pressionado vinda do interfone. O Asterisk é capaz desse tipo de ação por meio de features, as quais estão configuradas no arquivo features.conf. Uma feature associa uma sequência de um ou mais dígitos a uma ação a ser executada no PBX. Algumas features são predefinidas, tais como transferência e captura de chamada. Novas features podem ser definidas na seção applicationmap do arquivo features.conf. Uma nova feature associa uma sequência de dígitos a uma aplicação típica de plano de discagem. Para maiores informações, abra esse arquio e leia a explicação contida na seção applicationmap. Dica: a execução de um programa no PBX pode ser feita com a aplicação System. O exemplo a seguir mostra a definição de uma nova feature chamada chaveia. Essa feature associa a tecla 0 (zero) à aplicação Playback(tt-monkeys): chaveia => 0,self,Playback,tt-monkeys A definição de uma feature segue então o formato: nome_da_feature => sequência,canal,aplicação,argumentos da aplicação Sendo que:
Além disso, para que uma feature esteja disponível em uma chamada, a variável de canal DYNAMIC_FEATURES deve estar definida. Por exemplo: [default]
exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN})
same=>n,Set(DYNAMIC_FEATURES=chaveia)
same=>n,Dial(SIP/${EXTEN},30)
same=>n,hangup()
O exemplo acima possibilita que o canal originador da chamada ative a feature chaveia. Porém no caso do porteiro VoIP não é isso que se deve fazer. As chamadas se originam do painel para algum morador, e por isso não pode ser o canal originador quem abre o portão. Se assim fosse, o próprio painel liberaria o portão ! A solução é liberar a execução da feature somente no canal chamado (interfone). O Asterisk não tem um jeito direto de fazer isso, então é necessário o pequeno truque mostrado a seguir: [macaquinhos]
exten=>s,1,noop(ativa feature para tocar macaquinhos)
same=>n,Set(DYNAMIC_FEATURES=chaveia)
same=>n,Return
[default]
exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN})
same=>n,Dial(SIP/${EXTEN},30,U(macaquinhos))
same=>n,hangup()
No exemplo acima, usa-se o conceito de subrotina para ativar a feature no canal chamado. A opção U(macaquinhos) da aplicação Dial faz com que a subrotina macaquinhos seja executada no canal chamado quando atender a chamada. Uma subrotina se assemelha a um contexto que possui somente a extensão s. A chamada é processada nessa extensão até que apareça a aplicação Return, que termina a subrotina. Com isso consegue-se ativar a feature somente no interfone. |
22/09: Projeto 1: O protocolo SIP
Aula 14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
O protocolo SIPO 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 SIPO 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):
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.
Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)
Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)
Tabela com as classes de respostas AtividadesNas análises pedidas a seguir, faça o seguinte:
Usando o wireshark faça o seguinte:
Diagramas de chamadasAlguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. Registro de agente SIP em um proxy SIPEsta 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 SIPUma 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 SIPA 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 mediaEste 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-INVITEO 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 |<---------------|
|<---------------| |
| | |
AtividadesNas análises pedidas a seguir, faça o seguinte:
|
26/09: O protocolo SDP e o transporte de midia
Aula 15 | ||||
---|---|---|---|---|
SDP (Session Description Protocol)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:
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:
Atividade
O transporte de midia com protocolo RTP
RTCPAlé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:
Os cinco tipos de relatórios são:
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. AtividadeEssa atividade busca ilustrar os fluxos RTP com um exemplo:
Correção para o wiresharkO 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. |
03/10: Investigando os protocolos envolvidos nas chamadas
Aula 16 |
---|
Sinalização com SIPAs chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos:
Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso. Chamada entre dois agentes SIP com intermediação de um gateway de mediaEste 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-INVITEO uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. Fone 1 PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| INVITE |--------------->|
|<---------------| INVITE |
| 200 OK |--------------->|
|--------------->| 200 OK |
| ACK |<---------------|
|--------------->| ACK |
| |<---------------|
| |
| RTP Media |
|<===============================>|
| BYE | |
|--------------->| BYE |
| |--------------->|
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| | |
Atividade
|
06/10: VoIP e NAT
Aula 17 |
---|
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:
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
Solução utilizando o AsteriskO 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
Solução utilizando o Asterisk
Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte:
|
10/10: Qualidade da comunicação
Aula 18 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Componentes do atraso fim-a-fimO 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.
O menor atraso pode ser calculado assim:
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é . 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. Atividade
3. Devem ser realizadas chamadas entre softphones, dando atenção à qualidade do áudio. OBS: nos PBX devem-se capturar os pacotes das chamadas para posterior análise. 4. Após realizar as chamadas, devem-se analisar suas respectivas capturas. A análise deve se concentrar em informações que forneçam uma medida de qualidade de serviço. Dica: vejam o menu Telephony->RTP. 5. Os passos 3 e 4 devem ser repetidos conforme orientação dos professores. Os casos a serem analisados envolvem:
OBS: em todos os casos, a conversa esteve compreensível. Mesmo quando ruim, era possível entender a maior parte da conversa. |
17/10: Conexão com a PSTN e PABX legado
Aula 19 |
---|
Além de interligar a portaria aos interfones e softphones dos moradores, o porteiro VoIP pode se integrar a uma rede telefônica privativa preexistente. Por exemplo, o porteiro VoIP pode ser instalado em uma empresa que possui uma rede telefônica própria, formada por ramais e troncos para a rede telefônica pública. Nesse caso, os ramais da empresa teriam papel similar aos interfones. Para que o porteiro VoIP possa ser usado nesses cenários, ele deve ser capaz de se integrar a redes telefônicas convencionais. Integração de Asterisk a redes telefônicas convencionais ou móveisA rede pública de telefonia comutada (do inglês Public switched telephone network ou PSTN) é o termo usado para identificar a rede telefônica mundial comutada por circuitos destinada ao serviço telefônico. A PSTN é administrada pelas operadoras de serviço telefônico e inicialmente foi projetada como uma rede de linhas fixas e analógicas, porém atualmente é digital. Interligada a ela existe também a Rede Móvel, que inclui dispositivos móveis como os telefones celulares. Através dessas redes podem ser realizadas chamadas locais (chamada realizada na mesma cidade/região), longa distância (chamada realizada para outra cidade/região) ou internacionais (chamada realizada para outros países). Além da PSTN, existem também as Centrais Privadas de Comutação Telefônica (PABX ou, simplesmente, PBX). Redes telefônicas formadas por PABXs operam de forma similiar a PSTN, porém são restritas ao ambiente de uma empresa ou organização. Os PABXs tem a função de interligar os telefones dos usuários da empresa (ramais) e também conectar-se a Central Pública (PSTN) através de uma ou mais linhas telefônicas (linhas tronco). Ambos, PSTN e PABX convencional, operam de forma similar e fazem uso de comutação de circuitos. Mais recentemente, surgiu o conceito de PBX IP que funciona como uma central telefônica convencional (PABX), 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. O PBX IP, diferentemente da PSTN e do PABX convencional, não utiliza a comutação de circuitos, mas sim opera sobre a rede de dados utilizando comutação de pacotes. O Asterisk é uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada. Para funcionar puramente como um PABX IP, o Asterisk não necessita de nenhum item adicional. Basta tão somente instalá-lo em um computador e fazer as devidas configurações. Porém, se é desejado que o Asterisk se comunique com a PSTN ou com PABX convencional, são necessários placas ou gateways que façam a interface com o mundo da telefonia baseada em comutação de circuitos. Abaixo seguem como exemplo algumas placas que podem ser adicionas à máquina onde foi instalado o Asterisk:
Refazendo o Asterisk para conectá-lo com a PSTN
Instalando o Channel Driver da Khomp
Fazendo chamadas através de canais Khomp
exten=>9,1,Dial(Khomp/bXcY)
same=>n,hangup
AtividadesUma vez adicionado o módulo Khomp e este estando com status UP, pode-se fazer as configurações para que as chamadas sejam roteadas através dele.
|
20/10: Conexão com a PSTN e PABX legado (continuação)
Aula 20 |
---|
24/10: Conexão com a PSTN e PABX legado (continuação)
Aula 21 |
---|
27/10: Conexão com a PSTN e PABX legado (continuação)
Aula 22 |
---|
31/10: Etapa 2: conclusão
Aula 23 |
---|
A conclusão da etapa 2 envolve estender o porteiro VoIP para que ele se integre com uma rede telefônica privativa existente no condomínio ou empresa. Essa rede telefônica se compõe dos ramais de empresa ou dos interfones do condomínio. O porteiro VoIP deve ser capaz de explorar essa rede telefônica. Na versão do porteiro realizada na etapa 1, era possível contatar um morador por meio de seu celular. Nesse caso, a chamada era feito com VoIP. Na etapa 2, o porteiro deve ser capaz de tentar contatar números telefônicos externos, caso nenhum ranal SIP tenha sido configurado para aquele contato, ou se o ramal SIP configurado estiver indisponível. Assim incrementam-se as possibilidades de comunicação entre o sistema do porteiro VoIP e os condôminos ou funcionários de empresas. A rede telefônica existente se compõe de um PBX, ramais analógicos e troncos analógicos, digitais (E1) ou móveis (GSM) com uma operadora. Assim, a central do porteiro VoIP deve se integrar com esse PBX por meio de alguma tecnologia dentre aquelas estudadas.
|
7/11: Etapa 2: conclusão
Aula 24 |
---|
10/11: Etapa 2: conclusão
Aula 25 |
---|
14/11: Etapa 2: conclusão
Aula 26 |
---|
17/11: Etapa 3: integração com serviços de rede
Aula 27 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Existem serviços de rede essenciais para o provedor, e que devem ser integrados à infraestrutura existente. São eles:
Na aula de hoje será feita uma revisão sobre DNS, e em seguida sua implantação para o provedor.
O provedor deve ter seu domínio DNS, mas os clientes não possuem domínios próprios. No entanto, cada cliente possui uma identificação única no domínio do provedor, o que é útil para identificá-los nas URI SIP. Integração com o DNS1. No arquivo /etc/bind/named.conf.local será criado o domínio nome-provedor.com.br e seu reverso: ... zone "nome-provedor.com.br" { type master; file "/etc/bind/nome-provedor.com.br"; }; zone "10.in-addr.arpa" { type master; file "/etc/bind/10.in-addr.arpa"; };
$TTL 86400 @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( 2010033101 ; serial 1d ; refresh 1h ; retry 1w ; expire 1d ; negative cache ttl ) @ IN NS ns1 ns1 IN A IP-maquina-ns1 www IN CNAME ns1 servidor IN CNAME ns1
3. Configuração do DNS reverso, arquivo /etc/bind/10.in-addr.arpa: $TTL 86400 @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( 2010033101 ; serial 1d ; refresh 1h ; retry 1w ; expire 1d ; negative cache ttl ) @ IN NS ns1.nome-provedor.com.br. 1.0.0 IN PTR ns1 4. Utilitário para testar o arquivo que contém o conteúdo de uma zona: named-checkzone nome_do_dominio arquivo_da_zona ==> Aponta possíveis erros no arquivo de configuração.
|
21/11: Etapa 2: atividades da avaliação
Aula 28 |
---|
24/11: Etapa 2: atividades de avaliação
Aula 29 |
---|
28/11: Etapa 3: Integração com serviços de rede: WWW
Aula 30 |
---|
Uma empresa pode implantar outros serviços úteis tanto para os clientes quanto para suas equipes de suporte e gerência. Um dos serviços mais difundidos e utilizados é WWW, em que documentos, recursos genéricos ou mesmo aplicações são disponibilizados segundo um modelo cliente-servidor. Exemplos de uso desse serviço são:
Hoje será feita uma revisão sobre o serviço WWW. Em seguida, algumas aplicações para esse serviço na rede do porteiro serão identificadas.
WWW e protocolo HTTPWWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. Mensagens de pedido HTTPMensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo
Cabeçalho1: valor do cabeçalho1
Cabeçalho2: valor do cabeçalho2
Cabeçalho3: valor do cabeçalho3
CabeçalhoN: valor do cabeçalhoN
corpo da mensagem
A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são:
O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1
Host: wiki.sj.ifsc.edu.br
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4
Connection: keep-alive
If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT
Mensagens de resposta HTTPMensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info
Cabeçalho1: valor do cabeçalho1
Cabeçalho2: valor do cabeçalho2
Cabeçalho3: valor do cabeçalho3
CabeçalhoN: valor do cabeçalhoN
corpo da mensagem
A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são:
Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK
Date: Thu, 23 May 2013 20:43:31 GMT
Server: Apache
Last-Modified: Fri, 10 May 2013 14:09:58 GMT
ETag: "757236-40-4dc5db8df272a"
Accept-Ranges: bytes
Content-Length: 64
Vary: Accept-Encoding
Connection: close
Content-Type: text/plain; charset=UTF-8
Este é um pequeno arquivo de teste, sem informação útil ...
Captura de página somente HTML Captura de página HTML com uma figura Captura de página HTML com duas figuras
ApacheVer capítulo 26 da apostila. O servidor Apache (Apache server) é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (National Center for Supercomputing Applications), Universidade de Illinois. Ele descende diretamente do NCSA httpd, um servidor web criado e mantido por essa organização. Seu nome vem justamente do reaproveitamento do NCSA httpd (e do fator de tê-lo tornado modular) fazendo um trocadilho com a expressão "a patchy httpd (um httpd remendável). Para ter ideia de sua popularidade, em maio de 2010, o Apache serviu aproximadamente 54,68% de todos os sites e mais de 66% dos milhões de sites mais movimentados. O servidor é compatível com o protocolo HTTP versão 1.1. Suas funcionalidades são mantidas através de uma estrutura de módulos, podendo inclusive o usuário escrever seus próprios módulos — utilizando a API do software. É disponibilizado em versões para os sistemas Windows, Novell Netware, OS/2 e diversos outros do padrão POSIX (Unix, GNU/Linux, FreeBSD, etc). Um servidor web é capaz de atender requisições para transferência de documentos. Essas requisições são feitas com o protocolo HTTP (HyperText Transfer Protocol), e se referem a documentos que podem ser de diferentes tipos. Uma requisição HTTP simples é mostrada abaixo: GET / HTTP/1.1 Host: www.ifsc.edu.br
Para o servidor Web, os principais componentes de uma requisição HTTP são o método HTTP a executar e o localizador do documento a ser retornado (chamado de URI - Uniform Resource Indicator). No exemplo acima, a requisição pede o método GET aplicado à URI /. O resultado é composto do status do atendimento, cabeçalhos informativos e o conteúdo da resposta. No exemplo, o status é a primeira linha (HTTP/1.1 200 OK), com os cabeçalhos logo a seguir. Os cabeçalhos terminam ao aparecer uma linha em branco, e em seguida vem o conteúdo (ou corpo) da resposta. Todo documento possui um especificador de tipo de conteúdo, chamado de Internet media Type. O cabeçalho de resposta Content-type indica o media type, para que o cliente HTTP (usualmente um navegador web) saiba como processá-lo. No exemplo acima, o documento retornado é do tipo text/html, o que indica ser um texto HTML. Outros possíveis media types são: text/plain (texto simples), application/pdf (um texto PDF), application/x-gzip (um conteúdo compactado com gzip). Um documento no contexto do servidor web é qualquer conteúdo que pode ser retornado como resposta a uma requisição HTTP. No caso mais simples, um documento corresponde a um arquivo em disco, mas também podem ser gerados dinamicamente. Existem diversas tecnologias para gerar documentos, tais como PHP, JSP, ASP, CGI, Python, Perl, Ruby, e possivelmente outras. Todas se caracterizam por uma linguagem de programação integrada intimamente ao servidor web, obtendo dele informação sobre como gerar o conteúdo da resposta. Atualmente, boa parte dos documentos que compõem um site web são gerados dinamicamente, sendo PHP, JSP e ASP as tecnologias mais usadas. Informações gerais sobre Apache no Ubuntu
Uma configuração básicaO servidor Apache precisa de algumas informações básicas para poder ativar um site:
Neste caso, para distinguir uma página Web da outra é utilizado um endereço de IP ou portas diferentes para cada um. Em caso de um servidor que possua mais de um endereço IP configurado, é possível associar cada Virtual Host a um destes IPs. Já se o servidor possui apenas um endereço IP, é possível distinguir cada Virtual Host por um número diferente de porta.
# O nome de servidor
ServerName www.prj.edu.br
# As portas onde se atendem requisições HTTP
Listen 8080
# Onde estão os documentos desse site
DocumentRoot /var/www/html/prj
# As restrições de acesso aos documentos
<Directory /var/www/html/prj>
Options Indexes
DirectoryIndex index.html index.php
order allow,deny
allow from all
</Directory>
Neste caso, para distinguir uma página Web da outra é verificado o parâmetro ServerName declarado dentro do arquivo de configuração de cada página Web.
<VirtualHost *:80>
# Onde estão os documentos desse site
DocumentRoot /var/www/html/prj2
# O nome de servidor
ServerName www.redes2.edu.br
# As restrições de acesso aos documentos
<Directory /var/www/html/prj2>
Options Indexes
DirectoryIndex index.html index.php
order allow,deny
allow from all
</Directory>
</VirtualHost>
AtividadeNa atividade abaixo, defina um servidor WWW chamado www.<seu_domínio>.br, que atende requisições no port 8080.
Obs.: Para criar páginas HTML um pouco mais completas você pode ler o tutorial disponível aqui Configuração no Servidor da equipe
|
01/12: Etapa 3: monitoramento da rede do porteiro
Aula 31 |
---|
O monitoramento da rede e dos serviços é essencial para garantir a disponibilidade do porteiro. Quando problemas ocorrem, tais como quedas de links ou de servidores, a equipe técnica deve ser notificada o mais rápido possível para que possa repará-los. Devido à complexidade da estrutura do porteiro, são necessárias ferramentas para auxiliar em seu monitoramento. NMS (Network Management System) é um sistema (incluindo hardware e software) onde se executam softwares para gerenciar uma rede de computadores. Um termo parecido para NMS é Network Monitoring System, que se trata de um tipo específico de software para monitorar elementos de rede e seus serviços (ex: HTTP, SMTP, LDAP, DNS).
Existem muitos sistemas de monitoramento de rede, uma vez que o acompanhamento eficiente da saúde da rede é uma tarefa fundamental da gerência. Em uma grande rede, composta de muitos servidores, equipamentos de rede e diversos serviços, a equipe responsável precisa de ferramentas de auxílio ao acompanhamento de seu bom funcionamento. Essas ferramentas devem idealmente não somente mostrar se os componentes da rede estão funcionando como esperado, mas também alertar os responsáveis quando identificar algo errado. Além disso, como existe dependência tanto entre serviços de rede quanto entre equipamentos (e entre ambos), essas ferramentas devem senão apontar a causa raiz dos problemas, ao menos localizar os prováveis candidatos. Finalmente, é desejável que esses sistemas identifiquem e mostrem tendências de eventos na rede, a partir do histórico de funcionamento de seus componentes. São portanto muitos requisitos para os NMS, os quais não são totalmente atendidos por todos os softwares existentes. Alguns NMS interessantes: Monitoramento com CactiCacti é um coletor de dados e gerador automático de gráficos para fins de monitoramento e histórico de desempenho. Os dados devem ser numéricos, para possibilitar a geração de gráficos. Uma interface web possibilita a administração e visualização dos gráficos, como se pode ver abaixo:
Muitos exemplos e tipos de dispositivos ou fontes de dados estão predefinidos no Cacti. Por exemplo, existem todas as definições para obter estatísticas de interfaces de rede usando SNMP. Como o cacti é muito flexível, podem-se criar novos tipos de fontes de dados, bastando definir como os dados devem ser coletados. Mas afinal o que é SNMP ??? Basicamente, SNMP é um protocolo de gerenciamento de redes que possibilita, dentre outras coisas, obter informações sobre elementos de rede. Porém primeiro será instalado o Cacti, e depois isso será investigado com maiores detalhes ... Instalando o cactiNo Ubuntu a instalação se mostra muito simplificada, pois o sistema de pacotes já configura todos os detalhes do cacti após a instalação. Se for instalado a partir do código fonte serão necessárias a configuração do banco de dados MySQL (para guardar informações administrativas. como definições de dispositivos, fontes de dados e gráficos) e a instalação de algumas extensões PHP.
Atividades
|
05/12: Etapa 3: monitoramento de eventos e geração de alertas na rede
Aula 32 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cacti é útil para registrar a atividade e acompanhar o uso de recursos na rede, porém não para identificar automaticamente situações que requeiram atenção da equipe técnica. O monitoramente de recursos para geração de alertas pode ser realização por outras ferramentas de gerenciamento, tais como Nagios. Basicamente, o Nagios é uma plataforma configurável de monitoramento de serviços e equipamentos de rede, capaz de emitir alertas e de efetuar ações de recuperação de falhas. Cada serviço ou tipo de equipamento pode ser monitorado com um plugin especializado, que assim efetua testes de disponibilidade sob medida. Por exemplo, um plugin de monitoramento do serviço HTTP (Web) pode tentar buscar uma ou mais páginas, e analisar tanto o status da resposta do servidor quanto o tempo que levou para obtê-la. A dependência entre os serviços pode ser configurada, de forma que ao se detectarem falhas por diferentes plugins, o Nagios possa apontar a causa raiz do problema. O ponto de partida do Nagios é a descrição da rede e de todos os serviços a serem monitorados. Cada monitoramento de serviço ou equipamento precisa ser parametrizado (por exemplo, quais os atrasos de resposta aceitáveis para o roteador de um link), para que se possam identificar as situações anômalas. Essas informações residem na configuração do Nagios, e precisam ser criadas manualmente. OBS: existem outros sistemas de monitoramento e alerta, tais como Zabbix e PandoraFMS. Algumas comparações entre esses sistemas podem ser encontradas, tais como:
Instalação
Exemplos de configuraçõesA configuração do Nagios fica no diretório /etc/nagios3. Todos os arquivos mencionados abaixo se referem a esse diretório, salvo se for indicado o contrário. O arquivo de configuração principal se chama nagios.cfg, que contém opções globais e inclusões de outros arquivos com configurações específicas. Em particular, arquivos que tratam de objetos monitorados e informacões relacionadas (hosts, serviços, comandos e templates). ficam dentro do subdiretório objects. Definições de hostsPara configurar o Nagios, devem-se primeiro criar definições de hosts (equipamentos monitorados). Esas definições ficam em algum arquivo dentro do subdiretório conf.d, o qual deve estar incluído em nagios.cfg (veja o exemplo contido em localhost_nagios2.cfg). Cada host definido é automaticamente monitorado com PING, de forma a verificar se está no ar. Um host é declarado como a seguir: define host{
use generic-host ; Nome do template de host a ser usado
; Este host irá herdar toas a variáveis que estão definidas
; no template linux-server (ou que foram herdadas por ele).
host_name gateway ; nome do host na rede
alias Gateway do Lab. ; Descrição do host
address 192.168.2.1
parents localhost ; qual o próximo host em direção ao Nagios
}
O uso de templates simplifica a definição de hosts, pois evita a repetição de muitas opções comuns (veja como seria a definição completa de um host). Os templates estão nos arquivos generic-host_nagios2.cfg e generic-service_nagios2.cfg. A opção parents tem grande importância para possibilitar que o Nagios faça a distinção entre hosts ou serviços falhos ou inalcançáveis. O primeiro caso trata de serviços cujos testes programados falharam, e o segundo caso são aqueles que não podem ser testados, porque dependem de um host intermediário (um gateway) que falhou. Assim pode-se evitar a emissão de alertas para todos os serviços, concentrando-os na causa raiz do problema. Definições de serviçosEm cada host devem ser criadas definições de serviços a serem monitorados. Cada serviço possui um comando de verificação específico, para que o teste seja mais fidedigno. Duas definições de serviços são mostradas abaixo (para IMAP e DNS): define service{
use generic-service ; Nome do template de serviço a ser usado
host_name localhost ; Host onde reside o serviço
service_description IMAP
check_command check_imap ; Comando para verificar o serviço
notifications_enabled 0 ; Notificações desabilitadas
}
define service{
use generic-service
host_name localhost
service_description DNS
check_command check_dns
notifications_enabled 0
}
Assim como no caso de hosts, usam-se templates para evitar a repetição de opções de uso comum (ver definição completa de um serviço). Definições de comandos
msobral@ger:~$ cd /usr/lib/nagios/plugins
msobral@ger:/usr/lib/nagios/plugins$ ./check_dns -h
check_dns v1.5 (nagios-plugins 1.5)
Copyright (c) 1999 Ethan Galstad <nagios@nagios.org>
Copyright (c) 2000-2008 Nagios Plugin Development Team
<nagiosplug-devel@lists.sourceforge.net>
Esse complemento utiliza o programa nslookup para obter o endereço IP do host/domínio consultado.
Um servidor DNS opcional pode ser especificado.
Se um servidor DNS não é especificado, o(s) servidor(es) padrão(es) no arquivo /ect/resolv.conf serão utilizados.
Uso:
check_dns -H host [-s server] [-a expected-address] [-A] [-t timeout] [-w warn] [-c crit]
Opções:
-h, --help
Imprime uma tela de ajuda detalhada
-V, --version
Imprime informação da versão
--extra-opts=[seção][@arquivo]
Ler opções de um arquivo ini. Veja http://nagiosplugins.org/extra-opts
para exemplos de utilização.
-H, --hostname=HOST
O nome ou endereço que você deseja consultar
-s, --server=HOST
Servidor DNS opcional que você que utilizar para fazer consultas
-a, --expected-address=IP-ADDRESS|HOST
ENDEREÇO-IP opcional que você espera o servidor DNS retornar. SERVIDOR deve acabar com
um ponto (.). Essa opção pode ser repetida várias vezes (Retorna OK se qualquer
corresponde ao valor). Se vários endereços são retornados de uma vez, você tem que combinar
a cadeia completa de endereços separados por vírgulas (ordenados alfabeticamente)
-A, --expect-authority
Opcionalmente a espera pelo servidor DNS deve ser autorizada para a pesquisa
-w, --warning=seconds
Retorna um aviso se o tempo decorrido exceder o valor. Padrão off
-c, --critical=seconds
Retorno crítico se o tempo decorrido exceder o valor. Padrão off
-t, --timeout=INTEIRO
Segundos antes da conexão expirar (padrão: 10)
Enviar e-mail para nagios-users@lists.sourceforge.net se você tiver dúvidas
quanto ao uso deste software. Para enviar correções ou sugerir melhorias,
enviar e-mail para nagiosplug-devel@lists.sourceforge.net
msobral@ger:/usr/lib/nagios/plugins$
Nem todos os plugins acima são adicionados automaticamente à configuração do Nagios na instalação. O arquivo commands.cfg contém os comandos preconfigurados. Assim, caso seja necessário adicionar um plugin que ainda não esteja ali (ex: check_dns), deve-se criar uma definição de comando: define command{
command_name check_dns
command_line $USER1$/check_dns -H www.google.com.br -s $HOSTADDRESS$
}
O importante acima é a definição de como o plugin deve ser executado, incluindo os parâmetros que devem ser passados. Alguns parâmetros são predefinidos pelo Nagios, estando disponíveis em macros:
Para exemplificar como passar parâmetros para os plugins, veja o caso de um teste do tipo PING: define service{
host_name linuxbox
service_description PING
check_command check_ping!200.0,80%!400.0,40%
}
O comando check_ping deve ser chamado com dois argumentos (separados por !): 200.0,80% e 200.0,80%. A definição do comando check_ping, por sua vez, os utiliza da seguinte forma: define command{
command_name check_ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
Ativando as novas configuraçõesSempre que modificar a configuração o Nagios deve ser reiniciado: sudo service nagios3 reload
Caso ocorra um erro, e o nagios não inicie, significa que existe um ou mais erros nos arquivos de configuração. Para encontrá-los execute o nagios com a opção -v, que faz uma verificação desses arquivos: $ cd /etc/nagios3
$ nagios3 -v nagios.cfg
Total Warnings: 3
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
Atividades
|
08/12: Etapa 3: SNMP
Aula 33 |
---|
Desde o lançamento da primeira versão, na década de 80, o SNMP mantém-se como um protocolo simples de gerenciamento e é amplamente utilizado no gerenciamento de sistemas na Internet. Por isso, esse modelo também é denominado de Modelo de Gerenciamento da Internet . O modelo SNMP, e a maior parte dos sistemas de gerenciamento disponíveis, se baseia no modelo Agente/Gerente, que normalmente é formado pelos seguintes elementos:
O protocolo SNMPO protocolo SNMP serve para transmitir as informações das operações de gerência entre gerente e agentes. Ele usa o protocolo UDP, com port padrão 161. Há quatro comandos básicos (SNMPv1) que operam em modo comando-resposta originado no gerente (com exceção de TRAP):
Nomenclatura de objetos na MIBTodos os objetos acessados pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o Gerente e o Agente devem concordar sobre os nomes e significados das operações GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como MIB (do inglês: Management Information Base). O padrão SNMP não define o MIB, mas apenas o formato e o tipo de codificação das mensagens. A especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, são especificados por RFCs próprios. Cada variável em uma MIB se chama objeto da MIB, e é definida usando a linguagem de descrição de dados SMI. Um dispositivo de rede pode ter muitos objetos, que correspondem aos diferentes elementos de hardware e software nele contidos. Para possibilitar que novos objetos de MIB sejam facilmente definidos, grupos de objetos de MIB relacionados estão definidos em RFCs separadas chamados de módulos MIB.
.iso.org.dod.internet.mgmt.mib-2.application
.1.3.6.1.2.1.27.1.1.8.2
system.syslocation.0 ... corresponde na verdade ao OID: .iso.org.dod.internet.mgmt.mib.system.syslocation.0 Software net-snmpO projeto net-snmp provê uma implementação de um agente SNMP e de utilitários para fazer operações sobre MIBs (assim, fornece também a base para a implementação de um gerente). Para instalá-lo deve-se executar: sudo apt install -y snmpd
Esse pacote contém os seguintes programas:
O agente SNMP vem preconfigurado para atender somente requisições vindas de localhost (127.0.0.1). Edite o arquivo /etc/snmp/snmpd.conf, e modifique a variável agentAddress para que ele aceite requisições vindas de outras interfaces. Ela pode ficar desta forma: agentAddress udp:0.0.0.0:161
Atividades
|
11/12: Etapa 3: A rede completa com monitoramento e alertas
Aula 34 |
---|
15/12: Etapa 3: Avaliação final
Aula 35 |
---|
A avaliação final envolve implantar esta rede:
Nessa rede, deve-se fazer o seguinte:
|
18/12: Etapa 3: Avaliação final
Aula 36 |
---|