Conexão Terminal em Dispositivos Cisco via Cabo USB

Olá Pessoal,

A maioria dos equipamentos de rede possui uma porta de console para permitir aquele primeiro acesso em que são realizadas as configurações iniciais do dispositivo de maneira out-of-bound, ou seja, uma conexão local direta à parte da rede local. Em dispositivos Cisco essa conexão tradicionalmente é feita através de algum aplicativo terminal, a exemplo do PuTTY ou do Screen, via conexão serial em uma porta de console com terminal RJ-45, em que utilizamos o cabo apresentado na figura 1a para esse fim.

Ocorre que praticamente todos os novos computadores não possuem uma porta serial (RS-232) como acontecia anos atrás, motivo pelo qual é necessário utilizar um adaptador USB-Serial (figura 1b) que é acoplado em uma porta USB do computador e, depois de instalados os devidos drivers, o sistema operacional passa a reconhecer uma interface serial (COM ou TTY).

Figura 1. Tipos de Cabos de Console (Clique p/ Ampliar)

Felizmente, já há alguns anos, os roteadores e switches da Cisco possuem, além da tradicional porta de console do tipo serial (terminal RJ-45), uma porta de console adicional do tipo mini-USB (figura 2), o que permite a utilização de um cabo USB convencional. Na relação de acessórios da Cisco, o referido cabo é denominado CISCO-CONSOLE-USB, mas na prática qualquer cabo USB que tenha um terminal USB Tipo-A e outro terminal do tipo mini-USB Tipo-B (figura 1c) é compatível.

Figura 2. Visão Traseira do Chassi de um Roteador Cisco 1905

Nas linhas abaixo trago um rápido guia de como realizar essa conexão terminal em roteadores, switches ou mesmo outras caixas da Cisco utilizando um cabo USB, ao invés do tradicional cabo de console serial. O procedimento é descrito para Linux, Mac OS X e Windows. 

---

Conexão Terminal via USB no Linux

No Linux não é necessário instalar nenhum driver para que o cabo USB possa ser utilizado como linha serial. Ao conectar o cabo no computador e no roteador/switch, o sistema operacional irá identificar o dispositivo e criar seu respectivo arquivo de sistema em /dev/ttyACM#, sendo que # é um número qualquer de indexação. Outra vantagem é que não é necessário instalar nenhum software terminal, uma vez que a maioria das distribuições Linux já possui o screen. Apesar disso, não há problema nenhum em utilizar qualquer outro software terminal de preferência do usuário.

