terça-feira, 14 de fevereiro de 2017

Protocolos CDP e LLDP de Descoberta de Vizinhos

Olá Pessoal,

Os protocolos CDP e LLDP são utilizados para comunicação layer-2 entre dispositivos da infraestrutura de uma rede de computadores com a finalidade de descoberta dos vizinhos diretamente conectados. Como ambos os protocolos operam na camada de enlace, os dispositivos sequer precisam ser configurados com um endereço IP para trocarem quadros com informações que permitam sua descoberta na rede de maneira dinâmica. A boa notícia é que ambos os protocolos são extremamente simples de comprender e ainda mais fáceis de configurar! Se você já sabe operar o CDP, então operar o LLDP será tão simples quanto.

O CDP (Cisco Discovery Protocol) é um protocolo proprietário da Cisco e provavelmente um conhecido há anos daqueles que estudam para o exame de certificação CCNA. Outro protocolo que tem exatamente a mesma finalidade é o LLDP (Link-Layer Discovery Protocol) com a diferença de ser um padrão da indústria (IEEE 802.1AB) que pode ser implementado por qualquer fabricante, o que faz dele uma solução bem mais flexível do que o CDP em ambientes com dispositivos de múltiplos fabricantes.  Aqueles que estão estudando para o exame CCNA já devem saber que recentemente o LLDP passou a integrar o componente curricular do novo exame. 

Para praticar os procedimentos de configuração dos protocolos CDP e LLDP o leitor pode construir qualquer cenário com roteadores e switches no simulador Cisco Packet Tracer. Para exemplificar a configuração, irei me basear na simples topologia apresentada abaixo, em que temos um roteador diretamente conectado a outros dois switches que também estão conectados entre si.


Configuração do Cisco Discovery Protocol (CDP)

O CDP já vem habilitado por padrão nas caixas da Cisco, o que é útil para soluções que integram uma infraestrutura totalmente baseada em dispositivos Cisco, por exemplo entre telefones IP e switches Catalyst que se beneficiam da troca de informações da VLAN auxiliar de voz. No entanto, é importante estar atento que são muitas as situações em que é melhor desativar o CDP nas interfaces em que não desejamos que dispositivos vizinhos possam visualizar informações sobre um determinado equipamento, já que a divulgação pode facilitar o processo de descoberta de informações por pessoas não autorizadas. 

É possível desativar globalmente o CDP através do comando destacado em amarelo:

Router(config)# no cdp run
Router(config)# exit
Router# show cdp
% CDP is not enabled

Outra é possível é desativá-lo apenas em alguma(s) interface(s):

Router(config)# interface g0/0
Router(config-if)# no cdp enable

Como o CDP já vem habilitado por padrão, o comando "show cdp neighbors" pode ser utilizado nas caixas para exibir um resumo dos vizinhos diretamente conectados. Esse comando permite identificar qual(is) dispositivo(s) estão diretamente conectados em qual(is) interface(s) do dispositivo local. Caso o administrador queira obter informações mais detalhadas sobre os vizinhos, a palavra detail pode ser adicionada ao comando (show cdp neighbors detail). 

O CDP pode ser bastante útil em ambientes pequenos e médios que não possuem documentação atualizada da sua infraestrutura de redes. A partir de um dispositivo qualquer na infraestrutura é possível identificar os links para seus vizinhos e através do acesso sucessivo aos vizinhos é possível identificar todos os demais vizinhos sob a referência do dispositivo seguinte, de maneira que ao final o administrador terá em mãos a topologia completa da rede.  A propósito, um bom exercício é o leitor utilizar as informações abaixo para desenhar a topologia da rede. 

Observe que a partir do Router é possível identificar que diretamente conectado nele temos o Switch1 e Switch2. Na sequência, a partir do Switch1 podemos confirmar o link anterior para o Router, além de um link adicional para o Switch2. Continuando, no Switch2 podemos confirmar os links para o Router e Switch1. Ao final vocês serão capazes de chegar exatamente na topologia apresentada na figura anterior. Simples assim e bastante útil, não é mesmo?

Router> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch1      Gig 0/0          166            S       2960        Gig 0/1
Switch2      Gig 0/1          166            S       2960        Gig 0/1


Switch1> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch2      Gig 0/2          153            S       2960        Gig 0/2
Router       Gig 0/1          125            R       C2900       Gig 0/0


