Mudanças entre as edições de "PJI11103-2016-1"
(156 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 16: | Linha 16: | ||
==[[PJI3-TecTel#PJI3_-_PROJETO_INTEGRADOR_III|Plano de Ensino]]== | ==[[PJI3-TecTel#PJI3_-_PROJETO_INTEGRADOR_III|Plano de Ensino]]== | ||
+ | |||
+ | [[PJI3-TecTel_(Plano_de_Ensino) | Plano de ensino]] | ||
+ | |||
+ | == AVALIAÇÕES == | ||
+ | |||
+ | {| border="1" | ||
+ | !Aluno(a) | ||
+ | !Avaliação 1 | ||
+ | !Avaliação 2 | ||
+ | !Avaliação 3 | ||
+ | !Trabalho | ||
+ | !Média | ||
+ | |- | ||
+ | |Caroline ||(4,43*+7,65**)/2=6,04 ||7,63 ||7,75 ||10,00 ||7,86 | ||
+ | |- | ||
+ | |Christien ||6,17 ||(4,29*+9,00**)/2=6,65 ||6,00 ||10,00 ||7,21 | ||
+ | |- | ||
+ | |Thiago ||6,38 ||(2,92*+9,00**)/2=6,00 ||9,00 ||10,00 ||7,85 | ||
+ | |- | ||
+ | |Victor ||8,47 ||10,00 ||9,00 ||10,00 ||9,37 | ||
+ | |- | ||
+ | |} | ||
+ | '''*''' - Avaliação | ||
+ | |||
+ | '''**''' - Recuperação extra | ||
=Diário de aulas= | =Diário de aulas= | ||
Linha 768: | Linha 793: | ||
root@gerencia:~> | root@gerencia:~> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
+ | |||
+ | Quando é feita a configuração de rede via comando, normalmente é necessário alterar o arquivo /etc/resolv.conf e acrescentar neste arquivo um servidor DNS para resolver nome, conforme abaixo: | ||
+ | |||
+ | <code> nameserver 200.135.37.65</syntaxhighlight> | ||
==== Configuração no boot ==== | ==== Configuração no boot ==== | ||
Linha 873: | Linha 902: | ||
* [http://manpages.ubuntu.com/manpages/karmic/en/man1/wireshark.1.html wireshark]: o equivalente em modo gráfico (porém com muitas outras funcionalidades) | * [http://manpages.ubuntu.com/manpages/karmic/en/man1/wireshark.1.html wireshark]: o equivalente em modo gráfico (porém com muitas outras funcionalidades) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
'''Atividade''' | '''Atividade''' | ||
Linha 924: | Linha 947: | ||
{{Collapse bottom | Interfaces de rede e rotas estáticas}} | {{Collapse bottom | Interfaces de rede e rotas estáticas}} | ||
+ | |||
+ | ==Aula 8 - 15/04/16: Interfaces de rede - Atividades== | ||
+ | |||
+ | {{Collapse top | Atividades - Máquina virtual}} | ||
+ | |||
+ | '''A)''' Configurar interface de rede | ||
+ | |||
+ | # Verifique a configuração de sua interface de rede eth0, na sua máquina virtual. Se necessário corrija-a usando ''ifconfig'' assim: ip 192.168.2.X, sendo X o número do computador + 100 (exemplo: para o micro 2 (M2) X=102), roteador default = 192.168.2.1. '''Nameserver''' 200.135.37.65. | ||
+ | ## Teste a comunicação do seu computador, fazendo ''ping 192.168.2.1''. Tente pingar outras máquinas da rede. | ||
+ | ## Tente também pingar o IP 200.135.37.65. | ||
+ | ## Veja a tabela de rotas, usando '''netstat -rn''' ou '''route -n'''. | ||
+ | ## Verifique a rota seguida pelos datagramas enviados, usando ''traceroute -n 200.135.37.65''. Se o traceroute não estiver instalado insta-le-o ('''apt-get install traceroute'''). | ||
+ | # Configure sua máquina virtual servidora para que a informação de rede, configurada manualmente acima, fique permanente. Quer dizer, no próximo boot essa configuração deve ser ativada automaticamente. | ||
+ | # Adicione um ''IP alias'' a sua interface eth0. Esse novo IP deve ser configurado para 10.0.0.X/24 (X = item 1). | ||
+ | ## Tente pingar os computadores de seus colegas, usando ambos endereços: da rede 192.168.2.0/24 e da rede 10.0.0/24. | ||
+ | ## Enquanto acontecem os pings, visualize o tráfego pela interface eth0, usando o programa [http://manpages.ubuntu.com/manpages/karmic/en/man8/tcpdump.8.html tcpdump]: <syntaxhighlight lang=bash> | ||
+ | # Mostra o tráfego ICMP que passa pela interface eth1 | ||
+ | tcpdump -i eth1 -n icmp | ||
+ | </syntaxhighlight> | ||
+ | ## Pense em uma utilidade para ''IP alias'' ... | ||
+ | |||
+ | '''B)''' Coleta de tráfego | ||
+ | #Faça um ou mais pings para algum(ns) sítios e, com o uso de parâmetros apropriados, faça com que o ''tcpdump'': | ||
+ | ##Capture todos os pacotes da rede. | ||
+ | ##Capture somente os pacotes gerados por sua máquina. | ||
+ | ##Capture somente pacotes destinados à sua máquina. | ||
+ | ##Capture pacotes destinados ou originados da máquina 200.135.37.65. | ||
+ | ##Faça com que os pacotes capturados anteriormente sejam salvos num arquivo, chamado “pacotes_capturados.cap“. | ||
+ | ##Abra este arquivo com o Wireshark e analise. | ||
+ | |||
+ | '''C)''' Tabelas estáticas de roteamento | ||
+ | |||
+ | [[Imagem:Diagrama_para_construir_tabelas_de_roteamento_com_maquinas_virtuais-rede-2.jpg]] | ||
+ | |||
+ | #Configure as interfaces de rede (uma interface virtual – ip alias) de sua máquina servidora, conforme números de IPs sugeridos na Figura. Todas as máscaras de rede devem ser 255.255.255.0 ou /24. '''Não''' configure gateway. | ||
+ | #Configure sua máquina virtual servidora para rotear pacotes. | ||
+ | #Configure sua máquina virtual cliente para ser seu cliente de rede, conforme Figura. | ||
+ | #Montar as tabelas estáticas de roteamento para todas as redes de todos os seus colegas, de modo que todas as máquinas cliente tenham acesso entre si (“pingando” ente elas). | ||
+ | #Faça testes. Se houver problemas usar '''tcpdump''' para monitorar individualmente as interfaces e verificar onde está o problema. Lembre-se que os pacotes devem ter rota de ida e volta, portanto o problema pode ser no seu roteador ou de seu vizinho. Uma boa sequência de testes é: | ||
+ | ##Pingar entre cliente e roteador (servidor). | ||
+ | ##Do cliente pingar a interface externa do roteador. | ||
+ | ##Do cliente pingar a máquina do professor. Se funcionar até aqui seu roteador estará corretamente configurado. | ||
+ | ##Do roteador pingar a interface externa de outro roteador. | ||
+ | ##Do roteador pingar outro cliente. | ||
+ | ##Do seu cliente pingar outro cliente. | ||
+ | |||
+ | {{Collapse bottom | Atividades - Máquina virtual}} | ||
+ | |||
+ | ==Aula 9 - 19/04/16: Continuação Aula 8== | ||
+ | |||
+ | ==Aula 10 - 22/04/16: Interfaces de rede e roteamento estático== | ||
+ | |||
+ | #Conclusão do laboratório sobre interfaces de rede e roteamento estático; | ||
+ | #Configuração do servidor como roteador; | ||
+ | #Inserção de AP na rede. | ||
+ | |||
+ | ==Aula 11 - 26/04/16: NAT e DHCP== | ||
+ | |||
+ | {{collapse top | NAT }} | ||
+ | |||
+ | === NAT === | ||
+ | |||
+ | A tradução de endereço de rede (NAT - Network Address Translation), proposta pela [http://www.faqs.org/rfcs/rfc1631.html RFC 1631] em 1994, é uma função de rede criada para contornar o problema da escassez de endereços IP. Com a explosão no crescimento da Internet, e o mau aproveitamento dos endereços IP (agravado pelo endereçamento hierárquico), percebeu-se que o esgotamento de endereços poderia ser logo alcançado a não ser que algumas medidas fossem tomadas. Esse problema somente seria eliminado com a reformulação do protocolo IP, de forma a aumentar o espaço de endereços, que resultou na proposta do [http://www.faqs.org/rfcs/rfc2460.html IPv6] em 1998. Porém no início dos anos 1990 a preocupação era mais imediata, e pensou-se em uma solução provisória para possibilitar a expansão da rede porém reduzindo-se a pressão por endereços IP. O NAT surgiu assim como uma técnica com intenção de ser usada temporariamente, enquanto soluções definitivas não se consolidassem. Ainda hoje NAT é usado em larga escala, e somente deve ser deixado de lado quando IPv6 for adotado mundialmente (o que deve demorar). | ||
+ | |||
+ | NAT parte de um princípio simples: endereços IP podem ser compartilhados por nodos em uma rede. Para isto, usam-se endereços IP ditos não roteáveis (também chamados de inválidos) em uma rede, sendo que um ou mais endereços IP roteáveis (válidos) são usados na interface externa roteador que a liga a Internet. Endereços não roteáveis pertencem às subredes 10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12, e correspondem a faixas de endereços que não foram alocados a nenhuma organização e, portanto, não constam das tabelas de roteamento dos roteadores na Internet. A figura abaixo mostra uma visão geral de uma rede em que usa NAT: | ||
+ | |||
+ | [[Imagem:Nat-exemplo.png]] | ||
+ | |||
+ | Para ser possível compartilhar um endereço IP, NAT faz mapeamentos ''(IP origem, port origem, protocolo transporte)'' -> ''(IP do NAT, port do NAT, , protocolo transporte)'', sendo ''protocolo de transporte'' TCP ou UDP. Assim, para cada par ''(IP origem, port origem TCP ou UDP)'' o NAT deve associar um par ''(IP do NAT, port do NAT TCP ou UDP)'' (que evidentemente deve ser único). Assim, por exemplo, se o roteador ou firewall onde ocorre o NAT possui apenas um endeerço IP roteável, ele é capaz em tese de fazer até 65535 mapeamentos para o TCP (essa é a quantidade de ports que ele pode possui), e o mesmo para o UDP. Na prática é um pouco menos, pois se limitam os ports que podem ser usados para o NAT. Note que o NAT definido dessa forma viola a independência entre camadas, uma vez que o roteamento passa a depender de informação da camada de transporte. | ||
+ | |||
+ | ==== NAT no Linux ==== | ||
+ | |||
+ | Ver capítulo 35, seção 4, da [[Media:Gerencia_de_redes.pdf|apostila]]. | ||
+ | |||
+ | O NAT no Linux se configura com [http://manpages.ubuntu.com/manpages/jaunty/man8/iptables.8.html iptables]. As regras devem ser postas na tabela ''nat'', e aplicadas a chain ''POSTROUTING'', como no seguinte exemplo: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE ;Habilita o NAT | ||
+ | iptables -t nat -L ;Lista as atuais regras da tabela NAT | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | A regra acima faz com que todo o tráfego originado em 192.168.1.0/24, e que sai pela interface ''eth0'' deve ser mascarado com o endereço IP dessa interface. Esta regra diz o seguinte: todos os pacotes que passarem (POSTROUTING) por esta máquina com origem de 192.168.1.0/24 e sairem pela interface eth0 serão mascarados, ou seja sairão desta máquina com o endereço de origem como sendo da eth0. O alvo ''MASQUERADE'' foi criado para ser usado com links dinâmicos (tipicamente discados ou ADSL), pois os mapeamentos se perdem se o link sair do ar. | ||
+ | |||
+ | === Atividade === | ||
+ | |||
+ | '''D)''' NAT | ||
+ | #Desfaça as tabelas de roteamento. | ||
+ | #Configure a máquina cliente com os parâmetros: | ||
+ | ##IP, conforme o modelo da Figura | ||
+ | ##máscara: 255.255.255.0 ou /24 | ||
+ | ##default gw: ip_interno_do_seu_servidor | ||
+ | ##nameserver:200.135.37.65 | ||
+ | #Configure a máquina servidora para encaminhar pacote de uma interface a outra (''ip_forward''). | ||
+ | #Configure a máquina servidora para fazer NAT, por exemplo, no servidor do professor da Figura acima:<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. ...). | ||
+ | #A partir do cliente faça testes “pingando” para: | ||
+ | ##o próprio servidor | ||
+ | ##o servidor de colegas | ||
+ | ##redes externas | ||
+ | ##redes dos colegas. | ||
+ | #Qual é a diferença de “comportamento” quando comparado ao cenário das tabelas estáticas de roteamento? | ||
+ | |||
+ | {{collapse bottom | NAT }} | ||
+ | |||
+ | {{collapse top | DHCP }} | ||
+ | |||
+ | ===DHCP=== | ||
+ | |||
+ | Ver capítulo 31 da [[Media:Gerencia_de_redes.pdf|apostila]]. | ||
+ | |||
+ | Toda máquina que for participar de uma rede, deve primeiro, ter um endereço IP. Em uma rede pequena (até 20 máquinas), a tarefa de configurar IPs é relativamente simples. Mas em uma rede grande com centenas de máquinas, esta tarefa de endereçamento torna-se trabalhosa. Para facilitar as coisas, foi criado um mecanismo de endereçamento automático | ||
+ | de IP para máquinas em uma rede TCP/IP: o DHCP (Dynamic Host Configuration Protocol – Protocolo de configuração de máquinas dinâmico). Um servidor DHCP pode facilitar muito a vida do administrador da rede. | ||
+ | |||
+ | Dentre as configurações de serviços que podem ser passadas ao ''host'' cliente por dhcp são: | ||
+ | |||
+ | #Endereçamento IP, máscara de subrede, Gateway, Servidor(es) DNS, | ||
+ | #nome de host e/ou de domínio; | ||
+ | #Servidores e domínio NIS (autenticação); | ||
+ | #Servidores WINS (para redes Microsoft®); | ||
+ | #Servidores NTP (Hora); | ||
+ | #Imagens de boot para Terminais burros; | ||
+ | |||
+ | Como podemos observar, tudo o que é necessário para que uma máquina esteja em condições de ingressar em uma rede e usufruir de tudo o que ela possa oferecer, o DHCP se faz útil para sua configuração automática. | ||
+ | |||
+ | === Protocolo DHCP=== | ||
+ | |||
+ | Entenda, com a explicação a seguir, como funciona o protocolo DHCP. | ||
+ | |||
+ | '''a) DHCP Discover''' – Quando uma máquina é ligada, ela tem um serviço (daemon) cliente do DHCP configurado para localizar o servidor neste momento. Este cliente DHCP envia um pacote UDP com destino à porta 67 do servidor chamado “DHCP Discover”. Este pacote broadcast tem o endereço IP de destino 255.255.255.255 e mac address de destino ff:ff:ff:ff:ff:ff. | ||
+ | |||
+ | [[Arquivo:DHCP-discover.png|600px]] | ||
+ | |||
+ | '''b) DHCP Offer''' – O servidor ao receber o referido pacote em sua porta ethernet, irá analisá-lo e, em sua tabela de IPs, reservar um endereço e preparar um pacote de resposta ao cliente solicitante. Este pacote de resposta chama-se DHCP Offer. | ||
+ | |||
+ | [[Arquivo:DHCP-offer.png|600px]] | ||
+ | |||
+ | O único meio de a estação cliente saber que o pacote DHCP Offer se destina à ela, é através do mac address. | ||
+ | |||
+ | '''c) DHCP Request''' – O cliente ao receber o pacote do servidor, decide se aceita a configuração oferecida pois pode receber mais de uma oferta. Em caso positivo, retorna um novo pacote ao servidor, comunicando o aceitamento da oferta. Este pacote chama-se DHCP Request. | ||
+ | |||
+ | [[Arquivo:DHCP-request.png|600px]] | ||
+ | |||
+ | '''d) DHCP Ack''' – Para finalizar a “conversação” entre cliente e servidor DHCP, este finaliza (efetiva) o aluguel (lease) do endereço ao cliente em sua tabela de IPs, e envia àquele, um pacote DHCP Ack para que ele ajuste suas configurações. | ||
+ | |||
+ | [[Arquivo:DHCP-ack.png|600px]] | ||
+ | |||
+ | {{collapse bottom | DHCP}} | ||
+ | |||
+ | ==Aula 12 - 29/04/16: Aula cancelada== | ||
+ | |||
+ | Apenas o Christien compareceu e possuía apenas em torno de uma hora disponível, pois precisava sair cedo. Como o conteúdo terá de ser ministrado em outra aula, o mesmo foi dispensado desta uma hora que poderia assistir. | ||
+ | |||
+ | ==Aula 13 - 03/05/16: DHCP - prática== | ||
+ | |||
+ | {{collapse top | DHCP - atividade}} | ||
+ | |||
+ | ===Atividade=== | ||
+ | |||
+ | Em nosso experimento será usado o [http://www.isc.org/software/dhcp servidor DHCP desenvolvido pelo ISC]. Para usá-lo devem-se seguir os passos descritos abaixo. | ||
+ | |||
+ | # Instalar o serviço: <syntaxhighlight lang=bash> | ||
+ | apt-get install -y dhcp3-server | ||
+ | </syntaxhighlight> | ||
+ | # Configurar em ''/etc/dhcp/dhcpd.conf'', definindo as configurações globais e as redes onde o servidor DHCP irá ofertar endereços. Apague todo o conteúdo do arquivo original. '''X''' = 4, 5, 6 ou 7 a sua escolha, porém deve ser acordado entre os alunos quem usará cada faixa para não haver duplicação. <syntaxhighlight lang=text> | ||
+ | default-lease-time 600; | ||
+ | max-lease-time 7200; | ||
+ | option subnet-mask 255.255.255.0; | ||
+ | option broadcast-address 192.168.1.255; | ||
+ | option routers 192.168.1.1; | ||
+ | option domain-name-servers 200.135.37.65; | ||
+ | |||
+ | subnet 192.168.1.0 netmask 255.255.255.0 { | ||
+ | range 192.168.1.X1 192.168.1.X5; | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | # Editar a interface que vai atender ao DHCP, no exemplo abaixo eth0, se a sua máquina utilizar uma interface diferente de eth0 faça a devida correção, por exemplo, eth1, eth2...: <syntaxhighlight lang=text> | ||
+ | vi /etc/default/isc-dhcp-server | ||
+ | INTERFACES="eth0" </syntaxhighlight> | ||
+ | # Iniciar o servidor DHCP: <syntaxhighlight lang=text> | ||
+ | service isc-dhcp-server restart | ||
+ | </syntaxhighlight> | ||
+ | # Verifique o log no servidor e observe a troca de mensagens entre o cliente e o servidor: <syntaxhighlight lang=text> | ||
+ | tail -f /var/log/syslog </syntaxhighlight> | ||
+ | # Intale e use o utilitário o '''dhclient''' de sua máquina virtual com ambiente gráfico como cliente para testes <syntaxhighlight lang=bash> | ||
+ | apt-get install isc-dhcp-client | ||
+ | dhclient -v eth0 </syntaxhighlight> | ||
+ | # Verifique o log no servidor e observe a troca de mensagens entre o cliente e o servidor. <syntaxhighlight lang=text> | ||
+ | tail -f /var/log/syslog </syntaxhighlight> | ||
+ | # Verifique os aluguéis no seu servidor com: <syntaxhighlight lang=text> | ||
+ | cat /var/lib/dhcp/dhcpd.leases </syntaxhighlight> | ||
+ | # Desafio: fixe um IP para algum cliente seu (por exemplo seu vizinho). | ||
+ | |||
+ | Maiores detalhes sobre esse servidor DHCP: | ||
+ | * [http://manpages.ubuntu.com/manpages/karmic/en/man8/dhcpd.8.html dhcpd - o servidor DHCP] | ||
+ | * [http://manpages.ubuntu.com/manpages/dapper/en/man5/dhcpd.conf.5.html dhcpd.conf - o arquivo de configuração do DHCP] | ||
+ | * [http://manpages.ubuntu.com/manpages/karmic/en/man5/dhcp-options.5.html Opções do protocolo DHCP] | ||
+ | * [http://manpages.ubuntu.com/manpages/dapper/en/man8/dhclient.8.html dhclient - o cliente DHCP] | ||
+ | |||
+ | {{collapse bottom | DHCP - atividade}} | ||
+ | |||
+ | ==Aula 14 - 06/06/16: Avaliação individual== | ||
+ | |||
+ | Avaliação individual prática e teórica dos conteúdos vistos até o momento. | ||
+ | |||
+ | Conteúdos: | ||
+ | |||
+ | #Gerência de usuários e grupos; | ||
+ | #Permissionamento de arquivos; | ||
+ | #Acesso remoto via SSH; | ||
+ | #Interfaces de rede; | ||
+ | #Roteamento estático em servidor Linux; | ||
+ | #NAT; | ||
+ | #DHCP. | ||
+ | |||
+ | |||
+ | ==Aula 15 - 10/05/16: DNAT== | ||
+ | |||
+ | {{collapse top |DNAT}} | ||
+ | |||
+ | Anteriormente estudamos NAT com o intuito de mascarar IPs não roteáveis no âmbito da internet para IPs roteáveis no âmbito da internet. Este tipo de NAT é denominado SNAT e é aplicado quando desejamos alterar o endereço de origem de um determinado pacote. | ||
+ | |||
+ | Agora iremos estudar uma outra forma de implementar NAT, o DNAT. O DNAT aplica-se quando desejamos alterar o endereço de destino de um pacote. O redirecionamento de portas e o redirecionamento de servidores são um exemplo de DNAT e iremos utilizá-los nesta aula. | ||
+ | |||
+ | Para fazermos redirecionamento de porta apenas, devemos executar o seguinte comando: <code> iptables -t nat -A PREROUTING -p tcp -d ip_de_destino_do_pacote --dport porta_de_destino -j REDIRECT --to-port porta_da_aplicação </syntaxhighlight> | ||
+ | |||
+ | 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 tcp --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> | ||
+ | |||
+ | '''Atividades''' | ||
+ | |||
+ | #Abrir uma máquina virtual servidor e fazer a seguinte configuração prévia: | ||
+ | ##IP alias na faixa 10.0.X.0/24, onde X é o número da sua máquina; | ||
+ | ##Tornar a máquina um roteador; | ||
+ | ##Mascarar IPs da rede interna. | ||
+ | #Abrir uma máquina virtual com interface gráfica (cliente) com IP na faixa 10.0.X.0/24 e colocar a máquina servidor como ''gateway default'' | ||
+ | #Instalar um servidor SSH na máquina cliente e na maquina servidor , caso ainda não esteja. <code> apt-get install ssh</syntaxhighlight> | ||
+ | #Na máquina servidor fazer as seguintes regras de NAT: | ||
+ | ##Redirecionar os acesso à porta 222 para a porta 22 do mesma máquina; | ||
+ | ##Redirecionar os acesso à porta 2222 para a porta 22 da máquina cliente. | ||
+ | #Instalar um servidor Apache (HTTP) na máquina cliente e na maquina servidor. <code> apt-get install apache2</syntaxhighlight> | ||
+ | #Na máquina servidor fazer as seguintes regras de NAT: | ||
+ | ##Redirecionar os acesso à porta 8080 para a porta 80 do mesma máquina; | ||
+ | ##Redirecionar os acesso à porta 8088 para a porta 80 da máquina cliente. | ||
+ | |||
+ | {{collapse bottom |DNAT}} | ||
+ | |||
+ | ==Aula 16 - 13/05/16: DNAT no servidor e Correção da prova== | ||
+ | |||
+ | ==Aula 17 - 17/05/16: Apache== | ||
+ | |||
+ | {{collapse top | WWW e protocolo HTTP}} | ||
+ | |||
+ | === 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] | ||
+ | |||
+ | {{collapse bottom | WWW e protocolo HTTP}} | ||
+ | |||
+ | {{collapse top | Apache}} | ||
+ | |||
+ | ===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://192.168.2.1X/ (X é 02 para o micro 2, 03 para o 3, e assim por diante). | ||
+ | |||
+ | === 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 é utilizado é 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, define-se um servidor WWW chamado ''www.prj.edu.br'', que atende requisições no ''ports'' 8080. | ||
+ | |||
+ | #Crie um arquivo '''vi /etc/apache2/sites-available/prj.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> | ||
+ | #Crie um link simbólico para o arquivo prj:<syntaxhighlight lang=text> | ||
+ | ln -s /etc/apache2/sites-available/prj.conf /etc/apache2/sites-enabled/ </syntaxhighlight> | ||
+ | #Edite o arquivo /etc/hosts e acrescente: <syntaxhighlight lang=text> | ||
+ | 192.168.1.X www.prj.edu.br </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>PRJ!</h1> | ||
+ | <p>Esta e minha pagina.</p> | ||
+ | </body></html> | ||
+ | </syntaxhighlight> | ||
+ | #Restarte o Apache: <syntaxhighlight lang=text> | ||
+ | service apache2 restart </syntaxhighlight> | ||
+ | #Com o navegador acesse: 192.168.1.X e 192.168.1.X:8080 | ||
+ | #Com o navegador da máquina onde está instalado o Apache, acesse: www.prj.edu.br e www.prj.edu.br:8080 | ||
+ | #Crie uma página personalizada e coloque em /var/www/html/pessoal/index.html. Acesse 192.168.2.1X/pessoal e visualize a mesma. | ||
+ | |||
+ | 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 com IP interno, instale o Apache e crie uma página básica para a sua equipe; | ||
+ | # No servidor que faz o papel de ''gateway'' de rede, direcione todo o tráfego destinado a porta 80 (ou outra, se assim foi configurado no Apache) para o servidor onde o Apache está instalado; | ||
+ | #Teste o funcionamento. | ||
+ | |||
+ | Obs.: Não é necessário alterar o arquivo /etc/hosts, como na atividade acima. | ||
+ | |||
+ | {{collapse bottom | Apache}} | ||
+ | |||
+ | {{collapse top | Relatório individual - Complementação Av 1}} | ||
+ | |||
+ | ===Relatório individual=== | ||
+ | |||
+ | Gerar um documento sobre os TODOS as configurações e serviços que já estão rodando na máquina Servidor de cada Equipe. O trabalho deve ser individual e deve ser entregue em 27/05. Entregar em formato PDF. Os conteúdos a serem abordados no relatório são: | ||
+ | |||
+ | #Gerência de usuários e grupos; | ||
+ | #Permissionamento de arquivos; | ||
+ | #Acesso remoto via SSH; | ||
+ | #Interfaces de rede; | ||
+ | #Roteamento estático em servidor Linux; | ||
+ | #NAT; | ||
+ | #DHCP. | ||
+ | |||
+ | O trabalho deve contemplar os seguintes pontos: | ||
+ | |||
+ | # Escrever uma breve fundamentação teórica sobre os conteúdos listados acima. Esta parte teórica deve conter uma breve descrição do princípio de funcionamento de cada um dos itens. Não esqueça de apresentar as fontes usadas na pesquisa; | ||
+ | # Descrever como foram feitas as configurações na máquina servidora. Comentar sobre os arquivos de configuração e as configurações efetuadas. | ||
+ | # Demonstrar o funcionamento através de prints, logs, saídas de comandos, etc. Comentar os resultados obtidos. | ||
+ | |||
+ | {{collapse bottom | Relatório individual - Complementação Av 1}} | ||
+ | |||
+ | ==Aula 18 - 20/05/16: DNS== | ||
+ | |||
+ | {{Collapse top |DNS}} | ||
+ | |||
+ | Ver capítulo 25 da [[Media:Gerencia_de_redes.pdf|apostila]]. | ||
+ | |||
+ | '''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 domí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 o ''"."'' (último) significa o ''root level domain'' ''.br'' é o domínio do topo da hierarquia (no Brasil feito em [https://registro.br/])ao qual ''mail.sj.ifsc.edu.br'' pertence. ''.ifsc.edu'' é um subdomínio de ''.br.'', 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 envia as consultas para um ou mais servidores de nomes e interpreta as respostas. | ||
+ | |||
+ | [[Imagem:dns2.jpg|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> | ||
+ | root@freeman:~$ 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'' (''Time To Live'') é 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> | ||
+ | $TTL 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> | ||
+ | |||
+ | 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. | ||
+ | SOA – é o preâmbulo, o 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 ou seja debian.com.br) a diferença de usar o arroba é que ele será repetido automaticamente nas demais linhas caso não seja informado outro nome de zona, depois 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. | ||
+ | Em resumo um registro de recurso é uma tupla (linha) contendo 5 campos, sendo que alguns podem ser omitidos, seguem a seguinte ordem: | ||
+ | Domain Name Informa o domínio ao qual o registro se aplica, existem muitos registros para cada domínio, e cada cópia do banco de dados armazena informações sobre vários domínios, esse campo é a chave de pesquisa primária utilizada para atender às consultas | ||
+ | Time_to_live indica a estabilidade do registro, é dado em segundos | ||
+ | Class caso esteja relacionado a internet seu valor será sempre IN | ||
+ | Type informa o tipo de registro, dentre os mais importantes podemos os que aparecem na segunda tabela. | ||
+ | |||
+ | 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 que o servidor de DNS primário irá armazenar, informamos no arquivo em questão o ns1.debian.com.br. e o ns2.debian.com.br. Informamos também um registro do tipo MX (Mail Exchanger) com prioridade 10 (quanto menor o número da prioridade maior será a prioridade dada ao servidor de e-mail no recebimento de e-mails). E por último foram feitas as associações entre nameserver e seus respectivos IP’s. | ||
+ | |||
+ | === Comando útil === | ||
+ | |||
+ | Comando para recarregar os arquivos de configuração e zonas: | ||
+ | |||
+ | <syntaxhighlight lang=text> rndc reload </syntaxhighlight> | ||
+ | |||
+ | === Atividade === | ||
+ | |||
+ | O objetivo é montar a seguinte estrutura: | ||
+ | |||
+ | [[Arquivo:Diagrama_DNS_redesII.png]] | ||
+ | |||
+ | 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.1.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 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 | ||
+ | dig ufsc.br ANY ; consulta "total" ao domínio</syntaxhighlight> | ||
+ | # Instale o servidor DNS em sua máquina:<code>apt-get install bind9. Instalando o Bind.</syntaxhighlight> | ||
+ | # Configure a sua zona, onde X = 2 para M2, 3 Para M3, ... 10 para M10, ..., 14 para M14 e Y = 100 + o número da sua máquina. | ||
+ | |||
+ | vi /etc/bind/named.conf.local<code> | ||
+ | zone "redesX.edu.br" { | ||
+ | type master; | ||
+ | file "/etc/bind/db.redesX"; | ||
+ | allow-transfer { | ||
+ | 192.168.1.101; | ||
+ | }; | ||
+ | };</syntaxhighlight> | ||
+ | #vi /etc/bind/db.redesX<code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA ns.redesX.edu.br. admin.redesX.edu.br. ( | ||
+ | 2014040902; serial | ||
+ | 3H ; refresh | ||
+ | 60 ; retry | ||
+ | 1W ; expire | ||
+ | 3W ; minimum | ||
+ | ) | ||
+ | @ IN NS ns.redesX.edu.br. ; este é o servidor master deste domínio | ||
+ | @ IN MX 10 mail.redesX.edu.br. | ||
+ | $ORIGIN redesX.edu.br. | ||
+ | m80 A 192.168.1.Y | ||
+ | mail A 192.168.1.Y | ||
+ | www A 192.168.1.Y | ||
+ | ftp A 192.168.1.Y | ||
+ | ns A 192.168.1.Y | ||
+ | </syntaxhighlight> | ||
+ | #vi /etc/resolv.conf<code> | ||
+ | nameserver 192.168.1.101 | ||
+ | </syntaxhighlight> | ||
+ | #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 redesX.edu.br /etc/bind/db.redesX</syntaxhighlight> | ||
+ | #Utilitário para testar a configuração do BIND: <code> named-checkconf -z </syntaxhighlight> | ||
+ | #Restart do serviço:<code> service bind9 restart </syntaxhighlight> | ||
+ | #Verificando se está tudo certo:<code> tail -n 200 /var/log/syslog. Se necessário filtre por named. </syntaxhighlight> | ||
+ | |||
+ | * Seqüênica de Testes: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | ping www.redes12.edu.br | ||
+ | ping m8.redes8.edu.br | ||
+ | ping www.redesX.edu.br ; dos seus colegas | ||
+ | dig @localhost m14.redes14.edu.br | ||
+ | dig @192.168.1.101 m7.redes7.edu.br | ||
+ | dig redesX.edu.br ANY | ||
+ | </syntaxhighlight> | ||
+ | * Teste o DNS reverso. Faça testes usando a ferramenta “dig”: <syntaxhighlight lang=bash> | ||
+ | dig -x 192.168.1.101 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==== Arquivos na máquina '''Professor''', somente para exemplificar ==== | ||
+ | |||
+ | mkdir /var/cache/bind/slaves | ||
+ | chown bind:bind /var/cache/bind/slaves | ||
+ | |||
+ | {{collapse top | /etc/bind/named.conf.local}} | ||
+ | <code> | ||
+ | // | ||
+ | // Do any local configuration here | ||
+ | // | ||
+ | |||
+ | // Consider adding the 1918 zones here, if they are not used in your | ||
+ | // organization | ||
+ | //include "/etc/bind/zones.rfc1918"; | ||
+ | |||
+ | zone "redes1.edu.br" { | ||
+ | type master; | ||
+ | file "/etc/bind/db.redes1"; | ||
+ | }; | ||
+ | zone "2.168.192.in-addr.arpa" IN { | ||
+ | type master; | ||
+ | file "/etc/bind/db.1.168.192"; | ||
+ | }; | ||
+ | |||
+ | zone "redes2.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes2"; | ||
+ | masters { 192.168.1.102; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes3.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes3"; | ||
+ | masters { 192.168.1.103; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes4.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes4"; | ||
+ | masters { 192.168.1.104; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes5.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes5"; | ||
+ | masters { 192.168.1.105; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes6.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes6"; | ||
+ | masters { 192.168.1.106; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes7.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes7"; | ||
+ | masters { 192.168.1.107; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes8.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes8"; | ||
+ | masters { 192.168.1.108; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes9.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes9"; | ||
+ | masters { 192.168.1.109; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes10.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes10"; | ||
+ | masters { 192.168.1.110; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes11.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes11"; | ||
+ | masters { 192.168.1.111; }; | ||
+ | }; | ||
+ | zone "redes12.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes12"; | ||
+ | masters { 192.168.1.112; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes13.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes13"; | ||
+ | masters { 192.168.1.113; }; | ||
+ | }; | ||
+ | |||
+ | zone "redes14.edu.br" IN { | ||
+ | type slave; | ||
+ | file "/var/cache/bind/slaves/db.redes14"; | ||
+ | masters { 192.168.1.114; }; | ||
+ | }; | ||
+ | </syntaxhighlight> | ||
+ | {{collapse bottom}} | ||
+ | |||
+ | {{collapse top | /etc/bind/db.redes1}} | ||
+ | <code> | ||
+ | ; BIND reverse data file for empty rfc1918 zone | ||
+ | ; | ||
+ | ; DO NOT EDIT THIS FILE - it is used for multiple zones. | ||
+ | ; Instead, copy it, edit named.conf, and use that copy. | ||
+ | ; | ||
+ | $TTL 86400 | ||
+ | @ IN SOA m1.redes1.edu.br. root ( | ||
+ | 2014040900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | @ IN NS m1.redes1.edu.br. | ||
+ | @ IN MX 10 mail.redes1.edu.br. | ||
+ | $ORIGIN redes1.edu.br. | ||
+ | m1 A 192.168.1.101 | ||
+ | www A 192.168.1.101 | ||
+ | ftp A 192.168.1.101 | ||
+ | mail A 192.168.1.101 | ||
+ | </syntaxhighlight> | ||
+ | {{collapse bottom}} | ||
+ | |||
+ | {{collapse top | /etc/bind/db.1.168.192 (Zona reversa)}} | ||
+ | <code> | ||
+ | $TTL 86400 | ||
+ | @ IN SOA m1.redes1.edu.br. root ( | ||
+ | 2014040900 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 86400 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | IN NS m1.redes1.edu.br. | ||
+ | 101 IN PTR m1.redes1.edu.br. | ||
+ | 102 IN PTR m2.redes2.edu.br. | ||
+ | 103 IN PTR m3.redes3.edu.br. | ||
+ | 104 IN PTR m4.redes4.edu.br. | ||
+ | 105 IN PTR m5.redes5.edu.br. | ||
+ | 106 IN PTR m6.redes6.edu.br. | ||
+ | 107 IN PTR m7.redes7.edu.br. | ||
+ | 108 IN PTR m8.redes8.edu.br. | ||
+ | 109 IN PTR m9.redes9.edu.br. | ||
+ | 110 IN PTR m10.redes10.edu.br. | ||
+ | 111 IN PTR m11.redes11.edu.br. | ||
+ | 112 IN PTR m12.redes12.edu.br. | ||
+ | 113 IN PTR m13.redes13.edu.br. | ||
+ | 114 IN PTR m14.redes14.edu.br. | ||
+ | </syntaxhighlight> | ||
+ | {{collapse bottom}} | ||
+ | |||
+ | {{collapse bottom}} | ||
+ | |||
+ | ==Aula 19 - 24/05/16: DNS e Apache no servidor das equipes== | ||
+ | |||
+ | Na aula de hoje serão executados os seguintes pontos: | ||
+ | |||
+ | #Instalar o servidor DNS no Servidor 1 de cada equipe; | ||
+ | #Configurar o sub-domínio prjiX.sj.ifsc.edu.br, conforme ordem abaixo: | ||
+ | ##prji1 e prji2.sj.ifsc.edu.br pertencem à equipe 1; | ||
+ | ##prji3 e prji4.sj.ifsc.edu.br pertencem à equipe 2; | ||
+ | #No Servidor 2 devem ser criadas duas páginas Web para cada equipe. Para isso, deverão ser criados Virtual Hosts baseados em nome, sendo que o ServerName de cada página deve ser configurado como www.prjiX.sj.ifsc.edu.br; | ||
+ | #Configurar no Servidor 1 para que ao digitar www.prjiX.sj.ifsc.edu.br no navegador, um usuário consiga acessar uma página Web no Servidor 2 de cada equipe; | ||
+ | #Criar uma terceira página no Servidor 2 com o ServerName como www.minharedeinterna.edu.br; | ||
+ | #No Servidor 1, configurar uma zona minharedeinterna.edu.br; | ||
+ | #Associar o nome www.minharedeinterna.edu.br ao IP interno do Servidor 2; | ||
+ | #Criar uma página Web no Servidor 2 com o ServerName como www.minharedeinterna.edu.br; | ||
+ | #Fazer testes diversos. | ||
+ | |||
+ | ==Aula 20 - 27/05/16: Compartilhamento de arquivos via FTP e HTTP== | ||
+ | |||
+ | Nesta aula teremos os seguintes pontos: | ||
+ | |||
+ | #Conclusão dos quatro últimos itens da aula anterior; | ||
+ | # Compartilhamentos de arquivos via HTTP; | ||
+ | # Compartilhamento de arquivos via FTP. | ||
+ | |||
+ | {{Collapse top | Compartilhamento de arquivos via FTP e HTTP}} | ||
+ | |||
+ | ===Disponibilização de arquivos via Apache=== | ||
+ | |||
+ | As configurações padrões do Apache já fazem com que ele possa disponibilizar arquivos para download via web. Para isso, faça o seguinte no Servidor 2 da equipe: | ||
+ | |||
+ | # Crie um diretório pra disponibilização de arquivos da pasta base da sua página (/var/www/html/dir_pagina/dir_arquivos): | ||
+ | #Crie ou copie arquivos diversos para dentro desta página; | ||
+ | #Acesse o seu servidor Apache da seguinte forma no Browser:<code>http://ip_ou_dominio_apache/dir_arquivos</syntaxhighlight> | ||
+ | #Permita que a sua página seja acessada por qualquer usuário. Para isso edite o arquivo /etc/apache2/sites-available/minha_pagina.conf e insira: <code> < Directory> /var/www/html/dir_pagina> | ||
+ | order allow,deny | ||
+ | allow from all | ||
+ | </Directory> </syntaxhighlight> | ||
+ | #Permita que a sua pasta de compartilhamento de arquivos seja acessível somente para a rede interna. Para isso edite o arquivo /etc/apache2/sites-available/minha_pagina.conf novamente e insira mais estes parâmetros: <code> <Directory /var/www/html/dir_pagina/dir_arquivos> | ||
+ | order allow,deny | ||
+ | allow from 172.18.15.150 | ||
+ | #deny from all | ||
+ | </Directory> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === FTP=== | ||
+ | |||
+ | '''Material de apoio FTP:''' ([[Arquivo:Aula FTP.pdf]]) | ||
+ | |||
+ | |||
+ | Na máquina virtual executar os seguintes passos: | ||
+ | |||
+ | #Instalar um servidor FTP e escolher o modo '''Autônomo'''.<code>sudo apt-get install proftpd</syntaxhighlight> | ||
+ | #Configurar o arquivo /etc/proftpd/proftpd.conf e alterar os seguintes pontos: <code>UseIPv6 off | ||
+ | ServerName "Seu nome" | ||
+ | ServerIdent on "Saudação qualquer" | ||
+ | DefaultRoot ~ | ||
+ | RequireValidShell off | ||
+ | </syntaxhighlight> | ||
+ | #Criar um usuário para testes (ex. userftp) colocando a ''shell'' do usuário como /bin/false. | ||
+ | #Em /etc/ftpusers acrescentrar os usuários convencionais da sua máquina para que estas contas não possam ser usadas para acesso FTP. | ||
+ | #Restartar o servidor FTP: <code> /etc/init.d/proftpd restart </syntaxhighlight> | ||
+ | #Acessar o servidor FTP via terminal da máquina real usando este novo usuário e o usuário aluno.<code>ftp ip_do_servidor</syntaxhighlight> | ||
+ | #Copiar arquivos da máquina local para o servidor e vice-e-versa.<code>put nome_arquivo | ||
+ | get nome_arquivo</syntaxhighlight> | ||
+ | #Acessar o servidor via Browser na máquina real digitando ftp://IP_servidor_FTP. Fazer login com o usuário criado e testar subir níveis de diretórios. Foi possível? Por quê? | ||
+ | #Baixar o cliente Filezilla na sua máquina virtual com gráfico. <code>sudo apt-get -y install filezilla</syntaxhighlight> | ||
+ | #Conectar no servidor FTP via Filezilla com o usuário criado e testar enviar e receber arquivos. | ||
+ | #Editar o arquivo proftpd.conf e comentar a opção DefaultRoot. | ||
+ | #Acessar o Servidor FTP pelo Browser e verificar se é possível subir na árvore de diretórios. | ||
+ | #Editar o arquivo proftpd.conf, descomentar a opção DefaultRoot novamente e descomentar também de <Anonymous ~ftp> até </Anonymous>. | ||
+ | #Logar como Anonymous tanto via Browser como via Filezilla. | ||
+ | #Logar via Browser com um usuário diferente de Anonymous da seguinte forma: ftp://usuário:senha@IP_servidor_FTP | ||
+ | # No Filezilla, tentar enviar e receber arquivos. Foi possível? | ||
+ | |||
+ | {{Collapse bottom | Compartilhamento de arquivos via FTP e HTTP}} | ||
+ | |||
+ | ==Aula 21 - 31/05/16: Conclusão FTP e revisão para a prova== | ||
+ | |||
+ | {{Collapse top |FTP no Servidor }} | ||
+ | |||
+ | Foi inicialmente solicitado configurar um servidor FTP na máquina Servidor 2 de cada equipe. Devido a problemas com NAT, deve-se desinstalar o servidor FTP do Servidor 2 e instalá-lo e configurá-lo no Servidor 1. | ||
+ | |||
+ | {{Collapse bottom |FTP no Servidor }} | ||
+ | |||
+ | ==Aula 22 - 03/06/16: Avaliação individual == | ||
+ | |||
+ | Avaliação individual prática e teórica dos seguintes conteúdos: | ||
+ | |||
+ | Conteúdos: | ||
+ | |||
+ | #Apache; | ||
+ | #DNS; | ||
+ | #FTP. | ||
+ | |||
+ | ==Aula 23 - 06/06/16: Firewall == | ||
+ | |||
+ | {{collapse top | Firewall}} | ||
+ | |||
+ | === Uma introdução ao iptables === | ||
+ | |||
+ | * [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências] | ||
+ | * [http://www.sans.org/reading_room/whitepapers/firewalls/ Uma coleção de textos técnicos sobre firewalls e suas aplicações] | ||
+ | * Ver capítulo 35 da [[Media:Gerencia_de_redes.pdf|apostila]]. | ||
+ | |||
+ | |||
+ | O filtro IP do Linux se chama [http://www.netfilter.org/ NetFilter], e suas regras são configuradas por meio do utilitário [https://help.ubuntu.com/community/IptablesHowTo iptables] (ver também seu [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados ''chains'' ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três ''chains'' predefinidas: | ||
+ | * '''INPUT:''' contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall. | ||
+ | * '''OUTPUT:''' contém as regras a serem aplicadas aos pacotes transmitidos pelo próprio firewall. | ||
+ | * '''FORWARD:''' contém as regras a serem aplicadas aos pacotes em trânsito pelo firewall (isto é, pacotes recebidos de uma interface e sendo encaminhados através de outra interface). | ||
+ | |||
+ | [[imagem:Iptables-fluxo-filter.png]] | ||
+ | |||
+ | |||
+ | Assim, usando-se o iptables podem ser adicionadas regras a cada uma dessas ''chains'', dependendo do policiamento de tráfego a ser implantado no firewall. | ||
+ | |||
+ | |||
+ | [[imagem:Iptables-chains.png|400px]] | ||
+ | |||
+ | |||
+ | Uma regra deve especificar basicamente três coisas: | ||
+ | * '''Chain''': em que ''chain'' deve ser adicionada. | ||
+ | * '''Seletor:''' informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada. | ||
+ | * '''Alvo (''target''):''' ação a ser executada sobre o pacote que ativar a regra. | ||
+ | |||
+ | Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80: | ||
+ | |||
+ | |||
+ | [[imagem:Iptables-intro.png]] | ||
+ | |||
+ | |||
+ | Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]. | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Opção | ||
+ | !Descrição | ||
+ | !Exemplo | ||
+ | |- | ||
+ | | -s IP[/Mascara] || endereço IP de origem|| -s 200.135.37.64/26 | ||
+ | |- | ||
+ | | -d IP[/Mascara] || endereço IP de destino|| -d 8.8.8.8 | ||
+ | |- | ||
+ | | -p Protocolo || protocolo de transporte (tcp ou udp) || -p tcp | ||
+ | |- | ||
+ | | --dport numero || Port de destino || --dport 80 | ||
+ | |- | ||
+ | | --sport numero || Port de origem || --sport 53 | ||
+ | |- | ||
+ | | --syn || Se flag SYN está acesa (somente TCP) || | ||
+ | |- | ||
+ | | --tcp-flags Flags1 Flags2 || Se somente as flags listadas em Flags1 estão acesas dentre as Flags2 || --tcp-flags SYN,ACK,RST,FIN SYN | ||
+ | |- | ||
+ | | -i interface || Se pacote foi recebido pela interface || -i eth0 | ||
+ | |- | ||
+ | | -o interface || Se pacote vai sair pela interface || -o eth1 | ||
+ | |- | ||
+ | | -m state --state ESTADO || Identifica o estado do fluxo, o qual pode ser:<br>NEW: início de um fluxo<br>ESTABLISHED: parte de um fluxo estabelecido<br>RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente || -m state --state NEW,RELATED | ||
+ | |} | ||
+ | |||
+ | |||
+ | Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo: | ||
+ | |||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !Alvo | ||
+ | !Descrição | ||
+ | !Exemplo | ||
+ | |- | ||
+ | | ACCEPT || aceita o pacote|| -j ACCEPT | ||
+ | |- | ||
+ | | DROP || descarta o pacocte || -j DROP | ||
+ | |- | ||
+ | | REJECT || rejeita o pacote, devolvendo um código de erro ICMP para seu remetente || -j REJECT | ||
+ | |- | ||
+ | |LOG || registra o pacote no log do sistema || -j LOG | ||
+ | |- | ||
+ | |uma_chain || passa o pacote para ser processado pela chain uma_chain || -j rede_interna | ||
+ | |} | ||
+ | |||
+ | '''Exemplos''' | ||
+ | |||
+ | # Alterar política da ''chain'' FORWARD para DROP: <code> iptables -P FORWARD DROP </syntaxhighlight> | ||
+ | # Apagar a terceira regra da ''chain'' INPUT: <code> iptables -D INPUT 3 </syntaxhighlight> | ||
+ | # Apagar todas as regras de uma ''chain'' específica: <code> iptables -F INPUT </syntaxhighlight> | ||
+ | # Apagar todas as regras de todas as ''chains'': <code> iptables -F </syntaxhighlight> | ||
+ | # Visualização em tempo real do uso das regras das ''chains'': <code> watch iptables -L -v </syntaxhighlight> | ||
+ | |||
+ | === Salvando e restaurando regras do iptables === | ||
+ | |||
+ | Uma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles: | ||
+ | * '''iptables-save''': escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: <syntaxhighlight lang=bash> | ||
+ | iptables-save > minhas_regras | ||
+ | </syntaxhighlight> | ||
+ | * '''iptables-restore''': instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: <syntaxhighlight lang=bash> | ||
+ | iptables-restore < minhas_regras | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === Atividade === | ||
+ | |||
+ | Cada aluno deve implantar a seguinte rede virtual em seu computador utilizando a máquina virtual 1-Grafico para ser o PC e a máquina 1-Servidor para ser o Firewall: | ||
+ | |||
+ | |||
+ | [[imagem:Lab-firewall-intro.png]] | ||
+ | |||
+ | |||
+ | Inicie as máquinas virtuais, certificando-se de que suas interfaces de rede estejam em modo bridge. Configure os endereços IP de suas interfaces e também suas rotas default. | ||
+ | |||
+ | #Configure seu servidor como roteador. | ||
+ | #Configure no Ubuntu Gráfico como roteador padrão seu servidor. | ||
+ | #Instale o iptables. <syntaxhighlight lang=text> | ||
+ | apt-get install iptables </syntaxhighlight> | ||
+ | #Configure uma regra que impeça seu cliente (Ubuntu Gráfico) de acessar qualquer porta da máquina www.ifsc.edu.br. <syntaxhighlight lang=text>iptables -A FORWARD -d www.ifsc.edu.br -j DROP</syntaxhighlight> | ||
+ | #Repita a regra, mas agora mandando um aviso ao cliente. <syntaxhighlight lang=text>iptables -A FORWARD -d www.ifsc.edu.br -j REJECT</syntaxhighlight> | ||
+ | #Proíba o seu cliente de fazer ping para qualquer máquina, liberando todos os demais serviços. | ||
+ | ##Limpando todas as regras: <syntaxhighlight lang=text> iptables -F</syntaxhighlight> | ||
+ | ##Bloqueando o ping: <syntaxhighlight lang=text>iptables -A FORWARD -p icmp --icmp-type echo-request -j DROP</syntaxhighlight> | ||
+ | #Limpe as regras anteriores.<syntaxhighlight lang=text> iptables -F</syntaxhighlight> | ||
+ | #Permita que seu cliente acesse qualquer máquina na porta 80, mas somente nesta porta.<syntaxhighlight lang=text>iptables -A FORWARD -p tcp --dport 80 -j ACCEPT</syntaxhighlight> | ||
+ | #Limpe todas as regras. | ||
+ | #Mude a política para DROP e permita que o seu cliente acesse somente www.ifsc.edu.br. | ||
+ | #De seu cliente, faça um ataque do tipo ''ping of death'' em seu servidor: <syntaxhighlight lang=text> | ||
+ | ping -f 192.168.3.1X </syntaxhighlight> | ||
+ | #Iniba ataques do tipo ''ping of death'' na chain INPUT do seu servidor. | ||
+ | #Teste novamente com seu cliente e tente perceber a diferença no comportamento dos dois ataques. | ||
+ | |||
+ | OBS.: Não esquecer de prever regras de retorno!!! | ||
+ | |||
+ | |||
+ | '''Como configurar o cenário''' | ||
+ | |||
+ | |||
+ | Na máquina Servidor executar os seguintes comandos: | ||
+ | |||
+ | 1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua eth0: | ||
+ | 2 - Configurar esta interface de rede conforme abaixo: <syntaxhighlight lang=text> sudo ifconfig eth1 10.1.X.Y/24</syntaxhighlight> | ||
+ | 3 - Tornar uma máquina Linux roteador:<syntaxhighlight lang=text>echo 1 > /proc/sys/net/ipv4/ip_forward </syntaxhighlight> | ||
+ | 4 - Ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): <syntaxhighlight lang=text>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE</syntaxhighlight> | ||
+ | |||
+ | |||
+ | Na máquina Gráfico executar os seguintes comandos: | ||
+ | |||
+ | 1 - Executar o comando <code>service network-manager stop</syntaxhighlight> | ||
+ | 2 - Configurar a interface de rede eth0 conforme abaixo: <syntaxhighlight lang=text> sudo ifconfig eth0 10.1.X.Z/24</syntaxhighlight> | ||
+ | 3 - Configurar uma rota default: <syntaxhighlight lang=text> sudo route add default gw 10.1.X.Y </syntaxhighlight> | ||
+ | |||
+ | {{collapse bottom | Firewall}} | ||
+ | |||
+ | ==Aula 24 - 10/06/16: Firewall - continuação== | ||
+ | {{collapse top | Firewall - continuação}} | ||
+ | |||
+ | ===Atividade=== | ||
+ | |||
+ | 1 - Conclusão da atividade iniciada aula passada; | ||
+ | |||
+ | 2 - Atividade '''Valendo nota!!!''' | ||
+ | |||
+ | Cada grupo deve estudar quais regras de firewall querem implementar em seu cenário. Após isso, devem ser implementadas e testadas tais regras. Também deverão existir algumas regras pré determinadas: | ||
+ | |||
+ | #O acesso SSH deve ser permitido somente no Servidor 1 (Firewall) tanto via rede interna como via rede externa, porém via rede externa deve ser usada uma porta diferente da 22; | ||
+ | #Para acessar o Servidor 2 via SSH é necessário acessar primeiramente o Servidor 1 e depois acessar o Servidor 2 via rede interna. Ou seja, o acesso via SSH ao Servidor 2 não é permitido via rede externa diretamente; | ||
+ | #O acesso ao DNS deve ser permitido; | ||
+ | #O acesso ao servidor Apache instalado no Servidor 2 deve ser permitido tanto via rede interna como externa; | ||
+ | #Criar no mínimo uma regra em cada ''chain'' da tabela ''filter''; | ||
+ | #Não esquecer de tornar todas as regras permanentes no Servidor 1. | ||
+ | |||
+ | Cada grupo deverá gerar um relatório especificando tudo que foi implementado em relação ao firewall em seu servidor. Além disso, devem ser detalhadas todas as demais configurações que foram necessárias para que o cenário com firewall fosse desenvolvido (como roteamento, NAT, configuração de rede local). | ||
+ | |||
+ | Deverá ser entregue um '''relatório em formato PDF''' contendo o máximo possível de informações a respeito do cenário montado, explicação e justificativa das regras criadas, logs e prints que sejam necessários para a demonstração da configuração e funcionamento. | ||
+ | |||
+ | '''Data de entrega:''' 17/06/2016 | ||
+ | |||
+ | {{collapse bottom}} | ||
+ | |||
+ | ==Aula 25 - 14/06/16: Firewall - continuação== | ||
+ | {{collapse top | Firewall - continuação}} | ||
+ | |||
+ | ===Atividade - '''Valendo nota!!!'''=== | ||
+ | |||
+ | [[Imagem:Trab_firewall.png|600px]] | ||
+ | |||
+ | |||
+ | Cada grupo deve estudar quais regras de firewall querem implementar no cenário apresentado acima. Após isso, devem ser implementadas e testadas tais regras. Também deverão existir algumas regras pré determinadas: | ||
+ | |||
+ | #O acesso SSH deve ser permitido somente no Servidor 1 (Firewall) tanto via rede interna como via rede externa, porém via rede externa deve ser usada uma porta diferente da 22; | ||
+ | #Para acessar o Servidor 2 via SSH é necessário acessar primeiramente o Servidor 1 e depois acessar o Servidor 2 via rede interna. Ou seja, o acesso via SSH ao Servidor 2 não é permitido via rede externa diretamente; | ||
+ | #O acesso ao DNS deve ser permitido; | ||
+ | #O acesso ao servidor Apache instalado no Servidor 2 deve ser permitido tanto via rede interna como externa; | ||
+ | #Criar no mínimo uma regra em cada ''chain'' da tabela ''filter''; | ||
+ | #Não esquecer de tornar todas as regras permanentes no Servidor 1. | ||
+ | |||
+ | |||
+ | Cada grupo deverá gerar um relatório especificando tudo que foi implementado em relação ao firewall em seu servidor. Além disso, devem ser detalhadas todas as demais configurações que foram necessárias para que o cenário com firewall fosse desenvolvido (como roteamento, NAT, configuração de rede local). | ||
+ | |||
+ | Deverá ser entregue um '''relatório em formato PDF''' contendo o máximo possível de informações a respeito do cenário montado, explicação e justificativa das regras criadas, logs e prints que sejam necessários para a demonstração da configuração e funcionamento. | ||
+ | |||
+ | '''Data de entrega:''' 21/06/2016 | ||
+ | |||
+ | |||
+ | '''Como configurar o cenário''' | ||
+ | |||
+ | |||
+ | - Na máquina Servidor 1 executar os seguintes itens: | ||
+ | |||
+ | |||
+ | 1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua eth0: | ||
+ | 2 - Configurar esta interface de rede conforme abaixo: <syntaxhighlight lang=text> sudo ifconfig eth1 10.1.X.Y/24</syntaxhighlight> | ||
+ | 3 - Tornar uma máquina Linux roteador:<syntaxhighlight lang=text>echo 1 > /proc/sys/net/ipv4/ip_forward </syntaxhighlight> | ||
+ | 4 - Ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): <syntaxhighlight lang=text>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE</syntaxhighlight> | ||
+ | |||
+ | 5 - Instalar o SSH server, caso ainda não esteja instalado; | ||
+ | |||
+ | 6 - Fazer os redirecionamentos de porta necessários. | ||
+ | |||
+ | |||
+ | - Na máquina Servidor 2 executar os seguintes itens: | ||
+ | |||
+ | |||
+ | 1 - Configurar a interface de rede eth0 conforme abaixo: <syntaxhighlight lang=text> sudo ifconfig eth0 10.1.X.Z/24</syntaxhighlight> | ||
+ | 2 - Configurar uma rota default: <syntaxhighlight lang=text> sudo route add default gw 10.1.X.Y </syntaxhighlight> | ||
+ | 3 - Configurar o DNS como 200.135.37.65; | ||
+ | |||
+ | 4 - Instalar o SSH server, caso ainda não esteja instalado; | ||
+ | |||
+ | 5 - Instalar o servidor APACHE, caso ainda não esteja instalado. | ||
+ | |||
+ | |||
+ | - Na máquina PC executar os seguintes itens: | ||
+ | |||
+ | |||
+ | 1 - Configurar a interface de rede eth0 conforme abaixo: <syntaxhighlight lang=text> sudo ifconfig eth0 10.1.X.Z/24</syntaxhighlight> | ||
+ | 2 - Configurar uma rota default: <syntaxhighlight lang=text> sudo route add default gw 10.1.X.Y </syntaxhighlight> | ||
+ | 3 - Configurar o DNS como 200.135.37.65. | ||
+ | |||
+ | {{collapse bottom}} | ||
+ | |||
+ | ==Aula 26 - 17/06/16: Firewall - Conclusão da atividade== | ||
+ | |||
+ | ==Aula 27 - 21/06/16: Postfix== | ||
+ | {{collapse top | Postfix}} | ||
+ | |||
+ | O correio eletrônico (''email'') é um dos principais serviços na Internet. De fato foi o primeiro serviço a ser usado em larga escala. Trata-se de um método para intercâmbio de mensagens digitais. Os sistemas de correio eletrônico se baseiam em um modelo armazena-e-encaminha (''store-and-forward'') em que os servidores de email aceitam, encaminham, entregam e armazenam mensagens de usuários. | ||
+ | |||
+ | Uma mensagem de correio eletrônico se divide em duas partes: | ||
+ | * ''Cabeçalhos:'' contém informações de controle e atributos da mensagem | ||
+ | * ''Corpo:'' o conteúdo da mensagem | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | From: Roberto de Matos <roberto@eel.ufsc.br> | ||
+ | Content-Type: text/plain; | ||
+ | charset=iso-8859-1 | ||
+ | Content-Transfer-Encoding: quoted-printable | ||
+ | X-Smtp-Server: smtp.ufsc.br:roberto.matos@posgrad.ufsc.br | ||
+ | Subject: =?iso-8859-1?Q?Teste_Ger=EAncia?= | ||
+ | Message-Id: <0595A764-EEAE-41E7-99F0-80DC11FB5327@eel.ufsc.br> | ||
+ | X-Universally-Unique-Identifier: 684c3833-bbbe-420b-8b66-d92d9a419bc0 | ||
+ | Date: Wed, 20 Nov 2013 11:36:35 -0200 | ||
+ | To: Roberto de Matos <roberto.matos@ifsc.edu.br> | ||
+ | Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) | ||
+ | |||
+ | Ol=E1 Pessoal, | ||
+ | |||
+ | Hoje vamos aprender o funcionamento do Email!! | ||
+ | |||
+ | Abra=E7o, | ||
+ | |||
+ | Roberto= | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Na mensagem acima, os cabeçalhos são as linhas iniciais. Os cabeçalhos terminam quando aparece uma linha em branco, a partir de que começa o corpo da mensagem. | ||
+ | |||
+ | === Funcionamento do email === | ||
+ | |||
+ | Os componentes da infraestrutura de email são: | ||
+ | * ''MUA (Mail User Agent):'' o aplicativo que o usuário usa para envio e acesso a mensagens. Atualmente é bastante comum MUA do tipo webmail, mas existem outros como Mozilla Thunderbird, KMail e Microsoft Outlook. | ||
+ | * ''MDA (Mail Delivery Agent):'' o servidor responsável por receber dos usuários mensagens a serem enviadas. Assim, quando um usuário quer enviar uma mensagem, usa um MUA que contata o MDA para fazer o envio. Exemplos de software são Postfix, Sendmail, Qmail e Microsoft Exchange. | ||
+ | * ''MTA (Mail Transport Agent):'' o servidor responsável por transmitir mensagens até seu destino, e receber mensagens da rede para seus usuários. Comumente faz também o papel de MDA. Exemplos de softwares são Postfix, Sendmail, Qmail e Microsoft Exchange. | ||
+ | |||
+ | A figura abaixo ilustra uma infraestrutura de email típica. | ||
+ | |||
+ | [[Imagem:Email-intro.png]] | ||
+ | |||
+ | Os protocolos envolvidos são: | ||
+ | |||
+ | * ''SMTP (Simple Mail Transfer Protocol):'' usado para envios de mensagens entre MTAs, e entre MUA e MDA/MTA. | ||
+ | * ''IMAP (Internet Mail Access Protocol):'' usado por MUAs para acesso a mensagens armazenadas em caixas de email em servidores. | ||
+ | * ''POP (Post Office Protocol):'' mesma finalidade que IMAP, porém com funcionalidade mais limitada. Se destina a situações em que o normal é copiar as mensagens parao computador do usuário, e então removê-las do servidor. | ||
+ | |||
+ | |||
+ | Antes de implementar um serviço de correio eletrônico é importante que o administrador entenda como funciona a troca de mensagens, seja na Internet, seja em uma rede local. Para uma simples troca de mensagens entre dois usuários, pode ser necessária a utilização de vários protocolos e de várias aplicações. Será visto a seguir como isso acontece. | ||
+ | Um usuário que queira enviar uma mensagem para outro utilizará um aplicativo cliente de e-mail, também conhecido como MUA, ou Agente de Mensagens do Usuário. Ao terminar de redigir a sua mensagem o MUA enviará a mensagem a um MTA (Agente Transportador de Mensagens) que se encarregará então de entregar a mensagem ao MTA do destinatário, caso ele se encontre em outra máquina ou simplesmente colocar a mensagem na caixa postal do destinatário, caso ele se encontre no mesmo servidor. A transferência da mensagem entre o | ||
+ | MUA e o MTA se efetua utilizando um protocolo chamado SMTP ou Protocolo Simples de Transferência de Mensagens. O protocolo SMTP será utilizado também entre o MTA do remetente e o MTA do destinatário. O servidor de e-mail do destinatário, ao receber uma mensagem para um dos seus usuários, simplesmente a coloca na caixa postal deste usuário. Se o usuário possui uma conta shell neste servidor, ele poderá ler os seus e-mails direto no servidor, caso contrário o usuário deverá transferir suas mensagens para sua máquina a fim de lê-las com o seu cliente de e-mail. A transferência de mensagens recebidas entre o servidor e o cliente de e-mail requer a utilização de outros programas e protocolos. Usualmente é utilizado para este fim o protocolo POP, Protocolo de "Agência" de Correio, que recebe este nome por agir como uma agência de correios mesmo, que guarda as mensagens dos usuários em caixas postais e aguarda que estes venham buscar suas mensagens. Outro protocolo que pode ser utilizado para este mesmo fim é o IMAP, Protocolo para | ||
+ | Acesso de Mensagens via Internet, que implementa, além das funcionalidades fornecidas pelo POP, muitos outros recursos. Os protocolos POP e IMAP são protocolos para recebimentos de mensagens, ao contrário do protocolo SMTP, que serve para enviar mensagens, logo, possuem funcionalidades diferenciadas, como por exemplo, autenticação do usuário. Para a utilização dos protocolos POP e IMAP é necessária a instalação do servidor apropriado, que vai ser o responsável por atender as solicitações do cliente de e-mail por novas mensagens. O recebimento de mensagens pelo cliente se dá através da solicitação do MUA do usuário ao seu servidor de e-mail, que após a autenticação do usuário vai informar se existem mensagens em sua caixa postal e quantas são. A seguir o MUA solicita a transferência das mensagens para a máquina local, finalizando assim o processo de troca de mensagens entre dois usuários. A figura abaixo resume todo esse processo: | ||
+ | |||
+ | [[Imagem:postfix.png]] | ||
+ | |||
+ | === Endereçamento === | ||
+ | |||
+ | Endereços de email estão intimamente ligados ao DNS. Cada usuário de email possui um endereço único mundial, definido por um identificador de usuário e um domínio de email, escritos usando-se o símbolo especial ''@'' (lê-se ''at'', do original em inglês) para conectá-los: | ||
+ | |||
+ | tele@ifsc.edu.br | ||
+ | |||
+ | Nesse exemplo, o identificador de usuário é ''tele'', e o domínio é ''ifsc.edu.br''. | ||
+ | |||
+ | Os domínios de email tem correspondência direta com domínios DNS. De fato, para criar um domínio de email deve-se primeiro criá-lo no DNS. Além disto, o domínio DNS deve ter associado a si um ou mais registros MX (''Mail exchanger'') para apontar os MTAs responsáveis por receber emails para o domínio. Por exemplo, o domínio DNS ''ifsc.edu.br'' possui esse registro MX: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | > dig ifsc.edu.br mx | ||
+ | |||
+ | ;; QUESTION SECTION: | ||
+ | ;ifsc.edu.br. IN MX | ||
+ | |||
+ | ;; ANSWER SECTION: | ||
+ | ifsc.edu.br. 3581 IN MX 5 hermes.ifsc.edu.br. | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ... e o domínio ''gmail.com'': | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | > dig gmail.com mx | ||
+ | |||
+ | ;; QUESTION SECTION: | ||
+ | ;gmail.com. IN MX | ||
+ | |||
+ | ;; ANSWER SECTION: | ||
+ | gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. | ||
+ | gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. | ||
+ | gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. | ||
+ | gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. | ||
+ | gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. | ||
+ | </syntaxhighlight> | ||
+ | === MTA Postfix === | ||
+ | |||
+ | O primeiro software MTA usado em larga escala na Internet foi o [http://www.sendmail.org sendmail]. Esse MTA possui muitas funcionalidades, e enfatiza a flexibilidade em sua configuração. No entanto, configurá-lo e ajustá-lo não é tarefa fácil. Além disto, houve vários problemas de segurança no passado envolvendo esse software. Assim outras propostas surgiram, como [http://www.qmail.org qmail] e [http://www.postfix.org postfix]. Tanto ''qmail'' quanto ''postfix'' nasceram como projetos preocupados com a segurança nas operações de um MTA, e também se apresentaram como MTAs mais simples de configurar e operar. Em nossas aulas será usado o ''postfix'', mas recomenda-se experimentar usar as outras duas opcões citadas. | ||
+ | |||
+ | O ''postfix'' é um MTA modularizado, que divide as tarefas de processamento das mensagens em diversos componentes que rodam como processos separados. | ||
+ | |||
+ | * [http://www.postfix.org/OVERVIEW.html Visão geral do processamento de mensagens no postfix] | ||
+ | |||
+ | ==== Configuração ==== | ||
+ | |||
+ | * [http://help.ubuntu.com/community/Postfix Guia de instalação no Ubuntu] | ||
+ | |||
+ | A configuração do ''postfix'' é armazenada em arquivos, que normalmente residem no diretório ''/etc/postfix''. Os dois principais são: | ||
+ | |||
+ | * ''master.cf:'' configurações para execução dos subsistemas do Postfix (define que subsistemas estão ativados, quantas instâncias rodar de cada um, e seus argumentos de execução) | ||
+ | * ''main.cf:'' configurações usadas pelos subsistemas | ||
+ | |||
+ | No Ubuntu deve-se iniciar o uso do Postfix com esses comandos: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install -y postfix | ||
+ | |||
+ | # O comando abaixo deve ser usado se o postfix já foi instalado, mas deseja-se recriar sua configuração | ||
+ | dpkg-reconfigure postfix | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | As configurações iniciais informadas na instalação são suficientes para que o ''postfix'' possa ser iniciado. No entanto muitos detalhes provavelmente precisarão ser ajustados para que ele opere como desejado. | ||
+ | |||
+ | Para um rápido teste do ''postfix'' pode-se fazer a sequência abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | > sudo service postfix restart | ||
+ | > telnet localhost 25 | ||
+ | 220 ger ESMTP postfix (Ubuntu) | ||
+ | helo mail | ||
+ | 250 ger | ||
+ | mail from: aluno@ifsc.edu.br | ||
+ | 250 2.1.0 OK | ||
+ | rcpt to: postmaster@ger.edu.br | ||
+ | 250 2.1.5 OK | ||
+ | data | ||
+ | 354 End data with <CR><LF>.<CR><LF> | ||
+ | subject: Teste | ||
+ | |||
+ | blabla | ||
+ | . | ||
+ | 250 2.0.0 OK: queued as 71259CCA3 | ||
+ | quit | ||
+ | 221 2.0.0 Bye | ||
+ | Connection closed by foreign host | ||
+ | > | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O resultado do teste (a mensagem entreguepara o usuário ''postmaster'') pode ser visto no arquivo de log do ''postfix''. No Ubuntu esse arquivo é ''/var/log/mail.log'' : | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | > tail /var/log/mail.log | ||
+ | May 2 17:29:42 ger postfix/smtpd[1965]: 71259CCA3: client=localhost[127.0.0.1] | ||
+ | May 2 17:30:48 ger postfix/cleanup[1970]: 71259CCA3: message-id=<20100502202942.71259CCA3@ger> | ||
+ | May 2 17:30:48 ger postfix/qmgr[1894]: 71259CCA3: from=<aluno@ifsc.edu.br>, size=323, nrcpt=1 (queue active) | ||
+ | May 2 17:30:48 ger postfix/local[1972]: 71259CCA3: to=<root@ger.edu.br>, orig_to=<postmaster@ger.edu.br>, relay=local, delay=102, delays=102/0.05/0/0.03, dsn=2.0.0, status=sent (delivered to mailbox) | ||
+ | May 2 17:30:48 ger postfix/qmgr[1894]: 71259CCA3: removed | ||
+ | May 2 17:31:25 ger postfix/smtpd[1965]: disconnect from localhost[127.0.0.1] | ||
+ | > | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | A mensagem de teste foi entregue em ''/var/mail/root'': | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | > sudo cat /var/mail/root | ||
+ | From aluno@ifsc.edu.br Sun May 2 17:30:48 2010 | ||
+ | Return-Path: <aluno@ifsc.edu.br> | ||
+ | X-Original-To: postmaster@ger.edu.br | ||
+ | Delivered-To: postmaster@ger.edu.br | ||
+ | Received: from mail (localhost [127.0.0.1]) | ||
+ | by ger (Postfix) with SMTP id 71259CCA3 | ||
+ | for <postmaster@ger.edu.br>; Sun, 2 May 2010 17:29:06 -0300 (BRT) | ||
+ | Subject: teste | ||
+ | Message-Id: <20100502202942.71259CCA3@ger> | ||
+ | Date: Sun, 2 May 2010 17:29:06 -0300 (BRT) | ||
+ | From: aluno@ifsc.edu.br | ||
+ | To: undisclosed-recipients:; | ||
+ | |||
+ | blabla | ||
+ | |||
+ | </syntaxhighlight> | ||
+ | |||
+ | Outra maneira para testar e um pouco mais amigável é utilizar a ferramenta mail. Instale o pacote: | ||
+ | apt-get install mailutils | ||
+ | Para enviar uma mensagem proceda do seguinte modo:<code> | ||
+ | mail usuario@redesX.edu.br <Enter>, | ||
+ | inserir o subjet <Enter>, | ||
+ | inserir a mensagem, <Enter> | ||
+ | <Ctrl>+<d>. //Finaliza e encaminha o Email | ||
+ | </syntaxhighlight> | ||
+ | Verifique o encaminhamento ou não em: | ||
+ | tail -f /var/log/mail.log | ||
+ | |||
+ | === Instalação e testes com o Postfix === | ||
+ | |||
+ | # Em /etc/resolv.conf configurar: <code>nameserver 192.168.1.101</syntaxhighlight> | ||
+ | # Cada aluno terá um domínio com o seu nome no seguinte padrão: '''seu-nome.edu.br'''. Tenha certeza que seu serviço DNS esteja funcionando corretamente e você consiga acessar os domínios internos criados. <code> ping mail.seu-nome.edu.br </syntaxhighlight> | ||
+ | # Instale o postfix em sua máquina virtual: '''apt-get install postfix'''. Escolha '''Site Internet''' e nome como '''mail.redesX.edu.br''', este nome deve ser '''exatamente''' igual ao declarado no serviço DNS, na definição MX. | ||
+ | # Configure-o para que se comunicar na Internet, criando o domínio de email ''seu-nome.edu.br''. Edite o arquivo '''/etc/postfix/main.cf''' e crie ou edite os seguintes parâmetros, deixando-os da seguinte forma:<syntaxhighlight lang=text> | ||
+ | myhostname = mail.seu-nome.edu.br | ||
+ | mydomain = seu-nome.edu.br | ||
+ | myorigin = $mydomain | ||
+ | inet_interfaces = all | ||
+ | inet_protocols = ipv4 | ||
+ | mynetworks = 192.168.1.0/24, 127.0.0.0/8 | ||
+ | mynetworks_style = subnet | ||
+ | mydestination = $myhostname, $mydomain</syntaxhighlight> | ||
+ | # Reinicie o serviço: '''service postfix restart'''. | ||
+ | # Verifique se o servidor "subiu" corretamente: '''tail /var/log/syslog'''. | ||
+ | # Verifique se não houve erros de configuração: '''tail -n 30 /var/log/mail.log'''. | ||
+ | # Caso tudo esteja correto, teste o envio de e-mail usando o telnet: <code>telnet seu-nome.edu.br 25 </syntaxhighlight> | ||
+ | ##Converse com o servidor de e-mails: <code>helo mail | ||
+ | 250 mail.seu-nome.edu.br | ||
+ | mail from: qualquer@qualquer | ||
+ | 250 2.1.0 OK | ||
+ | rcpt to: usuario@seu-nome.edu.br | ||
+ | 250 2.1.5 OK | ||
+ | data | ||
+ | 354 End data with <CR><LF>.<CR><LF> | ||
+ | |||
+ | Subject: Teste - AlunoX | ||
+ | |||
+ | Testando o envio de uma mensagem na manualmente ... | ||
+ | |||
+ | . | ||
+ | 250 2.0.0 Ok: queued as 57C486819C | ||
+ | quit | ||
+ | 221 2.0.0 Bye</syntaxhighlight> | ||
+ | # Verifique se o email foi perfeitamente encaminhado procurando pela string ''sent'' no '''/var/log/mail.log'''. | ||
+ | # Instale um cliente de Email: '''apt-get install mailutils''' | ||
+ | # Envie um email:<syntaxhighlight lang=text> | ||
+ | mail usuario@seu-nome.edu.br | ||
+ | Cc: | ||
+ | Subject: Teste de email | ||
+ | Isto é somente um teste... | ||
+ | ... para sair, em uma linha em branco digite: CTRL d | ||
+ | </syntaxhighlight> | ||
+ | # Verifique se o email foi perfeitamente encaminhado procurando pela string ''sent'' no '''/var/log/mail.log'''. | ||
+ | # Para ler email, logado com o usuário desejado, execute o comando '''mail''' e digite o número da mensagem desejada. | ||
+ | # Teste o envio de mensagens para usuários dos domínios de seus colegas. Acompanhe o processamento das mensagens olhando o log. | ||
+ | # Crie um grupo de email com pelo menos três usuários, envie uma mensagem para o grupo e verifique se todos os usuários cadastrados no grupo receberam tal mensagem. | ||
+ | |||
+ | === Dicas === | ||
+ | |||
+ | Atenção para vários problemas comuns na implantação do correio eletrônico: | ||
+ | * ''Domínio DNS sem registro MX'': sem isso os MTAs não sabem como enviar mensagens para esse domínio | ||
+ | * ''Registro MX aponta um nome de host desconhecido:'' causa o mesmo problema acima | ||
+ | * ''Nome de host configurado como localhost no Postfix:'' o nome de host (parâmetro ''myhostname'' em /etc/postfix/main.cf) deve ser o nome DNS do servidor onde roda o Postfix. | ||
+ | * ''Erros de configuração (sintaxe) em /etc/postfix/main.cf'': tais erros podem fazer com que um dos subsistemas do Postfix aborte sua execução, impedindo que se processe uma mensagem. Por exemplo, se um parâmetro usado pelo subsistema ''smtpd'' (que recebe mensagens com protocolo SMTP) estiver errado, o ''smtpd'' não iniciam, ou termina abruptamente, abortando a recepção de mensagens. | ||
+ | Passo a passo para criar uma aliases (apelidos/grupos): | ||
+ | #Adicione as diretivas para criação de grupos:<code> | ||
+ | vi /etc/postfix/main.cf | ||
+ | alias_maps = hash:/etc/postfix/aliases | ||
+ | alias_database = hash:/etc/postfix/aliases</syntaxhighlight> | ||
+ | #Crie os grupos e adicione os respectivos usuários, por exemplo:<code> | ||
+ | vi /etc/postfix/aliases | ||
+ | todos: root, aluno | ||
+ | batman: aluno</syntaxhighlight> | ||
+ | #Execute o comando para criação da base de grupos:<code> | ||
+ | postalias /etc/postfix/aliases</syntaxhighlight> | ||
+ | #Reinicie o serviço: <code> | ||
+ | service postfix reload </syntaxhighlight> | ||
+ | #Teste os apelidos enviando email para '''todos''' e '''batman''' e verifique quais usuários (root e/ou aluno) receberam as respectivas mensagens. | ||
+ | |||
+ | {{collapse bottom}} | ||
+ | |||
+ | ==Aula 28 - 24/06/16: POP e IMAP== | ||
+ | |||
+ | {{collapse top | POP e IMAP}} | ||
+ | |||
+ | Na Aula 17 instalamos e testamos o Servidor de e-mail Postfix. Com ele pudemos testar o envio de e-mails utilizando o protocolo SMTP. | ||
+ | |||
+ | Agora queremos, também, instalar e testar o acesso dos usuários às suas caixas de e-mail. Para isso, é necessário os protocolos POP3 e IMAP. Com estes dois protocolos poderemos acessar as contas de e-mails dos usuários tanto com clientes instalados na máquina (Mozilla Thunderbird, Outlook Express, etc) como através de Webmails. | ||
+ | |||
+ | ===Instalação POP/IMAP e testes=== | ||
+ | |||
+ | Executar os passos seguintes nas máquinas virtuais. Utilizaremos a máquina virtual server para instalar os serviços e a cliente para configurar os clientes de e-mail e demais testes. | ||
+ | |||
+ | #Checar se a rede está OK; | ||
+ | #Testar se o domínio seu-nome.edu.br está OK; | ||
+ | #O servidor Postfix deve estar devidamente configurado (aula anterior); | ||
+ | # Pacotes para gerência de usuários do Postfix <syntaxhighlight lang=bash> | ||
+ | apt-get install postfix-ldap postfix-mysql | ||
+ | </syntaxhighlight> | ||
+ | #Configurando caixa de e-mail dos usuários <syntaxhighlight lang=bash> | ||
+ | postconf -e 'home_mailbox=Maildir/' | ||
+ | </syntaxhighlight> | ||
+ | #Criando usuário de e-mail: cada usuário de e-mail deve ter um usuário criado na máquina servidora do Postfix <syntaxhighlight lang=bash> | ||
+ | adduser usuárioX | ||
+ | </syntaxhighlight> | ||
+ | #Criando os diretórios onde ficarão as caixas de e-mails de cada usuário <syntaxhighlight lang=bash> | ||
+ | mkdir /home/usuario/Maildir | ||
+ | mkdir /home/usuario/Maildir/cur | ||
+ | mkdir /home/usuario/Maildir/new | ||
+ | mkdir /home/usuario/Maildir/tmp | ||
+ | </syntaxhighlight> | ||
+ | #Mudar dono e grupo dos diretórios <syntaxhighlight lang=bash> | ||
+ | chown usuario:grupo /home/usuario/Maildir | ||
+ | chown usuario:grupo /home/usuario/Maildir/cur | ||
+ | chown usuario:grupo /home/usuario/Maildir/new | ||
+ | chown usuario:grupo /home/usuario/Maildir/tmp | ||
+ | </syntaxhighlight> | ||
+ | # Instalar Servidor POP <syntaxhighlight lang=bash> | ||
+ | apt-get install courier-pop | ||
+ | </syntaxhighlight> | ||
+ | #Configurar Thunderbird com POP e testar envio e recebimento de e-mail; | ||
+ | # Instalar Servidor IMAP <syntaxhighlight lang=bash> | ||
+ | apt-get install courier-imap | ||
+ | </syntaxhighlight> | ||
+ | #Configurar Thunderbird com IMAP e testar envio e recebimento de e-mail. | ||
+ | |||
+ | {{collapse bottom | POP e IMAP}} | ||
+ | |||
+ | {{collapse top | Recuperação Avaliação 2}} | ||
+ | |||
+ | Esta é uma atividade de recuperação extra para aqueles que não atingiram a média na Avaliação 2 (DNS, Apache e FTP). A nota desta atividade será somada a nota tirada na Avaliação 2 (dia 03/06) e feito a média aritmética das duas. Esta média substituirá a nota tirada na Avaliação 2. | ||
+ | |||
+ | Os alunos devem atender aos seguintes pontos: | ||
+ | |||
+ | #Refazer a [[Media:Prova-prática-02.pdf | prova prática]]; | ||
+ | #Demonstrar o correto funcionamento das configurações para a professora; | ||
+ | #Gerar um relatório em formato PDF para ser entregue até dia 28/06 contendo: | ||
+ | ##Descrição das configurações feitas; | ||
+ | ##Descrição dos testes realizados para comprovação de funcionamento; | ||
+ | ##Prints, logs ou outros que comprovem o correto funcionamento dos serviços ativados. | ||
+ | |||
+ | {{collapse bottom | Recuperação Avaliação 2}} | ||
+ | |||
+ | ==Aula 29 - 28/06/16: Atividades de preparação para a Avaliação 3== | ||
+ | |||
+ | {{Collapse top | Atividades }} | ||
+ | |||
+ | ===Atividade sobre firewall com iptables=== | ||
+ | |||
+ | Para esta atividade se utilizará a rede apresentada na figura abaixo: | ||
+ | |||
+ | [[Arquivo:Atividade_firewall.png|600px]] | ||
+ | |||
+ | |||
+ | '''Protocolos e portas a serem utilizadas''' | ||
+ | |||
+ | # DNS: protocolo UDP e porta 53; | ||
+ | # SMTP: protocolo TCP e porta 25; | ||
+ | # HTTP: protocolo TCP e porta 80; | ||
+ | # HTTPS: protocolo TCP e porta 443; | ||
+ | # SSH: protocolo TCP e porta 22. | ||
+ | |||
+ | |||
+ | '''Atividade''' | ||
+ | |||
+ | #Configurar a rede adequadamente; | ||
+ | #PC1 e PC2 utilizarão a máquina 192.168.1.101 como DNS; | ||
+ | #PC1 tem acesso SMTP e HTTP somente à máquina 192.168.1.101, porém não faz acesso SSH à ela; | ||
+ | #PC2 tem acesso a qualquer serviço na máquina 192.168.1.101; | ||
+ | #PC2 pode fazer acesso Web (HTTP e HTTPS) externo; | ||
+ | #A máquina firewall não aceita acesso via SSH da rede externa; | ||
+ | #A máquina firewall não faz acesso Web. | ||
+ | |||
+ | ===Atividade SMTP/POP/IMAP=== | ||
+ | |||
+ | Repetir as atividades propostas nas Aulas 27 e 28. | ||
+ | |||
+ | {{Collapse bottom | Atividades }} | ||
+ | |||
+ | ==Aula 30 - 01/07/16: Avaliação 3== | ||
+ | |||
+ | Na Aula 30 será feita apenas uma avaliação prática que abordará os seguintes itens: | ||
+ | |||
+ | #Firewall; | ||
+ | #Postfix; | ||
+ | #POP e IMAP. | ||
+ | |||
+ | No entanto, a nota da Avaliação 3 será composta da seguinte maneira: | ||
+ | |||
+ | #50% - Avaliação 3; | ||
+ | #50% - Relatório sobre regras de firewall. | ||
+ | |||
+ | |||
+ | ==Aula 31 - 05/07/16: Avaliação 3== | ||
+ | |||
+ | ==Aula 32 - 08/07/16: LAN Ethernet== | ||
+ | |||
+ | {{Collapse top | LAN }} | ||
+ | |||
+ | ===Local Area Network=== | ||
+ | |||
+ | |||
+ | LAN é um acrônimo para Local Area Network que em português é chamada de Rede de Área Local ou simplesmente Rede local. Por LAN define-se uma rede de computadores desenvolvida para cobrir regiões geograficamente pequenas, como escritórios, andares de um edifício ou até mesmo um edifício. Elas cobrem uma área geográfica de até 1 Km, acima disso são chamadas MAN (Metropolitan Área Network). A nível de enlace o padrão IEEE 802.3 (Ethernet) e o padrão IEEE 802.11 (Wi-Fi) são os mais utilizados. O padrão ethetnet e o Wi-Fi especificam a camada de enlace e a camada física de uma rede. | ||
+ | |||
+ | |||
+ | Em se tratando de camada física do padrão Ethernet, os principais padrões da Ethernet são para Fast Ethernet: | ||
+ | |||
+ | #100BASE-T -- Designação para qualquer dos três padrões para 100 Mbit/s ethernet sobre cabo de par trançado. | ||
+ | #100BASE-TX -- Usa dois pares, mas requer cabo cat-5. | ||
+ | #100BASE-T4 -- 100 Mbit/s ethernet sobre cabeamento cat-3 (Usada em instalações 10BASE-T). | ||
+ | #100BASE-FX -- 100 Mbit/s ethernet sobre fibra óptica. Usando fibra ótica multimodo 62,5 mícrons tem o limite de 400 metros. | ||
+ | |||
+ | |||
+ | E para Gigabit Ethernet: | ||
+ | |||
+ | #1000BASE-T -- 1 Gbit/s sobre cabeamento de cobre categoria 5e ou 6. | ||
+ | #1000BASE-SX -- 1 Gbit/s sobre fibra. | ||
+ | #1000BASE-LX -- 1 Gbit/s sobre fibra. Otimizado para distâncias maiores com fibra mono-modo. | ||
+ | |||
+ | |||
+ | A camada de enlace é a responsável pela transmissão e recepção (delimitação) de quadros e pelo controle de fluxo. Ela também estabelece um protocolo de comunicação entre sistemas diretamente conectados. Na rede ethernet cada placa de rede possui um endereço físico, que deve ser único na rede. Em redes do padrão IEEE 802 esta camada é dividida em outras duas camadas: Controle de ligação lógica (LLC), que fornece uma interface para camada superior (rede), e controle de acesso ao meio físico (MAC), que acessa diretamente o meio físico e controla a transmissão de dados. | ||
+ | |||
+ | |||
+ | Um ponto muito importante da camada de enlace é o endereçamento. Este endereçamento recebe o nome de endereçamento MAC e é um endereço físico associado à interface de comunicação, que conecta um dispositivo à rede. O MAC é um endereço “único”, não havendo duas portas com a mesma numeração, é usado para controle de acesso em redes de computadores. Sua identificação é gravada em hardware, isto é, na memória ROM da placa de rede de equipamentos como desktops, notebooks, roteadores, smartphones, tablets, etc. | ||
+ | |||
+ | |||
+ | O endereço MAC é formado por um conjunto de 6 bytes separados por dois pontos (“:”) ou hífen (“-”), sendo cada byte representado por dois algarismos na forma hexadecimal, como por exemplo: "'''00:19:B9:FB:E2:58'''". Cada algarismo em hexadecimal corresponde a uma palavra binária de quatro bits, desta forma, os 12 algarismos que formam o endereço totalizam 48 bits. | ||
+ | |||
+ | |||
+ | '''Padrão Ethernet''' | ||
+ | |||
+ | |||
+ | O padrão Ethernet foi inicialmente desenvolvido para funcionar a 10Mbps via cabo coaxial, onde todas as comunicações aconteciam em um mesmo fio. Assim, todas as máquinas conectadas a este cabo recebiam uma dada informação que era, na verdade, destinada a apenas uma máquina. A máquina destinatária utilizava a informação recebida e as demais máquinas simplesmente a descartavam. | ||
+ | |||
+ | Além desta forma de conexão representar um claro problema de segurança, um único cabo de comunicação compartilhado como este também fazia com que a largura de banda deste cabo fosse compartilhada com todas as máquinas a ele conectadas. Desta forma, o tráfego poderia se tornar bastante lento. | ||
+ | |||
+ | Neste tipo de conexão compartilhada também há disputa pelo acesso ao meio de transmissão o que pode acarretar em colisões entre dados transmitidos ao mesmo tempo entre duas máquinas diferentes. Quando colisões ocorrem os dados transmitidos pelas duas fontes são perdidos e necessitam ser retransmitidos. Para se minimizar a incidência de colisões este padrão utilizava técnicas de controle de acesso ao meio, onde cada máquina deveria determinadas regras para poder acessar o meio e transmitir suas informações. | ||
+ | |||
+ | Hoje a Ethernet funciona principalmente através de switches (ou comutador) com uma topologia não mais em barramento, mas em estrela onde o switch recebe todo o tráfego da rede e o encaminha. A principal vantagem de se usar uma rede Ethernet comutada é o isolamento dos domínios de colisão, causando menos colisão no meio compartilhado e melhorando o desempenho da rede como um todo. | ||
+ | |||
+ | Numa primeira fase (antes do switch saber quem tem ligado a ele), quando um switch recebe informação numa determinada porta, transmite esse mesma informação por todas as outras portas, excepto por aquela que recebeu essa informação (flood). No entanto, ao contrário dos Hubs, os switchs registam o endereço MAC dos dispositivos que estão ligados a cada porta do equipamento. Sempre que um equipamento envia uma frame (quadro), o switch analisa o endereço MAC de destino e comuta a frame para a porta onde se encontra a máquina de destino. Desta forma, numa rede Ethernet, o switch não necessita de propagar a informação por todas as portas, sendo esta directamente enviada (com base na informação da tabela MAC do switch) para a máquina de destino (FONTE: [[http://pplware.sapo.pt/microsoft/windows/redes-como-funciona-um-switch/]]). | ||
+ | |||
+ | |||
+ | O modelo de um quadro Ethernet é apresentado abaixo: | ||
+ | |||
+ | [[Imagem:quadroethernet.png|600px]] | ||
+ | |||
+ | |||
+ | '''Protocolo ARP''' | ||
+ | |||
+ | |||
+ | Address Resolution Protocol ou ARP é um protocolo usado para encontrar um endereço da camada de enlace de dados (Ethernet, por exemplo) a partir do endereço da camada de rede (como um endereço IP). O emissor difunde em broadcast um pacote ARP contendo o endereço IP de outro host e espera uma resposta com um endereço MAC respectivo. Cada máquina mantém uma tabela de resolução em cache para reduzir a latência e carga na rede. | ||
+ | |||
+ | |||
+ | '''Atividade''' | ||
+ | Desenvolver atividades utilizando o Switch TP-Link TL-SG3210 [[Arquivo:TL-SG3210 User Guide.pdf]][[Arquivo:TL-SG3210 CLI Reference Guide.pdf]] | ||
+ | |||
+ | |||
+ | '''VLAN''' | ||
+ | |||
+ | |||
+ | Uma rede local virtual, normalmente denominada de VLAN, é uma rede logicamente independente. Várias VLANs podem co-existir em um mesmo comutador (switch), de forma a dividir uma rede local (física) em mais de uma rede (virtual), criando domínios de broadcast separados. Uma VLAN também torna possível colocar em um mesmo domínio de broadcast, hosts com localizações físicas distintas e ligados a switches diferentes. Um outro propósito de uma rede virtual é restringir acesso a recursos de rede sem considerar a topologia da rede, porém este método é questionável e improvavel. | ||
+ | |||
+ | Redes virtuais operam na camada 2 do modelo OSI. No entanto, uma VLAN geralmente é configurada para mapear diretamente uma rede ou sub-rede IP, o que dá a impressão que a camada 3 está envolvida. Um exemplo de VLAN é dado abaixo: | ||
+ | |||
+ | |||
+ | [[Imagem:vlan.png |600px]] | ||
+ | |||
+ | |||
+ | O quadro Ethernet sofre uma alteração para incluir uma tag para identificação da VLAN e fica da forma abaixo: | ||
+ | |||
+ | [[Imagem:tagvlan.jpg |600px]] | ||
+ | |||
+ | '''Atividade''' | ||
+ | Desenvolver atividades utilizando o Switch TP-Link TL-SG3210 [[Arquivo:TL-SG3210 User Guide.pdf]][[Arquivo:TL-SG3210 CLI Reference Guide.pdf]] | ||
+ | |||
+ | {{Collapse bottom | LAN}} | ||
+ | |||
+ | ==Aula 33 - 12/07/16: IEEE802.11/Radius== | ||
+ | |||
+ | [http://slideplayer.com.br/slide/50794/] | ||
+ | [https://pt.wikipedia.org/wiki/IEEE_802.11] | ||
+ | |||
+ | {{Collapse top | Radius}} | ||
+ | |||
+ | ===Radius=== | ||
+ | |||
+ | '''Remote Authentication Dial In User Service''' (RADIUS) é um protocolo de rede que provê de forma centralizada autenticação, autorização e contabilização(Accounting em inglês) no processo de gerenciar computadores que estarão se conectando e usando um determinado serviço de rede. O protocolo RADIUS foi desenvolvido pela Livingston Enterprises, Inc., em 1991 para acesso a servidores de autenticação e protocolos de contabilização, sendo mais tarde introduzido como padrão do Internet Engineering Task Force (IETF).1 | ||
+ | |||
+ | Por causa do amplo apoio e da forte presença do protocolo RADIUS, ele é muito usado por ISP's nas empresas no gerenciamento de acesso a internet ou intranet, e também é integrado a serviços de e-mail. Algumas dessas redes podem incorporar o protocolo em suas implementações. Como por exemplo modens, DSL, ponto de acesso wireless, VPN's, servidores WEB e etc. 2 | ||
+ | |||
+ | RADIUS é um protocolo do tipo cliente/servidor que roda como um protocolo da camada de aplicação, usa como apoio o protocolo de transferência UDP. Tanto Servidores de Acesso Remoto(RAS), como servidores de Redes Virtuais Privadas(VPNs) e Servidores de Acesso a Rede(NAS), e todos os gateways que controlam o acesso a rede possuem um componente cliente do protocolo RADIUS que se comunica com o servidor RADIUS. Este servidor normalmente é um processo de background rodando no UNIX ou Microsoft Windows server.3 | ||
+ | |||
+ | |||
+ | O servidor RADIUS possui três funções básicas: | ||
+ | |||
+ | 1. autenticação de usuários ou dispositivos antes da concessão de acesso a rede. | ||
+ | |||
+ | 2. autorização de outros usuários ou dispositivos a usar determinados serviços providos pela rede. | ||
+ | |||
+ | 3. para informar sobre o uso de outros serviços. | ||
+ | |||
+ | |||
+ | O protocolo RADIUS é resumidamente, um serviço baseado em UDP de pergunta e resposta. As requisições e respostas seguem uma padrão de tabelas (variável=valor). | ||
+ | |||
+ | A variável não possui um nome e sim um número. A relação entre este número e seu nome é obtida através de dicionários. Exemplo de dicionário padrão: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | ATTRIBUTE User-Name 1 string | ||
+ | ATTRIBUTE Password 2 string | ||
+ | ATTRIBUTE CHAP-Password 3 string | ||
+ | ATTRIBUTE NAS-IP-Address 4 ipaddr | ||
+ | ATTRIBUTE NAS-Port-Id 5 intege | ||
+ | ATTRIBUTE Service-Type 6 integer | ||
+ | ATTRIBUTE Framed-Protocol 7 integer | ||
+ | ATTRIBUTE Framed-IP-Address 8 ipaddr | ||
+ | ATTRIBUTE Framed-IP-Netmask 9 ipaddr | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | O valor tem um tipo definido no dicionário, e os tipos comuns são: string, inteiro (numero), octeto ou ipaddr (endereço IP: 4 bytes) e tipo estendido (usado para transportar parâmetros personalizados de fabricantes de equipamentos). | ||
+ | |||
+ | O RADIUS tem uma porta para autenticação (UDP 1645 ou UDP 1812) e outra para contabilidade (UDP 1646 ou UDP 1813). | ||
+ | |||
+ | |||
+ | Numa rede que usa RADIUS, há funções distintas para os equipamentos: | ||
+ | |||
+ | '''Cliente:''' é o host que deseja usufruir de um recurso da rede, como por exemplo, uma estação que deseja se associar a um Access Point. | ||
+ | |||
+ | |||
+ | '''NAS (Network Autentication Server):''' é o host que recebe uma solicitação do cliente (o Access Point por exemplo) e autentica esse pedido no servidor RADIUS. | ||
+ | |||
+ | |||
+ | '''Servidor RADIUS:''' é o host que validará o pedido do NAS. A resposta do pedido de autenticação pode ser positiva (Access-Accept) acompanhada da tabela de parâmetros de resposta ou negativa (Access-Reject) sem nenhum parâmetro. | ||
+ | |||
+ | |||
+ | Nas respostas positivas (Access-Accept) os parâmetros de resposta são usados para orientar o NAS de como tratar o cliente. | ||
+ | Numa rede wireless, nos parâmetros podem constar por exemplo, o tempo máximo de conexão permitida, ou a chave de criptografia que deverá ser usada no canal de comunicação entre o cliente e o NAS. | ||
+ | |||
+ | |||
+ | O serviço RADIUS é amplamente usado em provedores de acesso a internet. No Brasil por exemplo, a Oi (empresa de telecomunicações) usa RADIUS no seu produto ADSL chamado Velox. No sistema Velox, o cliente inicia um pedido de conexão via protocolo PPPoE, um roteador Cisco série 7000 atende o pedido e envia o nome de usuário e senha para o servidor RADIUS (localizado num datacenter no Rio de Janeiro), o RADIUS por sua vez confere as credênciais em seu banco de dados e retorna para o roteador se o cliente pode se conectar ou não. Se a resposta for positiva, o cliente receberá um IP público e poderá navegar, caso a resposta seja negativa, o acesso é negado. | ||
+ | |||
+ | ===Atividade=== | ||
+ | |||
+ | O Radius pode ser utilizado com um banco de dados LDAP, para que o mesmo busque usuário e senha ou pode-se usar o arquivo de texto '''users''' da mesma forma determinando usuário e senha. Utilizaremos o arquivo de texto '''users''' devido a facilidade de implementar. | ||
+ | |||
+ | Procedimento no AP (Access Point) '''Edimax''': | ||
+ | #Acesse o AP via browser, após o reset,o IP padrão do AP é 192.168.2.1, usuário admin, senha 1234. | ||
+ | #Na aba '''Security''' configure: <code> | ||
+ | Encryption: WPA RADIUS | ||
+ | Radius IP Server: 192.168.2.X | ||
+ | RADIUS Server Password: 1234 </syntaxhighlight> | ||
+ | #Configure seu AP para um novo IP padrão, caso necessário. | ||
+ | #Configure como ''default gateway'' do AP o 192.168.2.X (servidor da equipe). | ||
+ | #Habilite o DHCP Server (''System Utility'') com os seguintes parâmetros: <code> | ||
+ | Default Gateway IP: 192.168.2.X | ||
+ | Domain Name Server IP: 200.135.37.65 | ||
+ | Start IP: definir IP | ||
+ | End IP: definir IP </syntaxhighlight> | ||
+ | #Configure o SSID do AP com o nome da equipe, '''Basic Setting''' - '''ESSID''': '''equipe1''' ou '''equipe2''' ou '''equipe3'''. | ||
+ | #Clique em '''Apply''' - '''Apply''', para salvar e reiniciar o AP. | ||
+ | #O acesso direto ao AP será perdito caso tenha sido alterado o seu IP! | ||
+ | #Conecte o AP no mesmo switch do servidor. | ||
+ | |||
+ | Procedimento deve ser realizado (pela equipe) no servidor caso ainda não esteja feitos todos os pontos: | ||
+ | #Configure o servidor para repasse de pacotes: <code> | ||
+ | echo 1 > /proc/sys/net/ipv4/ip_forward </syntaxhighlight> | ||
+ | #Configure o NAT no servidor <code> | ||
+ | iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE </syntaxhighlight> | ||
+ | #Instale o pacote: <code> | ||
+ | apt-get update | ||
+ | apt-get install freeradius </syntaxhighlight> | ||
+ | #Crie no servidor um IP alias compatível com o IP do AP, por exemplo, 192.168.2.X. | ||
+ | #Após isso é necessário a configuração de dois arquivos o <tt>/etc/freeradius/clients.conf</tt>, arquivo onde é cadastrado os equipamentos que irão se conectar a rede (cada switch e AP terão seus dados cadastrados neste formato). Acrescente ao final do arquivo (XX é o IP do AP): <code> | ||
+ | client 192.168.2.X { | ||
+ | ipaddr = 192.168.2.X | ||
+ | shortname = nome_ficticio_do_AP | ||
+ | secret = 1234 | ||
+ | nastype = other | ||
+ | } </syntaxhighlight> | ||
+ | #e <tt>/etc/freeradius/users</tt>, arquivo onde é cadastrado os usuários que podem se conectar a rede, é necessário determinar dentro do users o login e senha que será utilizado por cada usuário: <code> | ||
+ | login Cleartext-Password :="senha"</syntaxhighlight> | ||
+ | ##O login e senha que estão acima serão os respectivos login e senha do usuário para que o mesmo possa se autenticar na rede cabeada ou sem fio. | ||
+ | #No arquivo <tt>/etc/freeradius/radiusd.conf</tt> deixe a configuração de logs da seguinte forma:<code> | ||
+ | log { | ||
+ | destination = files | ||
+ | file = ${logdir}/radius.log | ||
+ | syslog_facility = daemon | ||
+ | stripped_names = no | ||
+ | auth = yes | ||
+ | auth_badpass = yes | ||
+ | auth_goodpass = no | ||
+ | }</syntaxhighlight> | ||
+ | #Como root, reinicie o serviço: <code> | ||
+ | service freeradius restart </syntaxhighlight> | ||
+ | #Execute o comando <code> tail -f /var/log/freeradius/radius.log</syntaxhighlight> | ||
+ | #e em outro console (qualquer usuário): <code> | ||
+ | radtest <usuário> <senha> <servidor> <porta> <senha_cliente> </syntaxhighlight> | ||
+ | #Pode-se verificar os logs em '''/var/log/freeradius/radius.log'''. | ||
+ | |||
+ | {{Collapse bottom | Radius}} | ||
+ | |||
+ | ==Aula 34 - 15/07/16: ADSL e PPPoE== | ||
+ | |||
+ | {{collapse top | PPPoE}} | ||
+ | |||
+ | === PPPoE (PPP over Ethernet) === | ||
+ | |||
+ | PPPoE define um método para encapsular quadros PPP dentro de quadros Ethernet, e foi definido na [http://www.faqs.org/rfcs/rfc2516.html RFC 2516]. Ele foi criado para facilitar a integração de usuários discados e banda-larga em provedores de acesso (ISP - ''Internet Service Providers''). Além disso, torna mais fácil o controle de acesso, de uso da rede, e contabilização para usuários que a acessam via rede Ethernet. Assim, é possível implantar uma rede em que os usuários, para conseguirem acesso, precisam se autenticar como em um serviço discado. Uma vez obtido o acesso, pode-se também impor limitações de uso de banda de acordo com o usuário. Exemplos de infraestruturas que podem se beneficiar com essa técnica são redes de condomínios e de prédios comerciais. Finalmente, PPPoE é usado como protocolo de enlace em acessos aDSL, ilustrado na figura abaixo. | ||
+ | |||
+ | [[imagem:Pppoe_architecture.gif]] | ||
+ | |||
+ | |||
+ | No PPPoE suas PDUs são encapsuladas em quadros Ethernet, usando o ''ethertype'' 8863H (estágio de descoberta) ou 8864H (estágio de sessão). Devido ao cabeçalho PPPoE (6 bytes) combinado ao identificador de protocolo do quadro PPP (2 bytes), a MTU em enlaces PPPoE não pode ser maior que 1492 bytes. O quadro PPP é simplificado, não possuindo as flags delimitadoras e os campos ''Address'', ''Control'' e ''FCS''. A PDU PPPoE é mostrada a seguir: | ||
+ | |||
+ | |||
+ | [[imagem:Pppoe-pdu.png|800px]] | ||
+ | |||
+ | |||
+ | |||
+ | Em um enlace PPPoE um dos nodos é o ''host'' (cliente), e o outro o concentrador de acesso (AC, que tem papel de servidor). O estabelecimento do enlace é iniciado pelo ''host'', que procura um AC e em seguida solicita o início do enlace. Esse procedimento é composto por por dois estágios: | ||
+ | * '''Descoberta (''Discovery''):''' o cliente descobre um concentrador de acesso (AC) para se conectar. Ocorre uma troca de 4 PDUs de controle: | ||
+ | ** ''PADI (PPPoE Active Discovery Indication):'' enviado em broadcast pelo cliente para descobrir os AC. | ||
+ | ** ''PADO (PPPoE Active Discovery Offer):'' resposta enviada por um ou mais AC, contendo seus identificadores e nomes de serviços disponíveis (no âmbito do PPPoE). | ||
+ | ** ''PADR (PPPoE Active Discovery Request):'' enviado pelo cliente para o AC escolhido, requisitando o início de uma sessão. | ||
+ | ** ''PADS (PPPoE Active Discovery Session-Confirmation):'' resposta do AC escolhido.<br><br>[[imagem:Pppoe-discovery.png|300px]]<br><br> | ||
+ | * '''Sessão (''Session''):''' nessa etapa são trocados quadros PPP como no estabelecimento de um enlace PPP usual. A sessão pode ser encerrada com a terminação PPP (i.e., via protocolo LCP), ou com a PDU PPPoE PADT (''PPPoE Active Discovery Terminate''). | ||
+ | |||
+ | |||
+ | ===Atividade=== | ||
+ | |||
+ | |||
+ | A atividade a ser executada sobre enlace PPPoE é ilustrada na figura abaixo: | ||
+ | |||
+ | [[imagem:atividade-pppoe.png | 800px]] | ||
+ | |||
+ | #Cada dupla deve utilizar pelo menos duas máquinas virtuais, uma para ser o AC e outra para ser um cliente. | ||
+ | #Instalar o pacote no cliente e no AC:<code> sudo apt-get install pppoe</syntaxhighlight> | ||
+ | #No AC crie o arquivo /etc/ppp/pppoe-server-options com o seguinte conteúdo:<code> | ||
+ | require-chap | ||
+ | noauth | ||
+ | login | ||
+ | lcp-echo-interval 10 | ||
+ | lcp-echo-failure 2 | ||
+ | ms-dns 200.135.37.65 | ||
+ | netmask 255.255.255.0 | ||
+ | noipdefault | ||
+ | debug | ||
+ | kdebug 4 | ||
+ | </syntaxhighlight> | ||
+ | #Crie no AC o arquivo /etc/ppp/chap-secrets com o seguinte conteúdo: <code> | ||
+ | usuario1 * senha1 | ||
+ | usuario2 * senha2 | ||
+ | ... | ||
+ | usuarioN * senhaN </syntaxhighlight> | ||
+ | #Crie o arquivo /etc/ppp/faixa-ip no AC com o seguinte conteúdo:<code> | ||
+ | 192.168.10X.10-50</syntaxhighlight> | ||
+ | #Ative o servidor PPPoE no AC:<code> | ||
+ | pppoe-server -C pji -L 192.168.10X.200 -p /etc/ppp/faixa-ip -I eth1 </syntaxhighlight> | ||
+ | #m cada computador das redes de acesso deve-se criar o arquivo /etc/ppp/peers/pji com este conteúdo:<code> | ||
+ | pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452 -C pji" | ||
+ | noipdefault | ||
+ | usepeerdns | ||
+ | defaultroute | ||
+ | hide-password | ||
+ | lcp-echo-interval 20 | ||
+ | lcp-echo-failure 3 | ||
+ | connect /bin/true | ||
+ | noauth | ||
+ | persist | ||
+ | mtu 1492 | ||
+ | noaccomp | ||
+ | user usuarioX | ||
+ | default-asyncmap </syntaxhighlight> | ||
+ | #Crie nesses computadores o arquivo /etc/ppp/chap-secrets com este conteúdo (substitua usuarioX e senhaX de acordo com o que foi adicionado no chap-secrets no AC):<code> | ||
+ | usuarioX * senhaX </syntaxhighlight> | ||
+ | #Execute o tcpdump e ative o monitoramento na interface eth0 no AC. | ||
+ | # Ative o enlace PPPoE, executando no cliente:<code> | ||
+ | pppd call pji </syntaxhighlight> | ||
+ | #Veja no tcpdump o tráfego que foi criado durante o estabelecimento do enlace. Qual a sequência de quadros PPPoE trocada entre AC e computador ? | ||
+ | # Observe se foi criada a interface ppp0. Confira o IP que ela está usando, o tipo de encapsulamento e a MTU. Confira também as interfaces ppp no AC, observando as mesmas informações. | ||
+ | #Tente usar a rede a partir do computador. Primeiro faça ping no AC, e em seguida tente acessar a rede externa. Foi possível? | ||
+ | #Coloque a máquina AC para rotear e mascarar pacotes. | ||
+ | |||
+ | {{collapse bottom | PPPoE}} | ||
+ | |||
+ | {{collapse top | ADSL}} | ||
+ | |||
+ | ===ADSL=== | ||
+ | |||
+ | ADSL (Asymetric Digital Subscriber Line) é uma tecnologia para provimento de enlace de dados para assinantes de linhas telefônicas residenciais. Ao contrário da modems analógicos (ex: [http://en.wikipedia.org/wiki/V.92 V.92]), ADSL não está limitado à largura de banda de canal de voz (~ 4kHz). Com isso, podem-se obter taxas de dados muito superiores, dependendo da versão de ADSL em uso. | ||
+ | |||
+ | Comparada a outras formas de DSL, o ADSL tem a característica de que os dados podem ser transmitidos mais rapidamente em uma direção do que na outra, assimetricamente, diferenciando-o de outros formatos. Os provedores geralmente anunciam o ADSL como um serviço para as pessoas conectarem-se à Internet do seguinte modo: o canal de comunicação é mais amplo e rápido para receber(download) e menor e mais lento para enviar(upload). | ||
+ | |||
+ | |||
+ | A tabela abaixo ilustra os vários padrões ADSL existentes e suas características: | ||
+ | |||
+ | |||
+ | [[imagem:Adsl-taxas.png]] | ||
+ | <br>''Tabela de versões de ADSL e suas características.<br>Obtido em http://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line#ADSL_standards'' | ||
+ | |||
+ | |||
+ | ADSL consegue obter taxas de dados muito superiores às de modems analógicos (que chegavam no máximo a 56 kbps) porque na verdade não usa um canal de voz. A ideia é usar a fiação telefônica para estabelecer um enlace de dados entre o assinante residencial e a operadora, mas não a rede telefônica em si. No sistema ADSL os sinais de voz e dados trafegam no mesmo par metálico mas não se misturam, devido ao fato de ocuparem em bandas de frequência diferentes. O sistema telefônico utiliza a banda de 0 até 4 kHz, enquanto que o sistema ADSL trabalha na faixa de 25 kHz a 1,1 MHz, conforme figura abaixo: | ||
+ | |||
+ | [[imagem: espectro-adsl.png|600px]] | ||
+ | |||
+ | |||
+ | Por isso que com ADSL pode-se ter o enlace de dados e falar ao telefone ao mesmo tempo. Para isso, na central onde chega a linha do assinante é feita uma separação entre o sinal de dados e o de voz: o de dados vai para uma rede de dados, e o de voz segue pela infraestrutura de telefonia. Em consequência, é necessário haver uma rede de dados separada da rede telefônica. A figura a seguir ilustra um enlace ADSL para um assinante residencial, evidenciando os componentes da infraestrutura da rede dados. | ||
+ | |||
+ | |||
+ | [[imagem:Dsl-architecture.png]] | ||
+ | |||
+ | |||
+ | A separação entre os canais de voz e de dados, feita por um ''filtro passa-baixa'', está destacada na figura abaixo: | ||
+ | |||
+ | [[imagem:Adsl-model.png]] | ||
+ | |||
+ | |||
+ | Na infraestrutura ADSL, cabem destacar alguns elementos: | ||
+ | |||
+ | * '''modem ADSL:'''O Modem ADSL que temos em casa também é chamado por outro nome: tranceptor. Os engenheiros na companhia telefônica ou no provedor de internet (ISP) o chamam de ATU-R. Independentemente do nome pelo qual é chamado, ele é o ponto em que os dados do computador ou rede do usuário se conectam com a linha | ||
+ | DSL. O Modem pode operar basicamente de duas formas: como roteador ou como bridge. Quando funciona como roteador, o modem possui recursos internos para estabelecer a conexão lógica com o AC. Quando funciona como bridge, os recursos necessários para o estabelecimento de uma conexão lógica devem estar instalados no computador, como o protocolo PPPoE. | ||
+ | * '''splitter:''' filtro que separa os sinais de voz e de dados. São usados tanto do lado do assinante quanto no DSLAM. | ||
+ | * '''DSLAM (DSL Access Multiplexer):''' multiplexador de acesso ADSL, que recebe as linhas dos assinantes do lado da operadora. Esse componente faz a intermediação entre os assinantes e a rede de dados da operadora. Dentre suas atribuições, destacam-se a modulação do sinal das linhas dos assinantes, a limitação das taxas de ''downstream'' e ''upstream'' de acordo com o contratado pelos assinantes, e as conversões de protocolos de enlace (quando necessárias) para a rede da operadora. | ||
+ | * '''AC (concentrador de acesso):''' equipamento que concentra as pontas dos enlaces de dados dos assinantes no lado da rede da operadora. | ||
+ | |||
+ | A parte da infraestrutura ADSL dentro da rede de dados da operadora inclui equipamentos DSLAM (muitos deles), um ou mais AC e as redes de comunicação para interligá-los. Note-se que quem dá acesso de fato à Internet é o AC. A figura abaixo ilustra esses componentes. | ||
+ | |||
+ | [[imagem:Dslam-infra.png]] | ||
+ | |||
+ | O enlace de dados entre o equipamento do assinante e a rede da operadora pode ser feita de diferentes formas. Esse enlace é visto pelo assinante como seu enlace para a Internet - i.e. ele obtém seu endereço IP fornecido pela operadora. Os tipos de enlace de dados ADSL mais usados são: | ||
+ | * '''PPPoE (PPP over Ethernet):''' cria um enlace ponto-a-ponto com protocolo PPP, cujos quadros são encapsulados em quadros Ethernet. Esta é a forma mais utilizada para assinantes residenciais. | ||
+ | * '''PPPoA (PPP over ATM):''' cria um enlace ponto-a-ponto com protocolo PPP, cujos quadros são encapsulados em mensagens AAL5 da arquitetura ATM. | ||
+ | * '''EoA (Ethernet over ATM):''' cria um enlace Ethernet, cujos quadros são encapsulados em mensagens AAL5 da arquitetura ATM. | ||
+ | |||
+ | O enlace PPPoE funciona como se tivesse um link ponto-a-ponto entre o roteador ADSL e um concentrador de acesso (AC). Quer dizer, parece que existe um fio ligando diretamente esses dois equipamentos, apesar de na realidade existir toda uma infraestrutura entre os dois. Isso pode ser visualizado na figura abaixo. Em cada ponta desse link PPPoE há um endereço IP usado pelos respectivos equipamentos. | ||
+ | |||
+ | [[imagem:Enlace-pppoe.png]] | ||
+ | |||
+ | === ATIVIDADE === | ||
+ | |||
+ | Cada equipe deve estabelecer seu enlace WAN usando ADSL. Em seguida, fazer testes diversos afim de testar a conectividade de sua rede. | ||
+ | |||
+ | ==== Configurações ADSL ==== | ||
+ | |||
+ | Cada link ADSL deve ter seu IP manualmente configurado, o qual deve ser um IP válido fornecido à equipe pelo provedor (professores). | ||
+ | |||
+ | Os seguintes parâmetros dos modems ADSL devem ter estes valores: | ||
+ | * '''Port:''' ''0'' | ||
+ | * '''VPI:''' ''8'' | ||
+ | * '''VCI:''' ''35'' | ||
+ | * '''Encapsulamento:''' ''LLC/SNAP'' | ||
+ | * '''Modo:''' ''PPPoE'' | ||
+ | * '''User:''' usuario1 | ||
+ | * '''Password:''' senha1 | ||
+ | * '''NÃO''' ativar firewall. | ||
+ | * '''Ativar''' NAT | ||
+ | |||
+ | {{collapse bottom | ADSL}} | ||
+ | |||
+ | ==Aula 35 - 19/07/16: Trabalho== | ||
+ | |||
+ | [[imagem: trabalho-pji20161.png|600px]] | ||
+ | |||
+ | ==Aula 36 - 22/07/16: Trabalho - conclusão== | ||
+ | |||
+ | ==Aula 37 - 26/07/16: Recuperação== |
Edição atual tal como às 16h49min de 5 de dezembro de 2016
PJI11103-2015-2
Diário de aula de PJI - 2016-1 - Prof. Simara Sonaglio
Dados Importantes
Professora: Simara Sonaglio
Email: simara.sonaglio@ifsc.edu.br
Encontros: terças e sextas das 18:45 às 22:15 horas.
- Avaliação
- Avaliações individuais em cada etapa do projeto com conceito por letras: A, B, C e D. Conceito mínimo necessário em cada avaliação: C.
- Avaliação baseada no projeto. Avaliação individual com acesso ao servidor da equipe e com questões relativas aos serviços e configurações do mesmo.
- Um ou mais conceitos D implica na realização da reavaliação: uma única avaliação a ser realizada no último dia de aula.
IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.
Plano de Ensino
AVALIAÇÕES
Aluno(a) | Avaliação 1 | Avaliação 2 | Avaliação 3 | Trabalho | Média |
---|---|---|---|---|---|
Caroline | (4,43*+7,65**)/2=6,04 | 7,63 | 7,75 | 10,00 | 7,86 |
Christien | 6,17 | (4,29*+9,00**)/2=6,65 | 6,00 | 10,00 | 7,21 |
Thiago | 6,38 | (2,92*+9,00**)/2=6,00 | 9,00 | 10,00 | 7,85 |
Victor | 8,47 | 10,00 | 9,00 | 10,00 | 9,37 |
* - Avaliação
** - Recuperação extra
Diário de aulas
IPs e sub-domínios DNSs destinados às respectivas equipes:
- 200.135.37.121 - prji1.sj.ifsc.edu.br
- 200.135.37.122 - prji2.sj.ifsc.edu.br
- 200.135.37.123 - prji3.sj.ifsc.edu.br
Aula 1 - 22/03/16: Apresentação da disciplina e revisão de Linux
Apresentação |
---|
|
Revisão dos comandos básicos |
---|
Objetivo: Revisão dos comandos básicos, familiarização e fixação do conteúdo. Material Auxiliar (Comandos básicos 01) (Comandos básicos 02 ) ( Slides Aula Introdução ao Linux Tulio.)
Editor VI Objetivo: Familiarização com o editor e ser capaz de executar comandos simples, porém úteis para manipulação de arquivos.
|
Aula 2 - 25/03/16: Feriado
Aula 3 - 29/03/16: Criação de usuários e grupos e permissionamento de arquivos
Criação de usuários e grupos |
---|
Criação de contas de usuários e de grupos, e seu uso para conferir permissões de acesso a arquivos, diretórios e recursos do sistema operacional. Apostila, páginas 61 a 65. Slides Aula Tulio: Slides Aula Usuários, Grupos e Permissões Usuários e gruposUm usuário Linux é uma entidade que possui uma identificação no sistema onde os principais parâmetros são: login, senha, e número de identificação. Estas informações permitem ao Linux controlar como o acesso é garantido aos usuários e o que eles podem fazer depois de obter a permissão de acesso. Um grupo é um conjunto de usuários. Cada grupo também possui identificação única no sistema, um nome e um número. O administradores de sistemas normalmente fazem controle de acesso por meio dos grupos. Um usuário no Linux (e no Unix em geral) é definido pelo seguinte conjunto de informações:
As contas de usuários, que contêm as informações acima, podem ficar armazenadas em diferentes bases de dados (chamadas de bases de dados de usuários). Dentre elas, a mais simples é composta pelo arquivo /etc/passwd: root:x:0:0:root:/root:/bin/bash sshd:x:71:65:SSH daemon:/var/lib/sshd:/bin/false suse-ncc:x:105:107:Novell Customer Center User:/var/lib/YaST2/suse-ncc-fakehome:/bin/bash wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash news:x:9:13:News system:/etc/news:/bin/bash uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash roberto:x:1001:100:Roberto de Matos:/data1/roberto:/bin/bash Acima um exemplo de arquivo /etc/passwd Cada linha desse arquivo define uma conta de usuário no seguinte formato: nome de usuário:senha:UID:GID:Nome completo:Diretório inicial:Shell O campo senha em /etc/passwd pode assumir os valores:
O arquivo /etc/shadow armazena exclusivamente as informações relativas a senha e validade da conta. Nele cada conta possui as seguintes informações:
Um exemplo do arquivo /etc/shadow segue abaixo: root:$2a$05$8IZNUuFTMoA3xv5grggWa.oBUBfvrE4MfgRDTlUI1zWDXGOHi9dzG:13922:::::: suse-ncc:!:13922:0:99999:7::: uucp:*:13922:::::: wwwrun:*:13922:::::: roberto:$1$meoaWjv3$NUhmMHVdnxjmyyRNlli5M1:14222:0:99999:7::: Exercício: quando a senha do usuário roberto irá expirar ? Um grupo é um conjunto de usuários definido da seguinte forma:
Assim como as contas de usuários, os grupos ficam armazenados em bases de dados de usuários, sendo o arquivo /etc/group a mais simples delas: root:x:0: trusted:x:42: tty:x:5: utmp:x:22: uucp:x:14: video:x:33:roberto www:x:8:roberto users:x:100: radiusd:!:108: vboxusers:!:1000: Os membros de um grupo são os usuários que o têm como grupo primário (especificado na conta do usuário em /etc/passwd), ou que aparecem listados em /etc/group. Gerenciamento de usuários e gruposPara gerenciar usuários e grupos podem-se editar diretamente os arquivos /etc/passwd, /etc/shadow e /etc/group, porém existem utilitários que facilitam essa tarefa:
Esses utilitários usam os arquivos /etc/login.defs e /etc/default/useradd para obter seus parâmetros padrão. O /etc/adduser.conf tem o mesmo intuito mas é seta exclusivamente os parâmetros do comando adduser. O arquivo /etc/login.defs contém uma série de diretivas e padrões que serão utilizados na criação das próximas contas de usuários. Seu principal conteúdo é: MAIL_DIR dir # Diretório de e-mail PASS_MAX_DAYS 99999 #Número de dias até que a senha expire PASS_MIN_DAYS 0 #Número mínimo de dias entre duas trocas senha PASS_MIN_LEN 5 #Número mínimo de caracteres para composição da senha PASS_WARN_AGE 7 #Número de dias para notificação da expiração da senha UID_MIN 500 #Número mínimo para UID UID_MAX 60000 #Número máximo para UID GID_MIN 500 #Número mínimo para GID GID_MAX 60000 #Número máximo para GID CREATE_HOME yes #Criar ou não o diretório home Como o login.defs o arquivo /etc/default/useradd contém padrões para criação de contas. Seu principal conteúdo é: GROUP=100 #GID primário para os usuários criados HOME=/home #Diretório a partir do qual serão criados os “homes” INACTIVE=-1 #Quantos dias após a expiração da senha a conta é desativada EXPIRE=AAAA/MM/DD #Dia da expiração da conta SHEL=/bin/bash #Shell atribuído ao usuário. SKEL=/etc/skel #Arquivos e diretórios padrão para os novos usuários. GROUPS=video,dialout CREATE_MAIL_SPOOL=no O /etc/adduser.conf também possui uma série de padrões que funcionam especificamente para o comando adduser: DSHELL=/bin/bash #Shell atribuído ao usuário. DHOME=/home #Diretório a partir do qual serão criados os “homes” SKEL=/etc/skel #Arquivos e diretórios padrão para os novos usuários. FIRST_UID=1000 #Número mínimo para UID LAST_UID=29999 #Número máximo para UID FIRST_GID=1000 #Número mínimo para GID LAST_GID=29999 #Número máximo para GID QUOTAUSER="" #Se o sistema de cotas estiver funcional, pode atribuir quota ao usuário criado. AtividadeEsta parte da atividade cada aluno executa individualmente em sua máquina, fazendo uso da devida máquina virtual (1-Grafico ou 1-Servidor).
|
Permissionamento de arquivos |
---|
PermissionamentoHá uma maneira de restringir o acesso aos arquivos e diretórios para que somente determinados usuários possam acessá-los. A cada arquivo e diretório é associado um conjunto de permissões. Essas permissões determinam quais usuários podem ler, e escrever (alterar) um arquivo e, no caso de ser um arquivo executável, quais usuários podem executá-lo. Se um usuário tem permissão de execução para um diretório, significa que ele pode realizar buscas dentro daquele diretório, e não executá-lo como se fosse um programa. Quando um usuário cria um arquivo ou um diretório, o LINUX determina que ele é o proprietário (owner) daquele arquivo ou diretório. O esquema de permissões do LINUX permite que o proprietário determine quem tem acesso e em que modalidade eles poderão acessar os arquivos e diretórios que ele criou. O super-usuário (root), entretanto, tem acesso a qualquer arquivo ou diretório do sistema de arquivos. O conjunto de permissões é dividido em três classes: proprietário, grupo e usuários. Um grupo pode conter pessoas do mesmo departamento ou quem está trabalhando junto em um projeto. Os usuários que pertencem ao mesmo grupo recebem o mesmo número do grupo (também chamado de Group Id ou GID). Este número é armazenado no arquivo /etc/passwd junto com outras informações de identificação sobre cada usuário. O arquivo /etc/group contém informações de controle sobre todos os grupos do sistema. Assim, pode -se dar permissões de acesso diferentes para cada uma destas três classes. Quando se executa ls -l em um diretório qualquer, os arquivos são exibidos de maneira semelhante a seguinte: > ls -l total 403196 drwxr-xr-x 4 odilson admin 4096 Abr 2 14:48 BrOffice_2.1_Intalacao_Windows/ -rw-r--r-- 1 luizp admin 113811828 Out 31 21:28 broffice.org.2.0.4.rpm.tar.bz2 -rw-r--r-- 1 root root 117324614 Dez 27 14:47 broffice.org.2.1.0.rpm.tar.bz2 -rw-r--r-- 1 luizp admin 90390186 Out 31 22:04 BrOo_2.0.4_Win32Intel_install_pt-BR.exe -rw-r--r-- 1 root root 91327615 Jan 5 21:27 BrOo_2.1.0_070105_Win32Intel_install_pt-BR.exe > As colunas que aparecem na listagem são:
O esquema de permissões está dividido em 10 colunas, que indicam se o arquivo é um diretório ou não (coluna 1), e o modo de acesso permitido para o proprietário (colunas 2, 3 e 4), para o grupo (colunas 5, 6 e 7) e para os demais usuários (colunas 8, 9 e 10). Existem três modos distintos de permissão de acesso: leitura (read), escrita (write) e execução (execute). A cada classe de usuários você pode atribuir um conjunto diferente de permissões de acesso. Por exemplo, atribuir permissão de acesso irrestrito (de leitura, escrita e execução) para você mesmo, apenas de leitura para seus colegas, que estão no mesmo grupo que você, e nenhum acesso aos demais usuários. A permissão de execução somente se aplica a arquivos que podem ser executados, obviamente, como programas já compilados ou script shell. Os valores válidos para cada uma das colunas são os seguintes:
A permissão de acesso a um diretório tem outras considerações. As permissões de um diretório podem afetar a disposição final das permissões de um arquivo. Por exemplo, se o diretório dá permissão de gravação a todos os usuários, os arquivos dentro do diretório podem ser removidos, mesmo que esses arquivos não tenham permissão de leitura, gravação ou execução para o usuário. Quando a permissão de execução é definida para um diretório, ela permite que se pesquise ou liste o conteúdo do diretório. A modificação das permissões de acesso a arquivos e diretórios pode ser feita usando-se os utilitários:
Há também o utilitário umask, que define as permissões default para os novos arquivos e diretórios que um usuário criar. Esse utilitário define uma máscara (em octal) usada para indicar que permissões devem ser removidas. Exemplos:
Atividade
|
Aula 4 - 01/04/16: Permissionamento de arquivos e SSH
Permissionamento de arquivos |
---|
PermissionamentoHá uma maneira de restringir o acesso aos arquivos e diretórios para que somente determinados usuários possam acessá-los. A cada arquivo e diretório é associado um conjunto de permissões. Essas permissões determinam quais usuários podem ler, e escrever (alterar) um arquivo e, no caso de ser um arquivo executável, quais usuários podem executá-lo. Se um usuário tem permissão de execução para um diretório, significa que ele pode realizar buscas dentro daquele diretório, e não executá-lo como se fosse um programa. Quando um usuário cria um arquivo ou um diretório, o LINUX determina que ele é o proprietário (owner) daquele arquivo ou diretório. O esquema de permissões do LINUX permite que o proprietário determine quem tem acesso e em que modalidade eles poderão acessar os arquivos e diretórios que ele criou. O super-usuário (root), entretanto, tem acesso a qualquer arquivo ou diretório do sistema de arquivos. O conjunto de permissões é dividido em três classes: proprietário, grupo e usuários. Um grupo pode conter pessoas do mesmo departamento ou quem está trabalhando junto em um projeto. Os usuários que pertencem ao mesmo grupo recebem o mesmo número do grupo (também chamado de Group Id ou GID). Este número é armazenado no arquivo /etc/passwd junto com outras informações de identificação sobre cada usuário. O arquivo /etc/group contém informações de controle sobre todos os grupos do sistema. Assim, pode -se dar permissões de acesso diferentes para cada uma destas três classes. Quando se executa ls -l em um diretório qualquer, os arquivos são exibidos de maneira semelhante a seguinte: > ls -l total 403196 drwxr-xr-x 4 odilson admin 4096 Abr 2 14:48 BrOffice_2.1_Intalacao_Windows/ -rw-r--r-- 1 luizp admin 113811828 Out 31 21:28 broffice.org.2.0.4.rpm.tar.bz2 -rw-r--r-- 1 root root 117324614 Dez 27 14:47 broffice.org.2.1.0.rpm.tar.bz2 -rw-r--r-- 1 luizp admin 90390186 Out 31 22:04 BrOo_2.0.4_Win32Intel_install_pt-BR.exe -rw-r--r-- 1 root root 91327615 Jan 5 21:27 BrOo_2.1.0_070105_Win32Intel_install_pt-BR.exe > As colunas que aparecem na listagem são:
O esquema de permissões está dividido em 10 colunas, que indicam se o arquivo é um diretório ou não (coluna 1), e o modo de acesso permitido para o proprietário (colunas 2, 3 e 4), para o grupo (colunas 5, 6 e 7) e para os demais usuários (colunas 8, 9 e 10). Existem três modos distintos de permissão de acesso: leitura (read), escrita (write) e execução (execute). A cada classe de usuários você pode atribuir um conjunto diferente de permissões de acesso. Por exemplo, atribuir permissão de acesso irrestrito (de leitura, escrita e execução) para você mesmo, apenas de leitura para seus colegas, que estão no mesmo grupo que você, e nenhum acesso aos demais usuários. A permissão de execução somente se aplica a arquivos que podem ser executados, obviamente, como programas já compilados ou script shell. Os valores válidos para cada uma das colunas são os seguintes:
A permissão de acesso a um diretório tem outras considerações. As permissões de um diretório podem afetar a disposição final das permissões de um arquivo. Por exemplo, se o diretório dá permissão de gravação a todos os usuários, os arquivos dentro do diretório podem ser removidos, mesmo que esses arquivos não tenham permissão de leitura, gravação ou execução para o usuário. Quando a permissão de execução é definida para um diretório, ela permite que se pesquise ou liste o conteúdo do diretório. A modificação das permissões de acesso a arquivos e diretórios pode ser feita usando-se os utilitários:
Há também o utilitário umask, que define as permissões default para os novos arquivos e diretórios que um usuário criar. Esse utilitário define uma máscara (em octal) usada para indicar que permissões devem ser removidas. Exemplos:
Atividade
|
SSH |
---|
Ver capítulo 33 da apostila. Gabarito da atividade sobre SSH. Habilitando acesso remoto com SSHEm informática, o Secure Shell ou SSH é, simultaneamente, um programa de computador e um protocolo de rede que permite a conexão com outro computador na rede, de forma a executar comandos de uma máquina remota. Possui as mesmas funcionalidades do TELNET, com a vantagem da conexão entre o cliente e o servidor ser criptografada, ou seja, mais segura. O SSH faz parte da suíte de protocolos TCP/IP que torna segura a administração remota de um servidor Linux/Unix. O scp (Secure Copy) é uma maneira segura de fazer cópias de arquivos e diretórios usando o protocolo SSH. AtividadeAtividade individual, cada aluno em sua máquina virtual (1-Servidor)
vi /etc/hosts.allow sshd: 192.168.X.X vi /etc/hosts.deny sshd: ALL |
Aula 5 - 05/04/16: Formatação, instalação e início da configuração do servidor principal
Formatação, instalação e início da configuração do servidor principal |
---|
O objetivo inicial é instalar e configurar basicamente o sistema operacional na máquina que atuará como principal servidor da rede. Instalando o sistema operacionalAs etapas básicas consistem em:
|
Outras configurações no servidor |
---|
Configuração básica da interface de rede do servidorVer capítulo 22 da apostila.
|
Aula 6 - 08/04/16: SSH utilizando chaves de autenticação / Configuração do servidor / Interfaces de rede
SSH utilizando chaves de autenticação |
---|
SSH utilizando chaves de autenticaçãoTexto retirado de Dominando o SSH Por mais seguras que sejam suas senhas, sempre existe uma pequena possibilidade de que um atacante descubra alguma delas. Diante deste problema, o SSH permite o uso de chaves de autenticação. Em vez de depender unicamente da senha como forma de autenticação, você pode utilizar um par de chaves de autenticação, onde a chave pública é instalada nos servidores que serão acessados e a chave privada (que nunca sai da sua máquina) é protegida por uma passphrase, sem a qual a chave se torna inútil. Nesse caso, temos uma segurança de dois níveis, em que é preciso saber a passphrase e, além dela, ter a chave privada, um arquivo salvo no HD ou em um pendrive, algo similar ao sistema bancário, onde você precisa ter o cartão e saber a senha. Atividade Realizar esta atividade utilizando um terminal na sua máquina real (que será nosso cliente SSH) e uma máquina virtual que possua o servidor SSH instalado.
|
Aula 7 - 12/04/16: Configuração do servidor / Interfaces de rede
Atividade no servidor
Após aprendermos a tornar nossos acessos via SSH mais seguros, podemos dar sequência a configuração do servidor. Assim, cada equipe deve definir como implementar em seu servidor os pontos solicitados na aula passada em relação a usuários e grupos, permissionamento de acesso e acesso remoto via SSH.
Interfaces de rede e rotas estáticas |
---|
Apostila, capítulo 22. Para adicionarmos uma máquina à rede é obrigatória a configuração de no mínimo os seguintes parâmetros: endereço ip, máscara de rede. Com estes dois parâmetros a máquina já se comunica com outras máquinas da rede local. Para uma configuração completa é necessário configurarmos ainda o nome de máquina, o servidor de nomes (DNS) e o roteador padrão (default gateway). Todos estes parâmetros de rede podem ser configurados estaticamente ou por meio de um servidor DHCP (dinamicamente). No caso de servidores de rede é praticamente obrigatório, para alguns serviços é obrigatório, que a configuração seja estática. Para a maioria dos clientes a configuração clássica é como cliente DHCP. Nesta aula iremos nos concentrar na configuração estática de rede. Interface de rede é qualquer dispositivo (físico ou lógico) capaz de transmitir e receber datagramas IP. Interfaces de rede ethernet são o exemplo mais comum, mas há também interfaces PPP (seriais), interfaces tipo túnel e interfaces loopback. De forma geral, essas interfaces podem ser configuradas com um endereço IP e uma máscara de rede, e serem ativadas ou desabilitadas. Em sistemas operacionais Unix a configuração de interfaces de rede se faz com o programa ifconfig: Para mostrar todas as interfaces: root@gerencia:~> ifconfig -a
dsl0 Link encap:Point-to-Point Protocol
inet addr:189.30.70.200 P-t-P:200.138.242.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:34260226 errors:0 dropped:0 overruns:0 frame:0
TX packets:37195398 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:19484812547 (18582.1 Mb) TX bytes:10848608575 (10346.0 Mb)
eth1 Link encap:Ethernet HWaddr 00:19:D1:7D:C9:A9
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37283974 errors:0 dropped:0 overruns:0 frame:0
TX packets:42055625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20939614658 (19969.5 Mb) TX bytes:18284980569 (17437.9 Mb)
Interrupt:16 Base address:0xc000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:273050 errors:0 dropped:0 overruns:0 frame:0
TX packets:273050 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21564572 (20.5 Mb) TX bytes:21564572 (20.5 Mb)
root@gerencia:~>
Para configurar uma interface de rede (que fica automaticamente ativada): root@gerencia:~> ifconfig eth1 192.168.1.100 netmask 255.255.255.0
Os scripts ifup e ifdown servem para ativar ou parar interfaces específicas, fazendo todas as operações necessárias para isto: # Desativam e ativam todas as interfaces de rede
ifdown -a && ifup -a
Ao se configurar uma interface de rede, cria-se uma rota automática para a subrede diretamente acessível via aquela interface. Isto se chama roteamento mínimo. root@gerencia:~> ifconfig eth1 192.168.10.0 netmask 255.255.0.0
root@gerencia:~> netstat -rn (ou: route -n)
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
root@gerencia:~>
Pode-se associar mais de um endereço a uma mesma interface de rede. Isto se chama IP alias: root@gerencia:~> ifconfig eth1:0 192.168.1.110 netmask 255.255.255.0
root@gerencia:~> ifconfig eth1:1 192.168.2.100 netmask 255.255.255.0
root@gerencia:~> ifconfig -a
eth1 Link encap:Ethernet HWaddr 00:19:D1:7D:C9:A9
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37295731 errors:0 dropped:0 overruns:0 frame:0
TX packets:42068558 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20942258027 (19972.0 Mb) TX bytes:18294794452 (17447.2 Mb)
Interrupt:16 Base address:0xc000
eth1:0 Link encap:Ethernet HWaddr 00:19:D1:7D:C9:A9
inet addr:192.168.1.110 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:16 Base address:0xc000
eth1:1 Link encap:Ethernet HWaddr 00:19:D1:7D:C9:A9
inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:16 Base address:0xc000
root@gerencia:~>
Quando é feita a configuração de rede via comando, normalmente é necessário alterar o arquivo /etc/resolv.conf e acrescentar neste arquivo um servidor DNS para resolver nome, conforme abaixo:
|
Aula 8 - 15/04/16: Interfaces de rede - Atividades
Atividades - Máquina virtual |
---|
A) Configurar interface de rede
B) Coleta de tráfego
C) Tabelas estáticas de roteamento
|
Aula 9 - 19/04/16: Continuação Aula 8
Aula 10 - 22/04/16: Interfaces de rede e roteamento estático
- Conclusão do laboratório sobre interfaces de rede e roteamento estático;
- Configuração do servidor como roteador;
- Inserção de AP na rede.
Aula 11 - 26/04/16: NAT e DHCP
NAT |
---|
NATA tradução de endereço de rede (NAT - Network Address Translation), proposta pela RFC 1631 em 1994, é uma função de rede criada para contornar o problema da escassez de endereços IP. Com a explosão no crescimento da Internet, e o mau aproveitamento dos endereços IP (agravado pelo endereçamento hierárquico), percebeu-se que o esgotamento de endereços poderia ser logo alcançado a não ser que algumas medidas fossem tomadas. Esse problema somente seria eliminado com a reformulação do protocolo IP, de forma a aumentar o espaço de endereços, que resultou na proposta do IPv6 em 1998. Porém no início dos anos 1990 a preocupação era mais imediata, e pensou-se em uma solução provisória para possibilitar a expansão da rede porém reduzindo-se a pressão por endereços IP. O NAT surgiu assim como uma técnica com intenção de ser usada temporariamente, enquanto soluções definitivas não se consolidassem. Ainda hoje NAT é usado em larga escala, e somente deve ser deixado de lado quando IPv6 for adotado mundialmente (o que deve demorar). NAT parte de um princípio simples: endereços IP podem ser compartilhados por nodos em uma rede. Para isto, usam-se endereços IP ditos não roteáveis (também chamados de inválidos) em uma rede, sendo que um ou mais endereços IP roteáveis (válidos) são usados na interface externa roteador que a liga a Internet. Endereços não roteáveis pertencem às subredes 10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12, e correspondem a faixas de endereços que não foram alocados a nenhuma organização e, portanto, não constam das tabelas de roteamento dos roteadores na Internet. A figura abaixo mostra uma visão geral de uma rede em que usa NAT: Para ser possível compartilhar um endereço IP, NAT faz mapeamentos (IP origem, port origem, protocolo transporte) -> (IP do NAT, port do NAT, , protocolo transporte), sendo protocolo de transporte TCP ou UDP. Assim, para cada par (IP origem, port origem TCP ou UDP) o NAT deve associar um par (IP do NAT, port do NAT TCP ou UDP) (que evidentemente deve ser único). Assim, por exemplo, se o roteador ou firewall onde ocorre o NAT possui apenas um endeerço IP roteável, ele é capaz em tese de fazer até 65535 mapeamentos para o TCP (essa é a quantidade de ports que ele pode possui), e o mesmo para o UDP. Na prática é um pouco menos, pois se limitam os ports que podem ser usados para o NAT. Note que o NAT definido dessa forma viola a independência entre camadas, uma vez que o roteamento passa a depender de informação da camada de transporte. NAT no LinuxVer capítulo 35, seção 4, da apostila. O NAT no Linux se configura com iptables. As regras devem ser postas na tabela nat, e aplicadas a chain POSTROUTING, como no seguinte exemplo: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE ;Habilita o NAT
iptables -t nat -L ;Lista as atuais regras da tabela NAT
A regra acima faz com que todo o tráfego originado em 192.168.1.0/24, e que sai pela interface eth0 deve ser mascarado com o endereço IP dessa interface. Esta regra diz o seguinte: todos os pacotes que passarem (POSTROUTING) por esta máquina com origem de 192.168.1.0/24 e sairem pela interface eth0 serão mascarados, ou seja sairão desta máquina com o endereço de origem como sendo da eth0. O alvo MASQUERADE foi criado para ser usado com links dinâmicos (tipicamente discados ou ADSL), pois os mapeamentos se perdem se o link sair do ar. AtividadeD) NAT
|
DHCP |
---|
DHCPVer capítulo 31 da apostila. Toda máquina que for participar de uma rede, deve primeiro, ter um endereço IP. Em uma rede pequena (até 20 máquinas), a tarefa de configurar IPs é relativamente simples. Mas em uma rede grande com centenas de máquinas, esta tarefa de endereçamento torna-se trabalhosa. Para facilitar as coisas, foi criado um mecanismo de endereçamento automático de IP para máquinas em uma rede TCP/IP: o DHCP (Dynamic Host Configuration Protocol – Protocolo de configuração de máquinas dinâmico). Um servidor DHCP pode facilitar muito a vida do administrador da rede. Dentre as configurações de serviços que podem ser passadas ao host cliente por dhcp são:
Como podemos observar, tudo o que é necessário para que uma máquina esteja em condições de ingressar em uma rede e usufruir de tudo o que ela possa oferecer, o DHCP se faz útil para sua configuração automática. Protocolo DHCPEntenda, com a explicação a seguir, como funciona o protocolo DHCP. a) DHCP Discover – Quando uma máquina é ligada, ela tem um serviço (daemon) cliente do DHCP configurado para localizar o servidor neste momento. Este cliente DHCP envia um pacote UDP com destino à porta 67 do servidor chamado “DHCP Discover”. Este pacote broadcast tem o endereço IP de destino 255.255.255.255 e mac address de destino ff:ff:ff:ff:ff:ff. b) DHCP Offer – O servidor ao receber o referido pacote em sua porta ethernet, irá analisá-lo e, em sua tabela de IPs, reservar um endereço e preparar um pacote de resposta ao cliente solicitante. Este pacote de resposta chama-se DHCP Offer. O único meio de a estação cliente saber que o pacote DHCP Offer se destina à ela, é através do mac address. c) DHCP Request – O cliente ao receber o pacote do servidor, decide se aceita a configuração oferecida pois pode receber mais de uma oferta. Em caso positivo, retorna um novo pacote ao servidor, comunicando o aceitamento da oferta. Este pacote chama-se DHCP Request. d) DHCP Ack – Para finalizar a “conversação” entre cliente e servidor DHCP, este finaliza (efetiva) o aluguel (lease) do endereço ao cliente em sua tabela de IPs, e envia àquele, um pacote DHCP Ack para que ele ajuste suas configurações. |
Aula 12 - 29/04/16: Aula cancelada
Apenas o Christien compareceu e possuía apenas em torno de uma hora disponível, pois precisava sair cedo. Como o conteúdo terá de ser ministrado em outra aula, o mesmo foi dispensado desta uma hora que poderia assistir.
Aula 13 - 03/05/16: DHCP - prática
DHCP - atividade |
---|
AtividadeEm nosso experimento será usado o servidor DHCP desenvolvido pelo ISC. Para usá-lo devem-se seguir os passos descritos abaixo.
Maiores detalhes sobre esse servidor DHCP: |
Aula 14 - 06/06/16: Avaliação individual
Avaliação individual prática e teórica dos conteúdos vistos até o momento.
Conteúdos:
- Gerência de usuários e grupos;
- Permissionamento de arquivos;
- Acesso remoto via SSH;
- Interfaces de rede;
- Roteamento estático em servidor Linux;
- NAT;
- DHCP.
Aula 15 - 10/05/16: DNAT
DNAT |
---|
Anteriormente estudamos NAT com o intuito de mascarar IPs não roteáveis no âmbito da internet para IPs roteáveis no âmbito da internet. Este tipo de NAT é denominado SNAT e é aplicado quando desejamos alterar o endereço de origem de um determinado pacote. Agora iremos estudar uma outra forma de implementar NAT, o DNAT. O DNAT aplica-se quando desejamos alterar o endereço de destino de um pacote. O redirecionamento de portas e o redirecionamento de servidores são um exemplo de DNAT e iremos utilizá-los nesta aula. Para fazermos redirecionamento de porta apenas, devemos executar o seguinte comando:
|
Aula 16 - 13/05/16: DNAT no servidor e Correção da prova
Aula 17 - 17/05/16: Apache
WWW e protocolo HTTP |
---|
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 |
Apache |
---|
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 é utilizado é 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, define-se um servidor WWW chamado www.prj.edu.br, que atende requisições no ports 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
Obs.: Não é necessário alterar o arquivo /etc/hosts, como na atividade acima. |
Relatório individual - Complementação Av 1 |
---|
Relatório individualGerar um documento sobre os TODOS as configurações e serviços que já estão rodando na máquina Servidor de cada Equipe. O trabalho deve ser individual e deve ser entregue em 27/05. Entregar em formato PDF. Os conteúdos a serem abordados no relatório são:
O trabalho deve contemplar os seguintes pontos:
|
Aula 18 - 20/05/16: DNS
DNS | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Ver capítulo 25 da apostila. 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 domí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 o "." (último) significa o root level domain .br é o domínio do topo da hierarquia (no Brasil feito em [1])ao qual mail.sj.ifsc.edu.br pertence. .ifsc.edu é um subdomínio de .br., 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 envia as consultas para um ou mais servidores de nomes e interpreta as respostas. (tirado do manual do BIND9) Ver também o livro sobre DNS e BIND da O'Reilly. Registros DNSCada 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): root@freeman:~$ 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
Cada uma das informações acima mostra um determinado registro e seu conteúdo, como descrito na tabela abaixo:
Obs: TTL (Time To Live) é 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:
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: $TTL 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
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. SOA – é o preâmbulo, o 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 ou seja debian.com.br) a diferença de usar o arroba é que ele será repetido automaticamente nas demais linhas caso não seja informado outro nome de zona, depois 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. Em resumo um registro de recurso é uma tupla (linha) contendo 5 campos, sendo que alguns podem ser omitidos, seguem a seguinte ordem: Domain Name Informa o domínio ao qual o registro se aplica, existem muitos registros para cada domínio, e cada cópia do banco de dados armazena informações sobre vários domínios, esse campo é a chave de pesquisa primária utilizada para atender às consultas Time_to_live indica a estabilidade do registro, é dado em segundos Class caso esteja relacionado a internet seu valor será sempre IN Type informa o tipo de registro, dentre os mais importantes podemos os que aparecem na segunda tabela. 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 que o servidor de DNS primário irá armazenar, informamos no arquivo em questão o ns1.debian.com.br. e o ns2.debian.com.br. Informamos também um registro do tipo MX (Mail Exchanger) com prioridade 10 (quanto menor o número da prioridade maior será a prioridade dada ao servidor de e-mail no recebimento de e-mails). E por último foram feitas as associações entre nameserver e seus respectivos IP’s. Comando útilComando para recarregar os arquivos de configuração e zonas: rndc reload
AtividadeO objetivo é montar a seguinte estrutura: 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.1.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.
|
Aula 19 - 24/05/16: DNS e Apache no servidor das equipes
Na aula de hoje serão executados os seguintes pontos:
- Instalar o servidor DNS no Servidor 1 de cada equipe;
- Configurar o sub-domínio prjiX.sj.ifsc.edu.br, conforme ordem abaixo:
- prji1 e prji2.sj.ifsc.edu.br pertencem à equipe 1;
- prji3 e prji4.sj.ifsc.edu.br pertencem à equipe 2;
- No Servidor 2 devem ser criadas duas páginas Web para cada equipe. Para isso, deverão ser criados Virtual Hosts baseados em nome, sendo que o ServerName de cada página deve ser configurado como www.prjiX.sj.ifsc.edu.br;
- Configurar no Servidor 1 para que ao digitar www.prjiX.sj.ifsc.edu.br no navegador, um usuário consiga acessar uma página Web no Servidor 2 de cada equipe;
- Criar uma terceira página no Servidor 2 com o ServerName como www.minharedeinterna.edu.br;
- No Servidor 1, configurar uma zona minharedeinterna.edu.br;
- Associar o nome www.minharedeinterna.edu.br ao IP interno do Servidor 2;
- Criar uma página Web no Servidor 2 com o ServerName como www.minharedeinterna.edu.br;
- Fazer testes diversos.
Aula 20 - 27/05/16: Compartilhamento de arquivos via FTP e HTTP
Nesta aula teremos os seguintes pontos:
- Conclusão dos quatro últimos itens da aula anterior;
- Compartilhamentos de arquivos via HTTP;
- Compartilhamento de arquivos via FTP.
Compartilhamento de arquivos via FTP e HTTP |
---|
Disponibilização de arquivos via ApacheAs configurações padrões do Apache já fazem com que ele possa disponibilizar arquivos para download via web. Para isso, faça o seguinte no Servidor 2 da equipe:
|
Aula 21 - 31/05/16: Conclusão FTP e revisão para a prova
FTP no Servidor |
---|
Foi inicialmente solicitado configurar um servidor FTP na máquina Servidor 2 de cada equipe. Devido a problemas com NAT, deve-se desinstalar o servidor FTP do Servidor 2 e instalá-lo e configurá-lo no Servidor 1. |
Aula 22 - 03/06/16: Avaliação individual
Avaliação individual prática e teórica dos seguintes conteúdos:
Conteúdos:
- Apache;
- DNS;
- FTP.
Aula 23 - 06/06/16: Firewall
Firewall | |||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Uma introdução ao iptables
Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:
Exemplos
|
Aula 24 - 10/06/16: Firewall - continuação
Firewall - continuação |
---|
Atividade1 - Conclusão da atividade iniciada aula passada; 2 - Atividade Valendo nota!!! Cada grupo deve estudar quais regras de firewall querem implementar em seu cenário. Após isso, devem ser implementadas e testadas tais regras. Também deverão existir algumas regras pré determinadas:
Cada grupo deverá gerar um relatório especificando tudo que foi implementado em relação ao firewall em seu servidor. Além disso, devem ser detalhadas todas as demais configurações que foram necessárias para que o cenário com firewall fosse desenvolvido (como roteamento, NAT, configuração de rede local). Deverá ser entregue um relatório em formato PDF contendo o máximo possível de informações a respeito do cenário montado, explicação e justificativa das regras criadas, logs e prints que sejam necessários para a demonstração da configuração e funcionamento. Data de entrega: 17/06/2016 |
Aula 25 - 14/06/16: Firewall - continuação
Firewall - continuação |
---|
Atividade - Valendo nota!!!
Deverá ser entregue um relatório em formato PDF contendo o máximo possível de informações a respeito do cenário montado, explicação e justificativa das regras criadas, logs e prints que sejam necessários para a demonstração da configuração e funcionamento. Data de entrega: 21/06/2016
sudo ifconfig eth1 10.1.X.Y/24
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
5 - Instalar o SSH server, caso ainda não esteja instalado; 6 - Fazer os redirecionamentos de porta necessários.
sudo ifconfig eth0 10.1.X.Z/24
sudo route add default gw 10.1.X.Y
3 - Configurar o DNS como 200.135.37.65; 4 - Instalar o SSH server, caso ainda não esteja instalado; 5 - Instalar o servidor APACHE, caso ainda não esteja instalado.
sudo ifconfig eth0 10.1.X.Z/24
sudo route add default gw 10.1.X.Y
3 - Configurar o DNS como 200.135.37.65. |
Aula 26 - 17/06/16: Firewall - Conclusão da atividade
Aula 27 - 21/06/16: Postfix
Postfix |
---|
O correio eletrônico (email) é um dos principais serviços na Internet. De fato foi o primeiro serviço a ser usado em larga escala. Trata-se de um método para intercâmbio de mensagens digitais. Os sistemas de correio eletrônico se baseiam em um modelo armazena-e-encaminha (store-and-forward) em que os servidores de email aceitam, encaminham, entregam e armazenam mensagens de usuários. Uma mensagem de correio eletrônico se divide em duas partes:
From: Roberto de Matos <roberto@eel.ufsc.br>
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Smtp-Server: smtp.ufsc.br:roberto.matos@posgrad.ufsc.br
Subject: =?iso-8859-1?Q?Teste_Ger=EAncia?=
Message-Id: <0595A764-EEAE-41E7-99F0-80DC11FB5327@eel.ufsc.br>
X-Universally-Unique-Identifier: 684c3833-bbbe-420b-8b66-d92d9a419bc0
Date: Wed, 20 Nov 2013 11:36:35 -0200
To: Roberto de Matos <roberto.matos@ifsc.edu.br>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Ol=E1 Pessoal,
Hoje vamos aprender o funcionamento do Email!!
Abra=E7o,
Roberto=
Na mensagem acima, os cabeçalhos são as linhas iniciais. Os cabeçalhos terminam quando aparece uma linha em branco, a partir de que começa o corpo da mensagem. Funcionamento do emailOs componentes da infraestrutura de email são:
A figura abaixo ilustra uma infraestrutura de email típica. Os protocolos envolvidos são:
EndereçamentoEndereços de email estão intimamente ligados ao DNS. Cada usuário de email possui um endereço único mundial, definido por um identificador de usuário e um domínio de email, escritos usando-se o símbolo especial @ (lê-se at, do original em inglês) para conectá-los: tele@ifsc.edu.br Nesse exemplo, o identificador de usuário é tele, e o domínio é ifsc.edu.br. Os domínios de email tem correspondência direta com domínios DNS. De fato, para criar um domínio de email deve-se primeiro criá-lo no DNS. Além disto, o domínio DNS deve ter associado a si um ou mais registros MX (Mail exchanger) para apontar os MTAs responsáveis por receber emails para o domínio. Por exemplo, o domínio DNS ifsc.edu.br possui esse registro MX: > dig ifsc.edu.br mx
;; QUESTION SECTION:
;ifsc.edu.br. IN MX
;; ANSWER SECTION:
ifsc.edu.br. 3581 IN MX 5 hermes.ifsc.edu.br.
... e o domínio gmail.com: > dig gmail.com mx
;; QUESTION SECTION:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
MTA PostfixO primeiro software MTA usado em larga escala na Internet foi o sendmail. Esse MTA possui muitas funcionalidades, e enfatiza a flexibilidade em sua configuração. No entanto, configurá-lo e ajustá-lo não é tarefa fácil. Além disto, houve vários problemas de segurança no passado envolvendo esse software. Assim outras propostas surgiram, como qmail e postfix. Tanto qmail quanto postfix nasceram como projetos preocupados com a segurança nas operações de um MTA, e também se apresentaram como MTAs mais simples de configurar e operar. Em nossas aulas será usado o postfix, mas recomenda-se experimentar usar as outras duas opcões citadas. O postfix é um MTA modularizado, que divide as tarefas de processamento das mensagens em diversos componentes que rodam como processos separados. ConfiguraçãoA configuração do postfix é armazenada em arquivos, que normalmente residem no diretório /etc/postfix. Os dois principais são:
No Ubuntu deve-se iniciar o uso do Postfix com esses comandos: apt-get install -y postfix
# O comando abaixo deve ser usado se o postfix já foi instalado, mas deseja-se recriar sua configuração
dpkg-reconfigure postfix
As configurações iniciais informadas na instalação são suficientes para que o postfix possa ser iniciado. No entanto muitos detalhes provavelmente precisarão ser ajustados para que ele opere como desejado. Para um rápido teste do postfix pode-se fazer a sequência abaixo: > sudo service postfix restart
> telnet localhost 25
220 ger ESMTP postfix (Ubuntu)
helo mail
250 ger
mail from: aluno@ifsc.edu.br
250 2.1.0 OK
rcpt to: postmaster@ger.edu.br
250 2.1.5 OK
data
354 End data with <CR><LF>.<CR><LF>
subject: Teste
blabla
.
250 2.0.0 OK: queued as 71259CCA3
quit
221 2.0.0 Bye
Connection closed by foreign host
>
O resultado do teste (a mensagem entreguepara o usuário postmaster) pode ser visto no arquivo de log do postfix. No Ubuntu esse arquivo é /var/log/mail.log : > tail /var/log/mail.log
May 2 17:29:42 ger postfix/smtpd[1965]: 71259CCA3: client=localhost[127.0.0.1]
May 2 17:30:48 ger postfix/cleanup[1970]: 71259CCA3: message-id=<20100502202942.71259CCA3@ger>
May 2 17:30:48 ger postfix/qmgr[1894]: 71259CCA3: from=<aluno@ifsc.edu.br>, size=323, nrcpt=1 (queue active)
May 2 17:30:48 ger postfix/local[1972]: 71259CCA3: to=<root@ger.edu.br>, orig_to=<postmaster@ger.edu.br>, relay=local, delay=102, delays=102/0.05/0/0.03, dsn=2.0.0, status=sent (delivered to mailbox)
May 2 17:30:48 ger postfix/qmgr[1894]: 71259CCA3: removed
May 2 17:31:25 ger postfix/smtpd[1965]: disconnect from localhost[127.0.0.1]
>
A mensagem de teste foi entregue em /var/mail/root: > sudo cat /var/mail/root
From aluno@ifsc.edu.br Sun May 2 17:30:48 2010
Return-Path: <aluno@ifsc.edu.br>
X-Original-To: postmaster@ger.edu.br
Delivered-To: postmaster@ger.edu.br
Received: from mail (localhost [127.0.0.1])
by ger (Postfix) with SMTP id 71259CCA3
for <postmaster@ger.edu.br>; Sun, 2 May 2010 17:29:06 -0300 (BRT)
Subject: teste
Message-Id: <20100502202942.71259CCA3@ger>
Date: Sun, 2 May 2010 17:29:06 -0300 (BRT)
From: aluno@ifsc.edu.br
To: undisclosed-recipients:;
blabla
Outra maneira para testar e um pouco mais amigável é utilizar a ferramenta mail. Instale o pacote: apt-get install mailutils Para enviar uma mensagem proceda do seguinte modo:
|
Aula 28 - 24/06/16: POP e IMAP
POP e IMAP |
---|
Na Aula 17 instalamos e testamos o Servidor de e-mail Postfix. Com ele pudemos testar o envio de e-mails utilizando o protocolo SMTP. Agora queremos, também, instalar e testar o acesso dos usuários às suas caixas de e-mail. Para isso, é necessário os protocolos POP3 e IMAP. Com estes dois protocolos poderemos acessar as contas de e-mails dos usuários tanto com clientes instalados na máquina (Mozilla Thunderbird, Outlook Express, etc) como através de Webmails. Instalação POP/IMAP e testesExecutar os passos seguintes nas máquinas virtuais. Utilizaremos a máquina virtual server para instalar os serviços e a cliente para configurar os clientes de e-mail e demais testes.
|
Recuperação Avaliação 2 |
---|
Esta é uma atividade de recuperação extra para aqueles que não atingiram a média na Avaliação 2 (DNS, Apache e FTP). A nota desta atividade será somada a nota tirada na Avaliação 2 (dia 03/06) e feito a média aritmética das duas. Esta média substituirá a nota tirada na Avaliação 2. Os alunos devem atender aos seguintes pontos:
|
Aula 29 - 28/06/16: Atividades de preparação para a Avaliação 3
Atividades |
---|
Atividade sobre firewall com iptablesPara esta atividade se utilizará a rede apresentada na figura abaixo:
Atividade SMTP/POP/IMAPRepetir as atividades propostas nas Aulas 27 e 28. |
Aula 30 - 01/07/16: Avaliação 3
Na Aula 30 será feita apenas uma avaliação prática que abordará os seguintes itens:
- Firewall;
- Postfix;
- POP e IMAP.
No entanto, a nota da Avaliação 3 será composta da seguinte maneira:
- 50% - Avaliação 3;
- 50% - Relatório sobre regras de firewall.
Aula 31 - 05/07/16: Avaliação 3
Aula 32 - 08/07/16: LAN Ethernet
LAN |
---|
Local Area NetworkLAN é um acrônimo para Local Area Network que em português é chamada de Rede de Área Local ou simplesmente Rede local. Por LAN define-se uma rede de computadores desenvolvida para cobrir regiões geograficamente pequenas, como escritórios, andares de um edifício ou até mesmo um edifício. Elas cobrem uma área geográfica de até 1 Km, acima disso são chamadas MAN (Metropolitan Área Network). A nível de enlace o padrão IEEE 802.3 (Ethernet) e o padrão IEEE 802.11 (Wi-Fi) são os mais utilizados. O padrão ethetnet e o Wi-Fi especificam a camada de enlace e a camada física de uma rede.
Além desta forma de conexão representar um claro problema de segurança, um único cabo de comunicação compartilhado como este também fazia com que a largura de banda deste cabo fosse compartilhada com todas as máquinas a ele conectadas. Desta forma, o tráfego poderia se tornar bastante lento. Neste tipo de conexão compartilhada também há disputa pelo acesso ao meio de transmissão o que pode acarretar em colisões entre dados transmitidos ao mesmo tempo entre duas máquinas diferentes. Quando colisões ocorrem os dados transmitidos pelas duas fontes são perdidos e necessitam ser retransmitidos. Para se minimizar a incidência de colisões este padrão utilizava técnicas de controle de acesso ao meio, onde cada máquina deveria determinadas regras para poder acessar o meio e transmitir suas informações. Hoje a Ethernet funciona principalmente através de switches (ou comutador) com uma topologia não mais em barramento, mas em estrela onde o switch recebe todo o tráfego da rede e o encaminha. A principal vantagem de se usar uma rede Ethernet comutada é o isolamento dos domínios de colisão, causando menos colisão no meio compartilhado e melhorando o desempenho da rede como um todo. Numa primeira fase (antes do switch saber quem tem ligado a ele), quando um switch recebe informação numa determinada porta, transmite esse mesma informação por todas as outras portas, excepto por aquela que recebeu essa informação (flood). No entanto, ao contrário dos Hubs, os switchs registam o endereço MAC dos dispositivos que estão ligados a cada porta do equipamento. Sempre que um equipamento envia uma frame (quadro), o switch analisa o endereço MAC de destino e comuta a frame para a porta onde se encontra a máquina de destino. Desta forma, numa rede Ethernet, o switch não necessita de propagar a informação por todas as portas, sendo esta directamente enviada (com base na informação da tabela MAC do switch) para a máquina de destino (FONTE: [[2]]).
Redes virtuais operam na camada 2 do modelo OSI. No entanto, uma VLAN geralmente é configurada para mapear diretamente uma rede ou sub-rede IP, o que dá a impressão que a camada 3 está envolvida. Um exemplo de VLAN é dado abaixo:
Atividade Desenvolver atividades utilizando o Switch TP-Link TL-SG3210 Arquivo:TL-SG3210 User Guide.pdfArquivo:TL-SG3210 CLI Reference Guide.pdf |
Aula 33 - 12/07/16: IEEE802.11/Radius
Radius |
---|
RadiusRemote Authentication Dial In User Service (RADIUS) é um protocolo de rede que provê de forma centralizada autenticação, autorização e contabilização(Accounting em inglês) no processo de gerenciar computadores que estarão se conectando e usando um determinado serviço de rede. O protocolo RADIUS foi desenvolvido pela Livingston Enterprises, Inc., em 1991 para acesso a servidores de autenticação e protocolos de contabilização, sendo mais tarde introduzido como padrão do Internet Engineering Task Force (IETF).1 Por causa do amplo apoio e da forte presença do protocolo RADIUS, ele é muito usado por ISP's nas empresas no gerenciamento de acesso a internet ou intranet, e também é integrado a serviços de e-mail. Algumas dessas redes podem incorporar o protocolo em suas implementações. Como por exemplo modens, DSL, ponto de acesso wireless, VPN's, servidores WEB e etc. 2 RADIUS é um protocolo do tipo cliente/servidor que roda como um protocolo da camada de aplicação, usa como apoio o protocolo de transferência UDP. Tanto Servidores de Acesso Remoto(RAS), como servidores de Redes Virtuais Privadas(VPNs) e Servidores de Acesso a Rede(NAS), e todos os gateways que controlam o acesso a rede possuem um componente cliente do protocolo RADIUS que se comunica com o servidor RADIUS. Este servidor normalmente é um processo de background rodando no UNIX ou Microsoft Windows server.3
1. autenticação de usuários ou dispositivos antes da concessão de acesso a rede. 2. autorização de outros usuários ou dispositivos a usar determinados serviços providos pela rede. 3. para informar sobre o uso de outros serviços.
A variável não possui um nome e sim um número. A relação entre este número e seu nome é obtida através de dicionários. Exemplo de dicionário padrão: ATTRIBUTE User-Name 1 string
ATTRIBUTE Password 2 string
ATTRIBUTE CHAP-Password 3 string
ATTRIBUTE NAS-IP-Address 4 ipaddr
ATTRIBUTE NAS-Port-Id 5 intege
ATTRIBUTE Service-Type 6 integer
ATTRIBUTE Framed-Protocol 7 integer
ATTRIBUTE Framed-IP-Address 8 ipaddr
ATTRIBUTE Framed-IP-Netmask 9 ipaddr
O RADIUS tem uma porta para autenticação (UDP 1645 ou UDP 1812) e outra para contabilidade (UDP 1646 ou UDP 1813).
Cliente: é o host que deseja usufruir de um recurso da rede, como por exemplo, uma estação que deseja se associar a um Access Point.
AtividadeO Radius pode ser utilizado com um banco de dados LDAP, para que o mesmo busque usuário e senha ou pode-se usar o arquivo de texto users da mesma forma determinando usuário e senha. Utilizaremos o arquivo de texto users devido a facilidade de implementar. Procedimento no AP (Access Point) Edimax:
|
Aula 34 - 15/07/16: ADSL e PPPoE
PPPoE |
---|
PPPoE (PPP over Ethernet)PPPoE define um método para encapsular quadros PPP dentro de quadros Ethernet, e foi definido na RFC 2516. Ele foi criado para facilitar a integração de usuários discados e banda-larga em provedores de acesso (ISP - Internet Service Providers). Além disso, torna mais fácil o controle de acesso, de uso da rede, e contabilização para usuários que a acessam via rede Ethernet. Assim, é possível implantar uma rede em que os usuários, para conseguirem acesso, precisam se autenticar como em um serviço discado. Uma vez obtido o acesso, pode-se também impor limitações de uso de banda de acordo com o usuário. Exemplos de infraestruturas que podem se beneficiar com essa técnica são redes de condomínios e de prédios comerciais. Finalmente, PPPoE é usado como protocolo de enlace em acessos aDSL, ilustrado na figura abaixo.
Em um enlace PPPoE um dos nodos é o host (cliente), e o outro o concentrador de acesso (AC, que tem papel de servidor). O estabelecimento do enlace é iniciado pelo host, que procura um AC e em seguida solicita o início do enlace. Esse procedimento é composto por por dois estágios:
AtividadeA atividade a ser executada sobre enlace PPPoE é ilustrada na figura abaixo:
|
ADSL |
---|
ADSLADSL (Asymetric Digital Subscriber Line) é uma tecnologia para provimento de enlace de dados para assinantes de linhas telefônicas residenciais. Ao contrário da modems analógicos (ex: V.92), ADSL não está limitado à largura de banda de canal de voz (~ 4kHz). Com isso, podem-se obter taxas de dados muito superiores, dependendo da versão de ADSL em uso. Comparada a outras formas de DSL, o ADSL tem a característica de que os dados podem ser transmitidos mais rapidamente em uma direção do que na outra, assimetricamente, diferenciando-o de outros formatos. Os provedores geralmente anunciam o ADSL como um serviço para as pessoas conectarem-se à Internet do seguinte modo: o canal de comunicação é mais amplo e rápido para receber(download) e menor e mais lento para enviar(upload).
DSL. O Modem pode operar basicamente de duas formas: como roteador ou como bridge. Quando funciona como roteador, o modem possui recursos internos para estabelecer a conexão lógica com o AC. Quando funciona como bridge, os recursos necessários para o estabelecimento de uma conexão lógica devem estar instalados no computador, como o protocolo PPPoE.
A parte da infraestrutura ADSL dentro da rede de dados da operadora inclui equipamentos DSLAM (muitos deles), um ou mais AC e as redes de comunicação para interligá-los. Note-se que quem dá acesso de fato à Internet é o AC. A figura abaixo ilustra esses componentes. O enlace de dados entre o equipamento do assinante e a rede da operadora pode ser feita de diferentes formas. Esse enlace é visto pelo assinante como seu enlace para a Internet - i.e. ele obtém seu endereço IP fornecido pela operadora. Os tipos de enlace de dados ADSL mais usados são:
O enlace PPPoE funciona como se tivesse um link ponto-a-ponto entre o roteador ADSL e um concentrador de acesso (AC). Quer dizer, parece que existe um fio ligando diretamente esses dois equipamentos, apesar de na realidade existir toda uma infraestrutura entre os dois. Isso pode ser visualizado na figura abaixo. Em cada ponta desse link PPPoE há um endereço IP usado pelos respectivos equipamentos. ATIVIDADECada equipe deve estabelecer seu enlace WAN usando ADSL. Em seguida, fazer testes diversos afim de testar a conectividade de sua rede. Configurações ADSLCada link ADSL deve ter seu IP manualmente configurado, o qual deve ser um IP válido fornecido à equipe pelo provedor (professores). Os seguintes parâmetros dos modems ADSL devem ter estes valores:
|