root@Linux:~$ ls -ltr /dev/*ACM*
crw-rw---- 1 root dialout 166, 0 Jan   9 13:18 /dev/ttyACM0
root@Linux:~$ screen /dev/ttyACM0 9600
[screen is terminating]
root@Linux:~$

O primeiro passo é listar os arquivos tty do diretório de sistema /dev e localizar o arquivo que normalmente começa por ttyACM. Para facilitar a visualização da saída, é útil utilizar os parâmetros -ltr para exibir os arquivos em lista (-l), por ordem de alteração (-t) e de maneira reversa (-r). Uma vez identificado o nome do arquivo que faz referência à linha serial, basta executar o aplicativo screen na respectiva porta com a velocidade de 9600Bd (baud rate), destacando que o valor padrão de baud em dispositivos mais novos pode ser 115200Bd. Para encerrar o screen, basta digitar CTRL+A : quit.

---

Conexão Terminal via USB no Mac OS X

No Mac OS X não é necessário instalar nenhum driver para que o cabo USB possa ser utilizado como linha serial. Ao conectar o cabo no computador e no roteador/switch, o sistema operacional irá identificar o dispositivo e criar seu respectivo arquivo de sistema em /dev/tty.usbmodem#, sendo que # é um número qualquer de indexação. Outra vantagem é que não é necessário instalar nenhum software terminal, uma vez que o Mac OS X já possui o screen. Apesar disso, não há problema nenhum em utilizar qualquer outro software terminal de preferência do usuário.

MacBook:~ User$ ls -ltr /dev/*usb*
crw-rw-rw-  1 root wheel  18,   4  9 Jan 13:13 tty.usbmodem1411
crw-rw-rw-  1 root wheel  18,   5  9 Jan 13:13 cu.usbmodem1411
MacBook:~ User$ screen /dev/tty.usbmodem1411 9600
[screen is terminating]
MacBook:~ User$

É necessário abrir o aplicativo Terminal (no Launchpad) para listar os arquivos tty do diretório de sistema /dev e localizar o arquivo que normalmente começa por tty.usbmodem. Para facilitar a visualização da saída, é útil utilizar os parâmetros -ltr para exibir os arquivos em lista (-l), por ordem de alteração (-t) e de maneira reversa (-r). Uma vez identificado o nome do arquivo que faz referência à linha serial, basta executar o aplicativo screen na respectiva porta com a velocidade de 9600Bd (baud rate), destacando que o valor padrão de baud em dispositivos mais novos pode ser 115200Bd. Por fim, para encerrar o cliente terminal screen, basta digitar CTRL+A : quit.

---

Conexão Terminal via USB no Windows

No Windows é necessário instalar um pacote de drivers da Cisco (atualmente na versão 3.1) para que o sistema operacional possa utilizar o cabo USB como linha serial. O leitor pode baixar o pacote de drivers diretamente da página da Cisco ou através do link abaixo que estou disponibilizando no blog. Observe que existe um arquivo específico para arquiteturas 32bits e outro para 64bits. Também é necessário instalar algum software terminal que permita acesso serial (por ex.: PuTTY).

http://www.labcisco.com.br/app/cisco-usbconsole-driver.zip

Uma vez instalado o driver no Windows, então o sistema operacional irá reconhecer uma porta Cisco Serial do tipo COM (figura 3) que deverá ser informada no software terminal de maneira idêntica ao tradicional acesso serial que era feito via cabo de console.

Figura 3. Porta Cisco Serial no Gerenciador de Dispositivos do Windows

---

Façam seus testes...

Samuel.

Suporte Oficial da Cisco na Recuperação de Senhas

Olá Pessoal

Uma situação não tão incomum que um administrador de rede pode ter que enfrentar é a necessidade de acessar um roteador ou switch protegido por uma senha desconhecida, seja por remanejamento de equipamentos usados, seja por transição de pessoal técnico ou qualquer outro motivo.

No caso específico de roteadores e switches da Cisco, não existe um procedimento comum a ser executado em qualquer equipamento que permita a recuperação de senha (password recovery). Ao contrário, o procedimento de recuperação de senha varia entre os diversos modelos de caixas e, antes de fazê-lo aleatóriamente, é recomendável que o técnico consulte documentação confiável do modelo específico. Ao se deparar com essa necessidade, minha recomendação é que seja consultada a página de suporte da Cisco no link abaixo, onde podem ser encontrados os procedimentos necessários para resetar os principais modelos de switches e roteadores. 

http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/6130-index.html

Para não limitar este artigo apenas à recomendação de leitura da página de suporte da Cisco, aproveito para trazer um guia rápido dos procedimentos de recuperação da senha nos switches Catalyst 2960/3550/3560/3750 e nos roteadores 1900, equipamentos bastante comuns no mercado. Os guias abaixo tiveram como referência a página de suporte da Cisco que recomendo no link acima.

---

Password Recovery em Switches Catalyst 2960/3550/3560/3750

01) Utilize um computador qualquer para acessar o switch através de porta de console, procedimento que deve ser feito utilizando o devido cabo de console e um software de acesso terminal (por ex. PuTTY);

02) O segundo passo é delisgar o cabo de força do switch;

03) O terceiro passo é ligar o switch e colocá-lo em modo prompt. Basta manter apertado o botão MODE, normalmente localizado no lado esquerdo do chassi frontal do switch, enquanto é reconectado o cabo de força para ligar o equipamento. A figura abaixo traz uma ilustração do botão MODE (ítem 9), onde o leitor pode observar que ele normalmente fica localizado próximo aos LEDs de status do equipamento;

Fonte: Cisco Systems (www.cisco.com)

04) Ao receber o prompt switch:, digite flash_init e veja uma saída parecida com:

switch: flash_init

Initializing Flash...

flashfs[0]: 143 files, 4 directories

flashfs[0]: 0 orphaned files, 0 orphaned directories

flashfs[0]: Total bytes: 3612672

flashfs[0]: Bytes used: 2729472

flashfs[0]: Bytes available: 883200

flashfs[0]: flashfs fsck took 86 seconds

....done Initializing Flash.

Boot Sector Filesystem (bs:) installed, fsid: 3

Parameter Block Filesystem (pb:) installed, fsid: 4

switch:

05) Na sequência, digite load_helper;

06) Para exibir o sistema de arquivos do switch e identificar seu arquivo de configuração, digite dir flash: (incluindo os ":" no final). Observe na saída do exemplo abaixo que o arquivo de configuração está destacado em amarelo e é denominado config.text.

switch: dir flash:
Directory of flash:/
2    -rwx  1803357   <date>         c3500xl-c3h2s-mz.120-5.WC7.bin
4    -rwx  1131      <date>         config.text
5    -rwx  109       <date>         info
6    -rwx  389       <date>         env_vars
7    drwx  640       <date>         html
18   -rwx  109       <date>         info.ver
403968 bytes available (3208704 bytes used)
switch:

07) Uma vez localizado o arquivo de configuração que é carregado quando o switch é inicializado, podemos renomeá-lo através da inserção do seguinte comando no prompt:

switch: rename flash:config.text flash:config.old

08) Agora podemos reiniciar o switch, através do comando: boot

switch: boot
Loading "flash:c3500xl-c3h2s-mz.120-5.WC7.bin"...###############################
################################################################################
######################################################################
File "flash:c3500xl-c3h2s-mz.120-5.WC7.bin" uncompressed and installed, 
entry point: 0x3000 executing...

09) Depois de reiniciado, o switch não será mais capaz de localizar o arquivo de configuração original e você receberá o tradicional diálogo de configuração que é exibido pelo IOS quando o equipamento não possui nenhuma configuração. A partir desse ponto estamos no sistema IOS, então vamos sair do diálogo e renomear novamente o arquivo de configuração, dessa vez para o nome original para que o switch seja capaz de carregar todas as configurações que haviam sido previamente realizadas.

Switch> enable
Switch# rename flash:config.old flash:config.text
Destination filename [config.text]
<Pressione ENTER>
Switch#  copy flash:config.text system:running-config
Destination filename [running-config]
<Pressione ENTER>
1131 bytes copied in 0.760 secs
SW#

10) Agora já podemos atribuir novas senhas para o equipamento antes de reiniciá-lo pela última vez. Nas linhas abaixo atribuiremos novas senhas para o modo privilegiado (enable), para o acesso via console (linha console 0) e para o acesso remoto (linhas vty).

SW# configure terminal
SW(config)# enable secret SENHA
SW(config)# enable password SENHA
SW(config)# line vty 0 15
SW(config-line)# password SENHA
SW(config-line)# login
SW(config-line)# line console 0
SW(config-line)# password SENHA
SW(config-line)# end
SW# wr
Building configuration...
[OK]
SW#

Pronto! Basta reiniciar os switch que as novas senhas passam a vigorar sem que nenhuma das configurações previamente realizadas tenham sido perdidas.

---

Password Recovery em Roteadores 1900

01) Ao acessar o roteador através da porta de console, digite show version no prompt para confirmar quais são as configurações de registro (register configuration) que determinam a ação do equipamento ao ser inicializado, conforme observado na saída abaixo. O valor padrão da configuração de registro normalmente é 0x2102, o que quer dizer que o roteador deve carregar o arquivo de inicialização (startup-config) durante o boot;

Router> show version
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.0(1)M1,
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 02-Dec-09 15:23 by prod_rel_team

ROM: System Bootstrap, Version 15.0(1r)M1, RELEASE SOFTWARE (fc1)

(...) Saída Omitida

Technology Package License Information for Module:'c2900'

----------------------------------------------------------------
Technology    Technology-package          Technology-package
              Current       Type          Next reboot
-----------------------------------------------------------------
ipbase        ipbasek9      Permanent     ipbasek9
security      securityk9    Permanent     securityk9
uc            uck9          Permanent     uck9
data          datak9        Permanent     datak9

Configuration register is 0x2102

02) Utilize o botão power para desligar o roteador e ligá-lo novamente;

03) O próximo passo é colocar o roteador no modo ROMmon, pressionando break algumas vezes durante o boot, depois da mensagem "program load complete, entry point:". Um detalhe importante e fundamental é que a ROMmon (ou bootstrap) é um pequeno programa responsável pela inicialização de todo o hardware do roteador e também do sistema operacional IOS;

04) Uma vez no prompt da ROMmon, vamos alterar o valor padrão 0x2102 da configuração de registro para 0x2142, o que quer dizer que o roteador não deverá carregar o arquivo de inicialização em que as senhas estão armazenadas;

romnon 1> confreg 0x2142
romnon 2> reset

05) Observe que após o comando de reset o roteador será reinicializado, mas não carregará nenhuma configuração. O roteador irá ignorar o arquivo de configuração inicial (startup-config) e você receberá o tradicional diálogo que é exibido pelo IOS quando o equipamento não possui nenhuma configuração;

06) Agora podemos copiar o conteúdo da startup-config na running-config do roteador para recuperar todas as configurações previamente realizadas, incluindo as senhas antigas. O único detalhe diferente é que todas as interfaces previamente configuradas estarão desativadas em modo shutdown, por isso será necessário ativar novamente as interfaces em uso na rede. Na sequência será necessário atribuir novas senhas, conforme observado nas linhas abaixo:

Router> enable
Router# copy startup-config running-config
Router# configure terminal
Router(config)# enable secret SENHA

Obs.: Cuidado para não digitar "copy running-config startup-config" por engano, senão você estará copiando todas as configurações correntes para o arquivo com as configurações de inicialização, ou seja, suas configurações originais serão todas perdidas!

07) Por fim, antes de reiniciar o roteador será necessário retornar as configurações de registro atual, caso contrário o roteador não carregará o conteúdo da startup-config durante as próximas reinicializações. Esse procedimento é rápido e direto através do acesso ao prompt do IOS:

Router(config)# config-register 0x2102
Router(config)# end
Router# write

Pronto! Basta reiniciar o roteador que a nova senha passa a vigorar sem que nenhuma das configurações previamente realizadas tenham sido perdidas.

Façam seus testes...

Samuel.

Caros Leitores, Boas Festas

Olá Pessoal.

Estamos nos aproximando do final de mais um ano e agora é época de festas. Essa é uma mensagem de carinho que deixo para todos vocês leitores do blog que têm colaborado no processo de divulgação de todo o conteúdo que tenho produzido, a exemplo dos artigos técnicos, dos livros, cursos, vídeos, etc. Nesse ano de 2015 ultrapassamos a marca de 1.000.000 (um milhão) de acessos e em 2016 o blog certamente estará repleto de novos artigos!

Feliz Natal e Próspero Ano Novo!

Samuel.

Failover de Servidores DHCP Redundantes no Linux

Olá Pessoal.

É muito comum a utilização de um servidor DHCP no ambiente da empresa para fins de configuração dinâmica dos endereços IP das estações da rede de maneira automática. Uma vez que a implementação de um servidor DHCP é uma tarefa relativamente simples, é comum que muitos administradores acabem por dar menor importância ao seu papel crucial em qualquer rede de médio ou grande porte. É fato que o serviço de configuração automática dos endereços é fundamental para a operação de uma rede, afinal sem endereço IP nenhum host sequer consegue ser membro efetivo da rede.

É por essa simplicidade de configuração que o serviço DHCP acaba recebendo menos atenção do administrador e muitas vezes, talvez na maioria, é implantado através de um único servidor. O problema dessa abordagem tradicional é que um único servidor DHCP acaba se tornando um potencial ponto de falha que pode trazer sérios prejuízos para qualquer rede. Caso o servidor venha a cair, as máquinas que já receberam suas configurações irão mantê-las somente até que o tempo limite de empréstimo seja atingido (lease), por isso muitos administradores contornam esse problema aumentando o tempo de empréstimo. Ocorre que essa estratégia não resolve o problema por completo, uma vez que  novas máquinas não conseguirão localizar um servidor DHCP na rede e, portanto, não serão capazes de configurar automaticamente seus endereços.

No contexto específico de ambientes que possuem servidores baseados no Linux Debian, o serviço ISC-DHCP oferece a capacidade de configuração do recurso de failover através da inserção de dois servidores DHCP redundantes. Para demonstrar o roteiro de instalação de ambos os servidores primário e secundário, tomaremos por base a topologia apresentada na figura abaixo.

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server em ambos os servidores para que o Linux possa ser posteriormente configurado com o serviço DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em ambos os servidores em qual(is) interface(s) o serviço irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth0"

3. Configuração do Servidor DHCP Primário

Assim como a configuração tradicional de um servidor DHCP, a configuração do failover é relativamente simples. A principal diferença é que será adicionada uma nova declaração denominada "failover peer", onde definiremos a função do servidor (primário ou secundário) e as portas em que ambos os servidores parceiros irão conversar para sincronizar os empréstimos de endereços.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    primary;                     #define servidor como primário

    address 192.168.221.1;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.2;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;      
    max-unacked-updates 10;     

    load balance max seconds 3;

    mclt 1800;                  

    split 128;                  

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Os parâmetros mclt e split somente devem ser configurados no servidor primário. O parâmetro mclt (maximum client lead time) corresponde à extensão do tempo de lease concedido aos clientes no caso de falha do servidor responsável. O parâmetro split é uma métrica que define a proporção de balanceamento de carga entre os dois servidores, podendo variar de 0 (toda a carga no servidor secundário) até 255 (toda a carga no servidor primário), sendo que 128 equivale ao balanceamento simétrico (50/50).

4. Configuração do Servidor DHCP Secundário

A configuração do servidor secundário não é muito diferente da configuração anterior do servidor primário, exceto pelo fato de que informaremos o papel secundário e que algumas informações específicas previamente configuradas no servidor primário agora são omitidas.

#--- em /etc/dhcp/dhcpd.conf

authoritative;

ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"

{

    secondary;                   #define servidor como secundário

    address 192.168.221.2;       #endereço do servidor local

    port 647;                    #porta do servidor local

    peer address 192.168.221.1;  #endereço do servidor parceiro

    peer port 647;               #porta do servidor parceiro

    max-response-delay 30;

    max-unacked-updates 10;

    load balance max seconds 3;

} 

subnet 192.168.221.0 netmask 255.255.255.0

{

    option routers 192.168.221.254;

    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";

    pool

    {

        failover peer "NOME";

        range 192.168.221.100 192.168.221.199;

    }

}

Além dos servidores redundantes serem úteis para fins de disponibilidade ao eliminar o ponto único de falha na rede, outra vantagem é que eles fazem um trabalho cooperativo de balanceamento de carga na oferta dos leases para os clientes da rede, dividindo igualmente os empréstimos (se split = 128). Ambos os servidores irão armazenar o registro de todos os leases, além de logar o status dos servidores.

Obs.: É importante estar ciente de que antes da configuração dos servidores primário e secundário, espera-se que ambos estejam com os clocks devidamente sincronizados, uma vez que a referência de tempo é crucial para o serviço DHCP funcionar devidamente. Uma boa opção para manter os relógios dos servidores sincronizados é a implantação do serviço NTP na rede. O leitor encontra mais informações sobre esse assunto em outro artigo do blog, intitulado "A Hora Certa na Internet Brasileira".

Façam seus testes...

Samuel.

Nova Nomenclatura de Interfaces Previsíveis no Linux

Olá Pessoal

Recentemente, a partir da versão v197 do systemd/udev, o Linux passou a utilizar um novo mecanismo para nomenclatura das interfaces de redes, denominado Predictable Network Interface Names. O objetivo da nova nomenclatura foi solucionar problemas reais decorrentes da generalização dos nomes tradicionais que utilizavam o formato ethX (ethernet), wlanX (wireless), etc.

O problema da nomenclatura tradicional é que as interfaces de mesma natureza recebem seus nomes do kernel de maneira sequencial (no formato eth0, eth1, eth2, etc...) assim que elas são consultadas pelo driver. Ocorre que o mecanismo de comunicação entre o driver e a interface não é previsível, o que implica na possibilidade de alteração nos nomes das interfaces durante o processo de boot de máquinas que tenham múltiplas interfaces de rede em caso de atualização de hardware. Essa situação traz riscos de segurança em ambientes que tenham scripts de firewall que foram baseados nos nomes tradicionais.

Obs.: O leitor pode fazer um teste rápido para verificar essa situação usando um liveCD em máquina que tenha duas interfaces de rede. Repare que a indexação das interfaces ocorre de forma aleatória a cada boot. Em sistemas devidamente instalados os nomes permanecem persistentes depois de atribuídos pelo kernel até que haja alguma alteração de hardware que demande nova reindexação. 

O novo mecanismo de nomenclatura traz suporte nativo a diferentes políticas para nomeação das interfaces de rede, a destacar:

1. Nomes Indexados via Firmware/BIOS On-Board
2. Nomes Indexados via Firmware/BIOS PCI Express
3. Nomes Indexados via Localização Física do Hardware
4. Nomes Indexados via Endereço Físico (MAC)
5. Nomes Clássicos Nativos do Kernel (Imprevisíveis)

Todas essas políticas são utilizadas em conjunto, de forma que a primeira política será adotada caso as informações do firmware on-board estejam disponíveis, seguida pela segunda política caso as informações do firmware PCI estejam disponíveis, seguida pela terceira política se disponível, seguida da quinta política caso contrário. A quarta política não é utilizada por padrão, a menos que seja explicitamente configurada pelo administrador. Por exemplo, possíveis nomes de interfaces baseados na primeira, segunda, terceira, quarta e quinta políticas, respectivamente, seriam: eno1, ens1, enp2s0, enx78e7d1ea46da e eth0. 

Apesar das políticas padrões, as configurações realizadas pelo administrador sempre têm precedência. Ou seja, se o administrador criar links para outras regras udev, por exemplo para utilizar seus próprios nomes personalizados ou mesmo os nomes tradicionais, o novo mecanismo de nomenclatura previsível não será adotado. A nova nomenclatura previsível pode ser desativada, fazendo com que o sistema volte a utilizar os nomes tradicionais, através da simples passagem de uma instrução ao kernel durante o processo de boot. Essa tarefa pode ser realizada adicionando a seguinte linha  no arquivo de configuração do GRUB que fica localizado em /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0" 

Obs.: Reparem que em distribuições desktop é provável que a opção "quiet splash" esteja presente para que o usuário, durante o processo de boot, não tenha contato direto com as várias informações de inicialização do sistema, sendo que, ao invés disso, o usuário visualiza na tela uma imagem de inicialização (splash). Se for esse o caso, basta adicionar o parâmetro net.ifnames na sequência, depois de um espaço e dentro das aspas.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0"

Para que as alterações no arquivo de configuração do GRUB tenham efeito a partir do próximo boot, é necessário digitar update-grub. Façam seus testes...

Samuel.

Fonte:  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20

TACACS+ na Autenticação Centralizada de Dispositivos Cisco

Olá Pessoal.

A autenticação de usuários em dispositivos Cisco pode ser realizada através de uma base local de usuários que fica distribuída em cada uma das caixas ou através de uma base centralizada na rede via servidor TACACS+ (Terminal Access Controller Access Control System Plus). O TACACS+ é um protocolo de segurança utilizado para controlar os usuários que tentam se autenticar em roteadores ou switches da Cisco (e de outros fabricantes). Ao acessar uma caixa da rede, o usuário é conectado previamente a um servidor centralizado para fins de identificação e autorização das credenciais. Se autorizado, então o servidor TACACS+ encaminha as informações de login para a caixa remota que solicitou a autenticação.

A solução comercial oficialmente recomendada pela Cisco que implementa as funcionalidades de um servidor TACACS+ é o Cisco Secure Access Control System (ACS). Uma alternativa gratuita e que pode ser instalada no Linux é a ferramenta TAC_Plus (pacote tacacs+ no Debian). Neste artigo irei detalhar os passos necessários para configurar um servidor TACACS+ no Linux Debian e também como configurar as caixas Cisco para que o processo de autenticação seja centralizado através da comunicação com o servidor. A topologia proposta é bastante simples e pode ser observada na figura abaixo, sendo que o laboratório pode ser reproduzido no GNS3 em conjunto com o VirtualBox.

A primeira etapa consiste na instalação do pacote tacacs+ para que o Linux Debian possa ser posteriormente configurado como servidor TACACS+ na rede. Essa tarefa é simples através do APT.

root@tacacs:/# apt-get install tacacs+

Depois de instalado o pacote tacacs+, o arquivo de configuração principal do servidor TACACS+ fica armazenado em /etc/tacacs+/tac_plus.conf. Nas configurações abaixo definiremos uma chave de verificação do servidor denominada "CHAVE" e criaremos dois perfis, sendo um com privilégio administrativo de nível 15 (grupo "admin") e outro com privilégio de execução de nível 7 (grupo "user"). Na sequência, criaremos o usuário "shbbrito" no grupo "admin" e definiremos sua senha que deve ser informada de maneira cifrada. 

###--- em /etc/tacacs+/tac_plus.conf

accounting file = /var/log/tac_plus.acct

key = "CHAVE"

group = "admin"
{
  default service = permit
service = exec
{
priv-lvl = 15
idletime = 10
timeout  = 60
}
}

group = "user"
{
default service = deny
service = exec
{
priv-lvl = 7
idletime = 10
timeout  = 30
}
}

user = "shbbrito"
{
name = "Samuel Henrique Bucke Brito"
member = "admin"
login = des "1oV3QcqhpSN2w"
}

Obs.: Para gerar a senha cifrada pode ser utilizado o aplicativo tac_pwd. Ao digitar tac_pwd no shell, será necessário informar a senha para que o aplicativo possa fazer a cifragem e trazer seu resultado na tela. Neste exemplo, utilizamos a senha "SENHA" que equivale a "1oV3QcqhpSN2w".

Feito isso o servidor TACACS+ já está devidamente configurado no Linux Debian.
Para inicializar o serviço, basta digitar:

root@tacacs:/# service tacacs_plus start
[ OK ] tacacs_plus.service: TACACS+ authentication daemon

Agora que o servidor TACACS+ está operacional na rede, as caixas Cisco (roteadores e switches) devem ser configuradas para fazer a autenticação via TACACS+. Essa configuração é rápida e os comandos necessários para fazê-lo são listados abaixo, com destaque em amarelo para as informações do IP do servidor e a respectiva key que configuramos anteriormente.

Roteador(config)# aaa new-model
Roteador(config)# aaa authentication login default group tacacs+ local
Roteador(config)# aaa authorization exec default group tacacs+ local
Roteador(config)# tacacs-server host 192.168.221.1
Roteador(config)# tacacs-server key CHAVE

Façam seus testes...

Samuel.

Servidores DHCP Redundantes em Dispositivos Cisco

Olá Pessoal.

Uma prática útil para prover redundância no serviço de configuração automática de endereços IP é a inserção de um servidor DHCP adicional na rede que possa garantir a disponibilidade do serviço mesmo em caso de queda do servidor principal, além de dividir a carga de trabalho.

Basicamente essa tarefa pode ser implementada de duas maneiras: (a) através da divisão manual dos escopos configurados nos dois servidores DHCP, de maneira que os endereços providos por um servidor não conflitem com os endereços providos pelo outro; (b) através do protocolo DHCP Failover que viabiliza a coordenação das ações de ambos os servidores, feature suportada pelo ISC-DHCP no Linux Debian e também a partir do Windows Server 2012.

O método manual é suportado em qualquer caixa ou Sistema Operacional por ser o mais simples e não envolver nenhum protocolo específico, no entanto não há uma coordenação das atividades dos dois servidores, de maneira que as tabelas de leases dos dois servidores são totalmente independentes, o que não permite gerenciamento centralizado dos leases ou manutenção das reservas em caso de queda de um dos servidores. Apesar dessas limitações, ainda assim trata-se de uma opção muito comum e funcional para assegurar a disponibilidade do serviço de configuração automática de IPs.

Pois bem, neste breve artigo trago um exemplo bastante simples de configuração de dois roteadores Cisco (poderiam ser switches). Na figura abaixo existem dois roteadores que fazem parte de um grupo HSRP e que respondem pelo IP Virtual 192.168.0.10 (gateway).  Na figura abaixo o leitor pode observar a configuração de ambos os roteadores como servidor DHCP.

Em cada roteador foi definido um escopo denominado ESCOPO para distribuição de endreços na rede 192.168.0.0/24. No roteador DHCP-SRV1 excluímos a faixa inicial dos primeiros dez endereços para fins de atribuição estática e toda a segunda metade dos endereços da rede (de 192.168.0.129 até 192.168.0.254), ou seja, ele irá distribuir endereços que variam de 192.168.0.11 até 192.168.0.128. No roteador DHCP-SRV2 fizemos o processo inverso, ou seja, excluímos toda a primeira metade dos endereços da rede (de 192.168.0.1 até 192.168.0.128). Ao fazer isso, eliminamos qualquer possibilidade de conflito na distribuição de endereços a partir dos dois servidores DHCP presentes na rede.

Obs.: Aqueles interessados na tecnologia HSRP podem recorrer ao Laboratório 26 da segunda edição do livro Laboratórios de Tecnologias Cisco em Infraestrutura de Redes, que traz um exemplo de configuração de Alta Disponibilidade em Cluster de Roteadores.

Façam seus testes...

Samuel.