Switch2> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch1      Gig 0/2          124            S       2960        Gig 0/2
Router       Gig 0/1          157            R       C2900       Gig 0/1



Configuração do Link-Layer Discovery Protocol (LLDP)

Ao contrário do CDP que vem habilitado por padrão nas caixas da Cisco, o LLDP precisa ser habilitado manualmente pelo administrador antes de interagir com outros equipamentos com o protocolo aberto. Nada de mais nesse ponto, visto que sua ativação global em todas as interfaces é bem simples, conforme pode ser observado no comando destacado em amarelo:

Router# show lldp
% LLDP is not enabled
Router# configure terminal
Router(config)# lldp run
Router(config)# exit
Router# show lldp

Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds  

Depois de habilitado, o LLDP pode exibir as informações simplificadas dos seus vizinhos exatamente da mesma forma que foi feito anteriormente com o CDP, mudando apenas a palavra CDP por LLDP na linha de comando. A mesma regra vale para exibir informações detalhadas em que basta adicionar a palavra detail no comando de consulta dos vizinhos.  

Router# show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Switch1             Gig0/0         120        B               Gig0/1
Switch2             Gig0/1         120        B               Gig0/1

Total entries displayed: 2

Router# show lldp neighbors detail
(...) Saída Omitida 


Na realidade o LLDP permite que o administrador possa personalizar sua operação com mais opções do que o CDP. Por exemplo, com LLDP é possível definir quais informações um dispositivo deve ou não deve enviar para seus vizinhos através de atributos de controle, tamanho e valor (TLV). 

Router(config)# lldp tlv-select ?
    mac-phy-cfg           IEEE 802.3 MAC/Phy Configuration/status TLV
    management-address    Management Address TLV
    port-description      Port Description TLV
    port-vlan             Port VLAN ID
    power-management      IEEE 802.3 DTE Power via MDI TLV
    system-capbilities    System Capabilities TLV
    system-description    System Description TLV
    system-name           System NAME TLV 
 
Assim como o CDP, também é possível desativar o LLDP apenas em alguma(s) interface(s) em que não desejamos a troca de informações do dispositvo com seus vizinhos diretamente conectados. Para desativar o protocolo em uma interface específica devem ser utilizados os comandos abaixo:

Router(config)# interface g0/0
Router(config-if)# no lldp receive
Router(config-if)# no lldp transmit

Façam seus testes...

Samuel.

sexta-feira, 3 de fevereiro de 2017

Níveis de Privilégio no Sistema Cisco IOS

Olá Pessoal,

Um conceito básico que todos aprendem logo no primeiro contato com o sistema IOS utilizado em switches e roteadores da Cisco são os níveis de privilégio. A maioria dos profissionais já sabe que por padrão existe o modo de execução (nível 1) em que o usuário somente tem acesso à visualização de alguns comandos básicos sem nenhuma permissão de executar qualquer configuração no dispositivo, além do modo privilegiado (nível 15) que permite a visualização e configuração de todos os recursos do sistema (equivalente ao usuário root no Linux).

Se os níveis padrões são identificados pelos números 1 e 15, é de se esperar que os números intermediários tenham algum significado, não é mesmo? E eles têm, já que o IOS permite a definição de até 16 níveis de privilégio variando de 0 a 15, sendo 0 o mais restritivo e 15 o mais permissivo. Esse detalhe acaba se tornando apenas secundário porque é comum utilizar o comando enable assim que o administrador faz acesso a um dispositivo para obter acesso pleno a todas as configurações, o que torna desnecessário qualquer outro modo intermediário.  


No entanto, em ambientes maiores que possuem muitos equipamentos e diversos técnicos e engenheiros responsáveis pelas configurações das caixas, é natural segregar o pessoal em grupos homogêneos que tenham diferentes privilégios de acesso com o objetivo de restringir a atuação de cada grupo dentro do escopo da sua função. Por exemplo, é prática gerencial bastante comum classificar o pessoal técnico em níveis 1 (entrada), 2 (intermediário) e 3 (avançado), de maneira que os chamados sejam associados com cada nível em função da sua natureza. 

