Mudanças entre as edições de "Gerência de Redes (diário 2012-1)" - MediaWiki do Campus São José
Mudanças entre as edições de "Gerência de Redes (diário 2012-1)"
Edição das 09h58min de 22 de maio de 2012 (ver código-fonte)
(→‎Bruna Amante, Patrícia Domingos)
Edição atual tal como às 19h33min de 5 de novembro de 2016 (ver código-fonte)
Etorresini (discussão | contribs)
O formato da apostila é [http://idpf.org/epub EPUB], publicado semanalmente no '''[http://tele.sj.ifsc.edu.br/~etorresini/ger20121/ repositório do professor]'''. Ele está em produção usando o aplicativo [http://code.google.com/p/sigil/ Sigil].
O formato da apostila é [http://idpf.org/epub EPUB], que fora publicado semanalmente até a metade da disciplina. Ele foi produzido usando o aplicativo [http://code.google.com/p/sigil/ Sigil].
Há diversos dispositivos para leitura desse formato. No Linux, o aplicativo <tt>calibre</tt> (para Ubuntu está disponível pelo seu [http://packages.ubuntu.com/search?keywords=calibre&searchon=names&section=all repositório oficial]) lê e converte para esse formato.
** [[Gerência de Redes (diário 2012-1) - prova 4|Setembro]]
** No máximo 1 C e nenhum D: B;
** No máximo 1 D: C;
** Demais casos: D.
** Demais casos: D[https://docs.google.com/spreadsheet/ccc?key=0AvKQkavuEKVtdDRTaTJ0bFBZb2lVLWFqSkJ3VEw2a1E .]
=Ambiente de Trabalho=
* Repositório Git do projeto no [https://github.com/thiagoifsc/gerencia-de-redes github]
=== Anderson Rosa, Barbara Sodré e Ricardo Martins ===
=== Anderson Rosa e Ricardo Martins ===
*[[Media:cenario_ger.rar |cenario_ger.rar ]]
*[[Media:cenario_ger.rar |cenario_ger.rar (desatualizado) ]]
*[https://github.com/Androsa/GERproject Repositório do GitHub]<br>
=== Bruna Amante ===
*[https://github.com/brunamante/GerenciaRedes Lab.conf]
*[https://github.com/brunamante/GerenciaRedes Repositório no GitHub]
=== Helton Luiz Porto, Emerson Gomes, Fernando ===
== LAMP==
# Servidor DMZ 0: bora-bora
#* IP: 192.168.3.1
#* Serviço: MySQL
# Servidor DMZ 1: tuvalu
#* IP: 192.168.3.2
#* Serviço: HTTP
O CMS escolhido para o blog foi o [http://br.wordpress.org Wordpress], um dos [http://www.opensourcecms.com/general/cms-marketshare.php mais utilizados]. De acordo com o cenário, o banco de dados será instalado no primeiro servidor, <tt>bora-bora</tt>, enquanto que o servidor Web será no segundo, <tt>Tuvalu</tt>.
====Servidor 0: Bora-bora====
====Servidor 1: Tuvalu====
Em seguida, é descarregado o código do Wordpress (última versão = 3.3.2) no diretório de publicação, <tt>/var/www</tt>, para compor a URL <tt>/blog</tt>:
Após a [http://codex.wordpress.org/pt-br:Instalando_o_WordPress configuração do blog], pode-se facilitar o acesso ao código para o ''webmaster'' utilizando o [http://www.ietf.org/rfc/rfc2518.txt WebDAV], que expande os métodos HTTP. Primeiro, é ativado o módulo do Apache e reiniciado o serviço:
onde adiciona-se a seguinte linha após a definição do <tt>VirtualHost</tt>:
Na configuração do servidor Web via HTTPS, altera-se o certificado antigo por esse. No arquivo </tt>/etc/apache2/sites-enabled/default-ssl</tt> deve-se trocar as linhas:
SSLCertificateFile /etc/ssl/certs/apache2.pem
Até o presente momento, o blog está publicado na Web, com tráfego HTTPS disponível. Contudo, qualquer pessoa, inclusive o ''webmaster'' pode alterar o código PHP. Para controlar esse acesso, é adicionado um esquema de autenticação para [http://httpd.apache.org/docs/2.2/mod/core.html#limit limitar os métodos HTTP]. Exceto os métodos básicos GET e POST, todos os outros métodos irão requerer autenticação:
E, por fim, é criado o arquivo de senhas, <tt>/etc/apache2/blog-senhas</tt> com o comando <tt>htpasswd</tt>, e um primeiro chamado ''webmaster'':
Embora se pergunte se ainda será possível ver o código PHP do Wordpress, ou mesmo os arquivos de usuário enviados via ''upload'', usando WebDAV, a resposta é sim. Mas como o código já é ''software'' livre, e as imagens já estão disponíveis, qual a diferença?
Se quiser, pode-se utilizar outros métodos mais sofisticados, como WebDAV via HTTPS e acesso regular ao blog via HTTP. Assim, para todo o tráfego HTTPS é preciso autenticação do ''webmaster'', tornando a solução mais segura.
O [http://tele.sj.ifsc.edu.br blog de Tele] tem um cenário semelhante:
* HTTP sem WebDAV e sem senha:
** Blog: http://tele.sj.ifsc.edu.br/blog.
** Leitura de arquivo públicos: http://tele.sj.ifsc.edu.br/arquivos/alunos e http://tele.sj.ifsc.edu.br/arquivos/publicos/.
* HTTPS com WebDAV e com senha:
** Leitura e Escrita de arquivos públicos e restritos: todos os arquivos públicos, https://tele.sj.ifsc.edu.br/arquivos/cotel e https://tele.sj.ifsc.edu.br/arquivos/tele/.
digraph HTTP
* Pacotes instalados:
* Comandos executados:
* Arquivos/diretórios modificados:
digraph DHTML
===''Webmail''===
A aplicação Web escolhida foi [http://roundcube.net/ RoundCube], que implementa uma interface amigável ao usuário final, como arrastar e soltar mensagens de uma caixa a outra (embora isso soe antigo, é bom lembrar que ainda [http://www.w3counter.com/globalstats.php há usuários com navegador sem suporte a tais funcionalidades]). De acordo com o cenário, assim como o [[#Blog|blog]], o banco de dados será criado no servidor <tt>bora-bora</tt> e a aplicação Web em <tt>tuvalu</tt>.
O servidor Web também será de SMTP e de IMAP, permitindo que, futuramente, seja permitido apenas o ''webmail'' em detrimento das aplicações locais (''desktop'').
Assim, para instalar o servidor SMTP, optou-se pelo [http://www.postfix.org Postfix] por questões didáticas: [http://www.postfix.org/documentation.html documentação e facilidade de configuração] e integração com outras aplicações. Dica: [http://www.postfix.org/BASIC_CONFIGURATION_README.html atenção especial aos parâmetros que iniciam por <tt>my</tt>].
Uma vez instalado, o principal arquivo de configuração, <tt>/etc/postfix/main.cf</tt>, fica assim:
Como a ênfase está no ''webmail'', ao invés da aplicação de ''desktop'', será utilizado um servidor simples de IMAP, com a intenção de acesso exclusivo via Web:
E pronto! Não é necessário qualquer configuração. Lembrando que a configuração apresentada para ambos os serviços prevê usuários locais do sistema instalado; ou seja, todos aqueles listados nas fontes de busca (<tt>/etc/nsswitch.conf</tt>).
Embora as permissões não sejam as ideais (ainda é possível valores mais agressivos), isso permite a [http://trac.roundcube.net/wiki/Howto_Install continuação da aplicação via interface Web]:
Segundo o guia oficial de instalação, é importante adicionar algumas permissões à aplicação (<tt>AllowOverride</tt>), uma vez que a mesma utiliza arquivos <tt>.htaccess</tt> para reduzir o acesso em alguns diretórios. Portanto, deve ser criado um arquivo de configuração para o Apache:
E, por fim, adicionar as linhas referentes ao serviço de email no serviço DNS, mas especificamente no final do arquivo <tt>/etc/bind/rtfm.com.br</tt>:
@ IN MX 0 mail.rtfm.com.br.
mail IN A 192.168.3.2
Ou, para aqueles que já conhecem o [http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf rndc]:
==Gerência de Rede==
A gerência de rede, embora vista oficialmente apenas no último mês de aula, é vista ao longo de toda a disciplina - por isso o seu nome. No modelo OSI, é utilizado o padrão [http://en.wikipedia.org/wiki/FCAPS FCAPS]:
* Monitoramento (''fault''): o recurso está ''disponível''?
* Configuração (''configuration''): o recurso está bem ''configurado''?
* Contabilização (''accounting''): ''quanto'' do recurso está sendo utilizado?
* Desempenho (''performance''): o recurso está sendo ''bem'' usado?
* Segurança (''security''): o recurso está ''protegido''?
===Monitoramento===
O monitoramento pode ser realizado a partir de ferramentas próprias do administrador (''scripts'' sob rotina), porém há aplicações desenvolvidas para tal, como por exemplo [http://nagios.org Nagios], [http://zenoss.com Zenoss] e outros.
Um ''script'':
===Contabilização===
Uma vez o recurso disponível em rede, pode-se contabilizar o seu uso; ou seja, ''quanto'' do recurso é utilizado. Na arquitetura TCP/IP, o protocolo mais usado para tal é o Simple Network Management Protocol (SNMP), documentado ao longo de [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#RFC_references várias RFCs]. Nesse protocolo, há as entidades principais: o ''dispositivo a ser monitorado'', deve possuir um ''agente'', uma aplicação simples que responde a requisições de consulta (<tt>GET</tt>) e de escrita (<tt>SET</tt>), e o ''gerente'' que realiza tais operações remotas (''network management system'' - NMS).
Cabe, portanto, ao gerente SNMP realizar, periodicamente, consultas aos vários agentes rodando nos dispositivos sob monitoramento. Esse processo regular se chama ''polling''. Porém, como cada agente possui informações específicas, como a tabela de roteamento de um roteador ou a quantidade de usuários conectados em um sistema UNIX-''like'', não há um modelo rígido de quais dados serão fornecidos. Ao invés disso, há um conjunto de documentos que definem quais informações estão disponíveis e como acessá-las: as ''Management Information Bases'' (MIBs). As MIBs organizam os dados de forma hierárquica, em árvore, onde cada um desses objetos (''object identifier'' - OID) possui:
* Uma localização numérica.
* Uma descrição textual.
* O tipo de dado a ser armazenado: número, data, texto, etc.
* O valor do dado.
Pelo fato de ser uma árvore, uma MIB pode, assim, estender a árvore global a partir de um ramo de outra MIB (lembrando: a árvore é uma estrutura de dados recursiva...). O subconjunto de MIBs utilizadas para um dispositivo (e seu agente) definem que informações podem ser coletadas pelo gerente. A título de exemplo, na [http://docs.oracle.com/cd/B16240_01/doc/em.102/b16244/chap1.htm#insertedID6 documentação de uma aplicação da Oracle] nota-se a extensão da árvore (nó .1.3.6.1.4.1) para atender a detalhes específicos do programa em questão.
Contudo, os comandos se aplicam apenas a operações básicas e acessando diretamente os dados. Para fazer pleno uso, i.e., utilizando as MIBs como referência, deve-se instalar também a lista atualizada das mesmas (e atualizar o arquivo de configuração <tt>snmp.conf</tt>):
Um último conceito: a troca de dados entre agente e gerente se dá quando ambos pertencem a um mesmo agrupamento, ou '''comunidade'''. Na versão 3 do SNMP, é possível adicionar ainda autenticação ao processo. Geralmente, utilizam-se as versões 1 (equipamentos antigos ou de poucas funcionalidades) ou 2c. Os comandos a seguir perfazem toda a árvore do dispositivo (sequências de consultas: <tt>GETNEXT</tt>) alvo de forma sequencial do equipamento 192.168.1.1 e que pertence à comunidade <tt>ifsc</tt>:
O primeiro é o comando convencional. O segundo apresenta o nó da árvore de acordo com a descrição da MIB correspondente. O terceiro, por fim, apresenta todos os elementos com seu "endereço" numérico. Para saber mais sobre a correspondência entre número e descrição, há o comando <tt>translate</tt>:
====Cenário====
No nosso cenário, é interessante que todos os equipamentos importantes na rede estejam conm seus agentes operando e respondendo, regularmente, ao gerente central. Para fins didáticos, será utilizado o [http://cacti.net Cacti] como gerente, o qual é implementado em plataforma AMP; logo, pode-se aproveitar toda a infraestrutura de serviço Web e MySQL dos servidores da DMZ (Matriz). Embora sua documentação seja suficiente no auxílio de uma [http://www.cacti.net/downloads/docs/html/install_unix.html instalação manual], a instalação automatizada também o é:
A configuração não será o foco deste tópico, uma vez que há [http://www.cacti.net/downloads/docs/html/basics.html documentação disponível para tal]. Ao invés, haverá a ênfase no SNMP em si.
Inicialmente, pode ser utilizada uma configuração bastante simples: um agente que define uma única comunidade somente-leitura para gerente remoto - no caso, a comunidade <tt>ifsc</tt>. Além disso, é bastante recomendado informar '''onde está''' e '''quem é o responsável''' pelo dispositivo monitorado, de forma que seja possível, em termos de tempo hábil, corrigir ou prevenir uma falha. Esses são os objetos <tt>SNMPv2-MIB::sysLocation.0</tt> (<tt>.1.3.6.1.2.1.1.6.0</tt>) e <tt>SNMPv2-MIB::sysContact.0</tt> (<tt>.1.3.6.1.2.1.1.4.0</tt>), respectivamente.
O primeiro comando aplica toda a configuração do agente SNMP. O segundo comando permite conexões remotas (além de ''loopback''). O último, por fim, reinicia o serviço agente.
Para testar, pode-se realizar os comandos no mesmo servidor onde está instalado o gerente (Web), consultando desde o tempo no ar do agente (''uptime''), bem como os parâmetros definidos manualmente no arquivo acima. Assumindo que o agente está no computador com o IP 192.168.1.1:
Ou, com o ''endereço'' na árvore de objetos:
* Tempo: <tt>.1.3.6.1.2.1.1.3.0</tt>
* Local: <tt>.1.3.6.1.2.1.1.4.0</tt>
* Responsável: <tt>.1.3.6.1.2.1.1.6.0</tt>
Logo, pode-se varrer (''walk'') um ramo superior da árvore comum a todos (<tt>.1.3.6.1.2.1.1<tt>), mostrando esses objetos próximos:
Enquanto que estatísticas de uso em outro, como quantidade de pacotes ''unicast'' transmitidos em outro, conferindo escalabilidade da árvore global:
Nota-se, em todos os casos, o índice designando cada interface: geralmente a interface ''loopback'' é a primeira (sufixo <tt>1</tt>), seguida pelas demais - e seus sufixos ou terminações na sequência: eth0 (<tt>2</tt>), eth1 (<tt>3</tt>), eth2 (<tt>4</tt>) e assim por diante.
A ferramenta [http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&substep=2&translate=Translate&tree=NO Cisco SNMP Object Navigator] pode ser útil para navegar pela árvore e sua definição através das MIBs.