Nesses casos é bastante útil ter a flexibilidade de criar mais níveis de privilégios para esses grupos, ao invés de ficar limitado apenas aos dois níveis padrões 1 e 15, já que o nível 1 tem apenas acesso básico a visualização de poucas configurações e que o nível 15 representa o extremo oposto em que o técnico pode realizar qualquer intervenção na caixa. A ideia dos níveis intermediários é conferir acesso apenas a comandos específicos que um determinado grupo de usuários requer para executar suas funções. Quando criamos um usuário em uma base local que fica armazenada no próprio equipamento switch ou roteador, estamos habituados a fazê-lo da seguinte maneira:

Roteador(config)# line console 0
Roteador(config-line)# login local
Roteador(config-line)# line vty 0 4
Roteador(config-line)# login local
Roteador(config-line)# exit
Roteador(config)# username ADMIN privilege 15 secret SENHA

Utilizamos a configuração "login local" no acesso via console e nas primeiras 5 sessões remotas (vty 0 4) para forçar que seja realizada a autenticação do usuário antes de liberação do acesso, lembrando que o modo padrão (login) consiste apenas em senha sem usuário. O comando destacado em amarelo cria um usuário denominado ADMIN com permissão privilegiada (nível 15), sendo que SENHA é sua senha! A criação de usuários com níveis intermediários de privilégio é tão simples quanto o procedimento anterior, bastando alterar o número do privilégio.

No entanto, de nada adianta alocar um usuário com um nível de privilégio que não teve nenhum comando adicionado pelo administrador naquele nível específico, ou seja, é necessário informar quais comandos ele poderá executar. No exemplo abaixo criaremos um usuário denominado OPERADOR_2 com nível de privilégio 9, de modo que esse usuário será capaz de executar qualquer comando que tenha sido previamente associado pelo administrador com o nível 9 (incluindo os comandos de 0 a 8). Observem nas próximas linhas que a permissão de visualização do arquivo startup-config será restrita apenas aos usuários de nível intermediário 9, ou seja, somente os usuários dos níveis 9 até 15 poderão visualizar todas as configurações que são inicializadas com o equipamento. 

Roteador(config)# username OPERADOR_2 privilege 9 secret SENHA_9
Roteador(config)# privilege exec level 9 show startup-config

Como são várias as possibilidades para personalizar os níveis intermediários, abaixo trago outro exemplo em que é criado o usuário OPERADOR_1 de nível 6. Esse nível permite a configuração simples de endereços IPv4 e IPv6 nas interfaces de rede, inclusive com possibilidade de ativá-las (no shutdown) ou desativá-las (shutdown). Reparem que o segundo termo da sintaxe do comando privilege remete ao modo ou sub-modo de configuração de pertença do comando. Por exemplo, é no sub-modo de configuração de interface (amarelo) onde são configurados os endereços IP e ativadas/desativadas as interfaces.

Roteador(config)# username OPERADOR_1 privilege 6 secret SENHA_6
Roteador(config)# privilege exec level 6 configure terminal
Roteador(config)# privilege configure level 6 interface
Roteador(config)# privilege interface level 6 ip address 
Roteador(config)# privilege interface level 6 ipv6 address
Roteador(config)# privilege interface level 6 no ip address
Roteador(config)# privilege interface level 6 no ipv6 address
Roteador(config)# privilege interface level 6 shutdown
Roteador(config)# privilege interface level 6 no shutdown

Por fim, é importante ter em mente que o usuário pode utilizar o comando "show privilege" para visualizar o nível de privilégio do usuário em que ele está logado no sistema. 

Roteador> show privilege
Current privilege level is 1

Roteador# show privilege
Current privilege level is 15
  
Para que qualquer usuário possa ter permissão para visualizar seu nível de privilégio através do comando anterior, além de ter acesso a todos os demais comandos de visualização do modo padrão de execução (nível 1), podem ser utilizados os seguintes comandos:

Roteador(config)# privilege exec level 1 show privilege
Roteador(config)# privilege exec level 1 show

Como há muitos mais detalhes envolvidos com a configuração dos níveis intermediários de privilégio no sistema IOS, recomendo para aqueles interessados no assunto que façam a leitura da documentação oficial da Cisco no link abaixo:


Façam seus testes...

Samuel.

terça-feira, 17 de janeiro de 2017

Configuração de Link P2P em Bridge no Cisco Aironet

Olá Pessoal,

Tradicionalmente os dispositivos Access Point (AP) são utilizados como concentradores em redes sem fio com o propósito de viabilizar uma célula em seu entorno com área de cobertura para que haja comunicação com múltiplos dispositivos clientes de modo ponto-a-multiponto, motivo pelo qual os APs são equipados com antenas omnidirecionais com largura de feixe de 360° no plano horizontal (azimute). Apesar dessa ser a aplicação mais comum, há casos em que é necessário alterar esse comportamento convencional de modo a configurar dois APs em bridge para viabilizar a comunicação ponto-a-ponto, por exemplo na interligação sem fio à distância entre duas unidades remotas de uma empresa (vide figura). 

Nesses casos são acopladas nos APs antenas externas que tenham menor largura de feixe e com maior ganho (dBi) em uma determinada direção. A escolha da antena direcionada mais adequada vai depender da distância entre as duas unidades remotas, destacando que quanto maior o ganho da antena, maior será seu alcance e menor será a largura do feixe no plano horizontal. Por exemplo, antenas parabólicas são as que têm maior ganho (de 20 a 30 dBi) e podem alcançar vários quilômetros de distância (por volta de 50km), dependendo da obstrução no caminho entre as antenas. 


Obs.: Esteja ciente de que antenas parabólicas de alto ganho não devem ser utilizadas sem que o enlace de radiofrequência tenha sido devidamente projetado para irradiar sinal efetivo (EIRP) dentro dos limites legais do seu domínio regulatório, levando em consideração a potência de transmissão, a perda no cabo e demais componentes e o ganho da antena. Conforme Resolução 506/2008 da Anatel, no Brasil o EIRP máximo permitido na frequência de 2,4GHz é de até 30dBm (1000mW) em cidades com até 500.000 habitantes ou de até 26dBm (400mW) em cidades com mais de 500.000 habitantes. Qualquer enlace que esteja operando acima desses parâmetros deve ser licenciado junto à agência. 

O objetivo deste artigo é listar os passos necessários para configurar dois Aironet da Cisco em modo bridge para que seja possível estabelecer um enlace ponto-a-ponto entre duas unidades remotas, com base no cenário apresentado na figura anterior. Repare que as duas unidades pertencem à mesma sub-rede lógica em camada 3 (rede), o que deixa evidente que a conexão em modo bridge nada mais é do que uma ligação em camada 2 (enlace). É como se os APs fossem switches nas unidades remotas que estivessem interligados através de um cabo. Ocorre que na maioria dos casos não é possível fazer a passagem dos  cabos na via pública e a locação de um link dedicado não é barato (quando há disponibilidade no local), então fazer essa ligação através do meio não-guiado (wireless) acaba sendo uma opção atrativa.

Obs.: Também é possível isolar cada unidade em sua respectiva sub-rede lógica (camada 3). Nesse caso, o link ponto-a-ponto entre os dois APs é configurado como sendo uma sub-rede /30 independente das outras duas sub-redes das unidades remotas, de forma que cada AP terá um dos IPs disponíveis na sub-rede /30. O AP de cada unidade remota será diretamente conectado em um roteador de borda, ao invés de um switch. Se essa estratégia for adotada, é importante ter em mente que nos roteadores de borda deverá ser adicionada uma rota para a sub-rede lógica da outra unidade. 

Abaixo o leitor encontra os comandos necessários para configurar ambos os APs através dá interface de linha de comando (CLI) do IOS. Observe que o AP-A foi definido como root bridge e que o AP-B foi definido como non-root bridge, sendo que o canal do enlace é definido apenas no AP raíz. Assim que o link for efetivamente estabelecido, o LED dos Aironet em ambas as unidades mudará sua cor de verde para azul, indicando que os dois APs estão associados entre si. 

AP-A(config)# interface bvi1
AP-A(config-if)# ip address 192.168.0.201 255.255.255.0
AP-A(config-if)# exit
AP-A(config)# ip default-gateway 192.168.0.1
AP-A(config)# dot11 ssid BRIDGE
AP-A(config-ssid)# authentication open
AP-A(config-ssid)# authentication key-management wpa ver 2
AP-A(config-ssid)# wpa-psk ascii PASSWORD
AP-A(config-ssid)# exit
AP-A(config)# interface dot11radio0
AP-A(config-if)# station-role root bridge
AP-A(config-if)# channel 6
AP-A(config-if)# encryption mode ciphers aes-ccm
AP-A(config-if)# ssid BRIDGE
AP-A(config-if)# no shut
AP-A(config-if)# end

AP-B(config)# interface bvi1
AP-B(config-if)# ip address 192.168.0.202 255.255.255.0
AP-B(config-if)# exit
AP-B(config)# ip default-gateway 192.168.0.1
AP-B(config)# dot11 ssid BRIDGE
AP-B(config-ssid)# authentication open
AP-B(config-ssid)# authentication key-management wpa ver 2
AP-B(config-ssid)# wpa-psk ascii PASSWORD
AP-B(config-ssid)# exit
AP-B(config)# interface dot11radio0
AP-B(config-if)# station-role non-root bridge
AP-B(config-if)# encryption mode ciphers aes-ccm
AP-B(config-if)# ssid BRIDGE
AP-B(config-if)# no shut
AP-B(config-if)# end

Façam seus testes...

Samuel.

quarta-feira, 11 de janeiro de 2017

Marcação DSCP e QoS em Roteadores Cisco

Olá Pessoal,

O modelo DiffServ de serviços diferenciados é flexível de acordo com o perfil das aplicações, uma abordagem alinhada com o conceito de nível de serviço (SLA) em que são previamente acordadas as classes de serviços com base em parâmetros como volume de tráfego, disponibilidade e outros que possam assegurar o desempenho adequado dos serviços em execução na infraestrutura de uma rede. O modelo DiffServ é o mais utilizado para implementar QoS porque exige menos dos roteadores do que o modelo IntServ de serviços integrados que requer protocolos inteligentes para que os roteadores possam providenciar a reserva prévia de recursos entre dois pontos (cliente/servidor). 

RFC 2597 e RFC 2598 descrevem, respectivamente, aquilo que é denominado Assured Forwarding (AF) e Expedited Forwarding (EF), ambos mecanismos de classificação de diferentes níveis de tráfego para serviços diferenciados no modelo DiffServ. Existem quatro classes AF que variam de AF1X até AF4X, sendo que o primeiro número é a prioridade da classe. Quanto maior o número de prioridade, então maior é a importância daquele perfil de tráfego no ambiente. O segundo número (representado por X) varia de 1 a 3 e diz respeito à preferência de descarte dos pacotes, sendo que números maiores têm maior probabilidade de serem descartados. Já a classe EF faz referência ao encaminhamento expresso, ou seja, aquele perfil de tráfego que possui baixa tolerência a qualquer tipo de atraso (tradicionalmente o tráfego de voz). A tabela abaixo traz um resumo de todas as combinações possíveis dos códigos das classes AF e EF.

|-----------------------------------------------------------------|
| Descarte | Classe 1 | Classe 2 | Classe 3 | Classe 4 | Expresso |
|-----------------------------------------------------------------|
| Baixo    |   AF11   |   AF21   |   AF31   |   AF41   |          |
| Médio    |   AF12   |   AF22   |   AF32   |   AF42   |    EF    |
| Alto     |   AF13   |   AF23   |   AF33   |   AF43   |          |
|----------|----------|----------|----------|----------|----------|

O modelo DiffServ propõe um sistema de códigos para classificação de tráfego que é denominado DSCP (DiffServ Code Point) e consiste em sobrescrever os primeiros 6 primeiros bits do campo ToS (Type of Service) do cabeçalho IP, Dessa maneira, cada código diz respeito a uma classe de tráfego que pode receber tratamento diferenciado pelo administrador. A figura abaixo traz um resumo de alguns dos principais códigos DSCP, inclusive com o mapeamento das principais classes AF/EF previamente apresentadas e sugestões de associações com aplicações típicas do cotidiano:

Fonte: Internet (sem especificação de autoria)  
É fato que no primeiro momento parece ser bastante informação teórica para assimilar, então aproveito o cenário simplista da topologia abaixo para exemplificar a configuração prática de alguns desses conceitos, particularmente em relação à marcação de pacotes de uma aplicação qualquer em execução na porta TCP/3050 com o código AF41 (ou DSCP 34) para fins de priorização desse tráfego, além de marcação de um host qualquer com o código AF13 de baixa prioridade.


O objetivo não é discutir cada uma das linhas abaixo com detalhes dos elementos de uma política de QoS, por isso recomendo a leitura do artigo intitulado "Policy-Map na Restrição da Taxa de Tráfego". Apenas vale relembrar que basicamente o processo de configuração de QoS em dispositivos Cisco consiste em três etapas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na entrada/saída de alguma interface.

!--- ACL 101 (Referente Tráfego do Host 192.168.0.109 (Host 109)
access-list 101 permit ip host 192.168.0.109 any
access-list 101 permit ip any host 192.168.0.109

!--- ACL 102 (Referente Tráfego do Servidor de Banco de Dados (Firebird)
access-list 102 permit tcp any any eq 3050
access-list 102 permit tcp any eq 3050 any

!--- Classificação do Tráfego da ACL 101 na Class-Map HOST-109
class-map match-all HOST-109
   match access-group 101
   exit

!--- Classificação do Tráfego da ACL 102 na Class-Map FIREBIRD
class-map match-all FIREBIRD
   match access-group 102
   exit

!--- Definição de Políticas na Policy-Map QOS
policy-map QOS
   class HOST-109
      set dscp af13
      police rate 256000 bps
      exit
   class FIREBIRD
      set dscp af41
      end

!--- Aplicação da Policy-Map na Saída da Interface F0/0
interface f0/0
   service-policy output QOS 

Nesse exemplo foram definidas duas class-map, uma vinculada à ACL 101 que faz referência ao host 192.168.0.109 (class-map HOST-109) e outra vinculada à ACL 102 que faz referência à aplicação TCP/3050 (class-map FIREBIRD). Observem que nesse exemplo é realizada apenas a marcação dos pacotes em um roteador isolado, sendo que sua utilização em cenário real também requer a leitura prévia dessa marcação para posterior aplicação de ações/políticas nos demais roteadores intermediários da rede.

Na sequência, a policy-map denominada QOS possui duas políticas, uma relacionada ao host 192.168.0.109 que marca seus pacotes com o código DSCP AF13 (baixa prioridade) e também aplica uma restrição de banda de apenas 256k; e outra relacionada a uma aplicação em execução na porta TCP/3050 que apenas faz a marcação dos seus pacotes com o código DSCP AF41 (alta prioridade) sem aplicar nenhuma outra ação. 

Por fim, o comando "show policy-map" pode ser utilizado para visualizar todas as políticas que foram configuradas em um determinado roteador da rede, lembrando que essas políticas são individuais de cada roteador (distribuídas), ainda que exista um esforço centralizado de definição dessas políticas no ambiente da empresa. Ou seja, é importante estar atento no momento de fazer as configurações das políticas de QoS nos roteadores da infraestrutura porque facilmente a escrita equivocada de regras pode implicar em roteadores contendo políticas contraditórias entre si (ambiguidade).

!---
!--- Visualização de Políticas Previamente Configuradas
!---
R1# show policy-map
  Policy Map QOS
    Class HOST-109
      set dscp af13
      police rate 256000 bps burst 8000 bytes
        conform-action transmit 
        exceed-action drop 
    Class FIREBIRD
      set dscp af41



Façam seus testes...

Samuel.

quarta-feira, 2 de novembro de 2016

Controlador de Domínio do SAMBA 4 no Debian GNU/Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração Básica do SAMBA em Servidores Linux" o leitor passou pela experiência básica de como fazer o simples compartilhamento de diretórios e arquivos através do SAMBA para integrar ambientes heterogêneos com máquinas Linux e Windows. No entanto, é importante destacar que o SAMBA 4 vai muito além do simples compartilhamento e permite que o servidor Linux assuma o papel de controlador de domínio (DC). Assim é possível ingressar máquinas Windows no serviço de diretório do servidor Linux para que a gerência dos objetos de um domínio (computadores, contas de usuários, políticas, etc) seja centralizada sem a necessidade do MS Windows Server, o que implica em economia na licença do sistema operacional do servidor e também da quantidade de clientes da rede (CAL).




O objetivo deste artigo é listar as etapas necessárias para instalar o SAMBA 4 (e seus complementos) para transformar um servidor Debian GNU/Linux no controlador do domínio denominado AULA.LOCAL. Nesse exemplo assumiremos que nosso controlador de domínio será configurado com o IP 192.168.221.1/24. Uma etapa preliminar é definir estaticamente no arquivo /etc/hosts o mapeamento do nome do servidor que posteriormente será configurado como controlador de domínio. Nessa etapa criaremos um mapeamento estático (NOME<>IP) em que o nome da máquina já será composto com o sufixo do domínio (FQDN) que será utilizado posteriormente. Por causa desse mapeamento o SAMBA irá sugerir o nome de domínio AULA.LOCAL durante sua instalação. 

###--- em /etc/hosts -------------------------
127.0.0.1       localhost
192.168.221.1   samba-dc   samba-dc.aula.local
###--- fim do arquivo ------------------------

1) Instalação do Servidor SAMBA DC

Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado samba para que o Linux possa ser posteriormente configurado como controlador de domínio. Também é necessário instalar vários pacotes com outros serviços, a exemplo do DNS (winbind), do Kerberos (krb5-user), etc. Apesar de ser bastante coisa, essa tarefa é simples e rápida através do APT:

root@samba-dc:/# apt-get update
root@samba-dc:/# apt-get install samba smbclient ntp krb5-user winbind ldap-utils acl attr

Durante a instalação irá aparecer um diálogo (modo texto) solicitando 3 informações:

- Nome do Domínio                               : AULA.LOCAL
- Endereço do Servidor Kerberos de Autenticação : 127.0.0.1
- Endereço do Servidor Administrativo           : 127.0.0.1

2) Configuração do NTP p/ Sincronização do Relógio das Máquinas

A próxima etapa é fazer alguns ajustes no serviço NTP responsável pela sincronização do relógio da máquina que será responsável por sincronizar os relógios de todas as demais máquinas do domínio. Depois de criado o diretório ntp_signd com as devidas permissões, é necessário adicionar algumas linhas ao final do arquivo de configuração localizado em /etc/ntp.conf.

root@samba-dc:/# install -d /var/lib/samba/ntp_signd/
root@samba-dc:/# chown root:ntp /var/lib/samba/ntp_signd
root@samba-dc:/# chmod 750 /var/lib/samba/ntp_signd/

###--- em /etc/ntp.conf ------------------------
(...) Conteúdo Omitido
### Adicionar Configuracoes Abaixo p/ SAMBA 4 DC
ntpsigndsocket /var/lib/samba/ntp_signd/
restrict default mssntp
disable monitor
###--- fim do arquivo --------------------------

Depois desses ajustes, basta reiniciar o serviço NTP:

root@samba-dc:/# service ntp restart

O status do serviço NTP pode ser verificado através dos seguintes comandos:

root@samba-dc:/# service ntp status
root@samba-dc:/# ntpq -p

3) Parada de Serviços em Execução

Antes de fazer a configuração do domínio propriamente dito através do processo de provisionamento do SAMBA, é necessário parar serviços que são automaticamente executados logo depois da instalação dos pacotes, além de "remover" o arquivo original de configuração do SAMBA (/etc/samba/smb.conf):

root@samba-dc:/# service smbd stop
root@samba-dc:/# service nmbd stop
root@samba-dc:/# service winbind stop
root@samba-dc:/# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

4) Provisionamento do Domínio

Uma das etapas mais importantes é o provisionamento do domínio em que serão utilizadas ferramentas automatizadas do próprio SAMBA para preparar nosso servidor como controlador do domínio AULA.LOCAL. A principal ferramenta é o comando samba-tool que serve como frontend responsável por manipular o OpenLDAP (backend), simplificando muito a tarefa de configuração. 

root@samba-dc:/# samba-tool domain provision --use-rfc2307 --interactive

Ao digitar o comandoo sistema irá indagá-lo e sugerir as seguintes configurações que podem ser aceitas através da tecla <ENTER>:

- Realm                       [AULA.LOCAL] 
- Domain                      [AULA]
- Server Role                 [DC]
- DNS Backend                 [SAMBA_INTERNAL]
- DNS Forwarder IP Address    (IP do DNS da REDE)
- Administrator Password      (SENHA FORTE)

Obs.: Os parâmetros trazidos nas chaves [] são sugeridos pelo samba-tool e podem ser aceitos. O servidor DNS integrado ao controlador de domínio será responsável pelos mapeamentos dos nomes na rede interna, de forma que todas as máquinas Windows a serem ingressadas no domínio devem ser configuradas para apontar seu DNS primário para o IP do servidor SAMBA (192.168.221.1). Caso exista(m) outro(s) servidor(es) DNS na rede (por ex. BIND), responsável por exemplo pelo mapeamento de nomes externos, pode ser feito o apontamento através do DNS Forwarder.

5) Ajustes Finais

É hora de fixar as configurações de DNS do servidor no arquivo /etc/resolv.conf e aplicar a característica de imutabilidade (+i) no mesmo para que seu conteúdo não seja mais dinamicamente atualizado. Também vamos copiar o template do arquivo de configuração do Kerberos que vem com o pacote samba (/var/lib/samba/private/krb5-conf) para o diretório /etc para que a autenticação no domínio possa funcionar. Por fim, vamos reiniciar o serviço do SAMBA como controlador de domínio.

###--- em /etc/resolv.conf ---
search aula.local
nameserver 192.168.221.1
###--- fim do arquivo --------

root@samba-dc:/# chattr +i /etc/resolv.conf
root@samba-dc:/# cp /var/lib/samba/private/krb5.conf /etc
root@samba-dc:/# service samba-ad-dc restart

6) Verificação

A primeira maneira de verificar se o SAMBA está em execução é:

root@samba-dc:/# service samba-ad-dc status
Active: active (running) since (...) 

Para fazer uma verificação mais apurada, vale testar a resolução de nomes internos de alguns registros automaticamente criados pelo controlador de domínio, além de testar a resolução de nomes externos:

root@samba-dc:/# host -t A aula.local
aula.local has address 192.168.221.1

root@samba-dc:/# host -t SRV _kerberos._udp.aula.local
_kerberos._udp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host -t SRV _ldap._tcp.aula.local
_kerberos._tcp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host www.debian.org
www.debian.org has address 200.17.202.197
www.debian.org has IPv6 address 2801:82:80ff:8009:e61f:13ff:fe63:8388

Finalmente vamos testar a autenticação do Kerberos:

root@samba-dc:/# kinit administrator@AULA.LOCAL
Password for administrator@AULA.LOCAL: <Senha do Administrador do Domínio>
Warning: Your password will expire in 41 days on (...)

root@samba-dc:/# klist
(...) Informações de Validade do Ticket (Kerberos)


7) Administração do Domínio

Pronto, o servidor SAMBA já está em operação como controlador do domínio AULA.LOCAL. A partir deste ponto o domínio pode ser administrador via interface de linha de comando (CLI) através da ferramenta samba-tool. São várias as opções para administração do domínio via samba-tool, por isso é recomendada a leitura do manual da ferramenta (man samba-tool). Abaixo trago uma breve relação de alguns dos comandos mais comuns:

samba-tool user list                  ### exibe todos os usuários do domínio
samba-tool user add <NOME>            ### adiciona um novo usuário
samba-tool user del <NOME>            ### remove um usuário existente
samba-tool user enable <NOME>         ### habilita um usuário desabilitado
samba-tool user disable <NOME>        ### desabilita uma conta de usuário

Caso algum usuário esqueça sua senha, o coomando abaixo pode ser utilizado para resetá-la de forma que o usuário seja obrigado a alterá-la no próximo login:

samba-tool user NOME --newpassword=SENHA --must-change-at-next-login  

Outra opção bastante atrativa é utilizar a ferramenta RSAT (Remote Server Administration Tools) que pode ser baixada gratuitamente na página da Microsoft e instalada em qualquer máquina executando o Windows (versões 7, 8 ou 10). A vantagem dessa abordagem é que a administração do domínio é feita pela mesma interface gráfica das tradicionais Ferramentas Administrativas do Windows Server, aproveitando todo o conhecimento do administrador. O RSAT pode ser baixado através dos links abaixo:

- Windows 7: https://www.microsoft.com/pt-br/download/details.aspx?id=7887 
- Windows 8: https://www.microsoft.com/pt-br/download/details.aspx?id=28972
- Windows X: https://www.microsoft.com/pt-BR/download/details.aspx?id=45520

Obs.: Depois de baixado o RSAT deve ser instalado no Windows e manualmente adicionado como recurso extra. Nos links oficiais da Microsoft onde o RSAT pode ser baixado o leitor encontra as instruções para instalação da ferramenta. 

Façam seus testes...

Samuel.

segunda-feira, 10 de outubro de 2016

Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)
Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)
/dev/sda2 > +/- 7.0 GB (/)
/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)
/dev/sdb2 > +/- 7.0 GB (/)
/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)
/dev/md1 = /dev/sda2 + /dev/sdb2 (/)
/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda
root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 
root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2
root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel.