Telefonia IP da Cisco em Médias Empresas

Olá Pessoal.

O Lab11 do livro traz um cenário bem interessante de telefonia integrada à rede de dados que é comumente adotado em empresas de médio porte, conforme pode ser observado na figura abaixo. Lembrando aos intressados que os procedimentos de configuração desse ambiente são detalhados no livro.

Quando faço esse laboratório em aula com os meus alunos, logo vem a seguinte pergunta: "Professor, como interligar a rede local de telefonia com a rede pública de telefonia?" Ou seja, como permitir que os ramais internos também possam fazer ligações externas?

Infelizmente o Packet Tracer não permite que essa prática seja configurada no nosso cenário, mas como essa é uma dúvida recorrente, acho que cabe uma postagem mostrando como seria essa configuração.

Então vamos começar com uma pequena alteração na figura anterior, já que precisamos acoplar ao nosso roteador ISR (Roteador de Serviços Integrados) uma interface FXO de voz que será conectada à rede pública de telefonia (denominada PSTN).

Estamos partindo do princípio de que todas as configurações do CUCME (Cisco Unified Communications Manager Express), antigo Call Manager Express, já estão configuradas da maneira apresentada no livro. A interface FXO que permitirá a conexão do roteador à rede analógica de telefonia será a "voice-port 0/0/0". As configurações básicas necessárias para permitir que os ramais internos possam alcançar números externos são apresentadas adiante:

01. ISR(config)# voice-port 0/0/0

02. ISR(config-voiceport)# connection plar 9

03. ISR(config-voiceport)# exit

04. ISR(config)# num-exp 9 54001

05. ISR(config)# dial-peer voice 1 pots

06. ISR(config-dial-peer)# description "Chamada de Emergência"

07. ISR(config-dial-peer)# destination-pattern 019[023]

08. ISR(config-dial-peer)# forward-digits 3

09. ISR(config-dial-peer)# port 0/0/0

10. ISR(config-dial-peer)# exit

11. ISR(config)# dial-peer voice 2 pots

12. ISR(config-dial-peer)# description "Chamada Local"

13. ISR(config-dial-peer)# destination-pattern 0........

14. ISR(config-dial-peer)# digit-strip

15. ISR(config-dial-peer)# port 0/0/0

16. ISR(config-dial-peer)# exit

17. ISR(config)# dial-peer voice 3 pots

18. ISR(config-dial-peer)# description "Chamada Interurbano"

19. ISR(config-dial-peer)# destination-pattern 0099..........

20. ISR(config-dial-peer)# prefix 099

21. ISR(config-dial-peer)# port 0/0/0

22. ISR(config-diar-peer)# exit

Muito bem, está pronto! Vamos às explicações:

Nas linhas de 01-04 configuramos um recurso importante denominado PLAR (Private Line Auto Ring) que faz com que qualquer chamada destinada ao número telefônico da sua linha analógica seja redirecionado para o ramal 54001, afinal seu roteador não irá tocar quando alguém te ligar! Normalmente a chamada é redirecionada para um ou mais ramais das telefonistas. É comum nas empresas a utilização do ramal 9 para falar com as telefonistas porque é mais cômodo digitar um único digito e por isso escrevemos a quarta linha para criar uma associação entre 54001 e 9.

Feito isso, o passo mais importante é a criação de planos de discagem denominados dial-peers com as "rotas" para as chamadas externas. Pensem no dial-peer como uma entrada estática na tabela de roteamento, mas voltado para o contexto da telefonia.

Nas linhas de 05-10 criamos um dial-peer para as chamadas de emergência, um pré-requisito fundamental que sempre deve ser configurado. Reparem que informamos esse plano com a entrada 019[023], o que quer dizer que o primeiro dígito 0 é necessário para "pegar" a linha, como acontece em qualquer PBX, e depois temos os números 190, 192 e 193. Como os números e emergência sempre iniciam em 19, então fixamos esses dígitos e utilizamos [023] para identificar que o usuário pode discar no final 0, 2 ou 3. Qualquer outro número fora desse parão, por exemplo, 199, terá a chamada rejeitada pela operadora. O comando "forward-digits 3" considera somente os três últimos dítigos da direita para a esquerda, ou seja, remove o 0 da discagem, afinal o 0 somente foi importante para "pegar" a linha. Por fim, informamos ao roteador que qualquer número discado que se enquadre nessas regras será encaminhado para a interface 0/0/0 de voz, ou seja, para a rede de telefonia pública.

Seguindo essa mesma lógica, nas linhas de 11-16 criamos um dial-peer para as chamadas locais e nas linhas de 17-22 criamos um dial-peer para as chamadas interurbanas. A única diferença é que o "." indica que o usuário pode discar qualquer número, sendo que "digit-srip" instrui o roteador a eliminar os números pré-fixados - nesse caso, o 0. É interessante destacar que podemos fidelizar no roteador uma única operadora para todas as chamadas de longa distância, como fizemos com a operadora fictícia 99 através do comando "prefix". Com o plano que criamos, quando algum usuário quiser fazer uma ligação interurbana, terá que digitar dirtamente o DDD da cidade seguido do número, ou seja, 19XXXXXXXX. Interessante, não?

Com essas configurações rápidas, nossa rede de voz integrada à rede de dados agora está interligada com a rede de telefonia pública. Claro que exploramos apenas os recursos mais básicos.  As soluções de comunicações unificadas da Cisco tem vários outros recursos, tais como: 

• Network Directory: associa nomes de usuários aos números de ramais e distribui automaticamente a "agenda" aos telefones IP;
• Call Forwarding: redireciona a chamada para outro telefone, normalmente quando a linha está ocupada ou ninguém responde;
• Call Park: estaciona uma chamada em outro ramal para que outras pessoas posteriormente possam capturá-la novamente ao discar para esse outro remal;
• Call Pickup: permite que usuários possam "puxar" a ligação de outros telefones quando não há ninguém para atender;
• Intercom: chamada unidirecional via viva-voz;
• Paging: permite o envio de mensagens unidirecionais para um grupo de usuários (multicast), no entanto a infraestrutura da rede (switches) deve estar preparada para tráfego multicast;
• After-Hours Call Blocking: permite o bloqueio do telefone a partir de um horário ou em feriados;
• CDR Call Accounting: log de chamadas (tarifador);
• Music on Hold (MoH): executa um arquivo de áudio na espera das chamadas;
• Single Number Reach (SNR): uma pessoa pode ser localizada onde estiver através de um número único do escritório, desde que seu celular esteja cadastrado no roteador como segunda opção.

Enfim, fica claro que são vários os recursos disponíveis.

Abraço!

Samuel.

Acesso Seguro ao Roteador via SSHv2

Olá Pessoal.

A maioria de vocês deve saber que os acessos remotos aos dispositivos da Cisco (roteadores e switches) acontecem, por padrão, através do telnet. Acontece que no telnet o dados trafegam "em claro", o que quer dizer que alguém executando algum software para sniffar a rede (a exemplo do Wireshark) pode facilmente interceptar toda a informação que trafega entre o computador que iniciou a sessão remota e o roteador, inclusive as senhas... Aí é que está o problema!!!

Por causa disso as empresas sempre habilitam o SSH para esse fim, já que esse protocolo implementa a criptografia dos dados, ou seja, ele cifra (codifica) todo o conteúdo digitado no computador que iniciou a sessão remota e o roteador decifra esse conteúdo antes de interpretá-lo. Dessa forma, caso alguém venha a interceptar a sessão remota, tudo que poderá ser visualizado será uma sequência de caracteres codificados que não fazem nenhum sentido para quem não conhece a chave, conforme é ilustrado abaixo.

Uma pergunta frequente que meus alunos fazem é exatamente como proceder para habilitar o SSH no acesso remoto ao roteador, ao invés do telnet. Registrarei essa resposta para futuras dúvidas recorrentes, mostrando adiante como habilitar o SSHv2, ainda mais seguro do que o SSHv1. Para habilitar o SSHv2 no roteador ou em switches, basta executar as seguintes linhas de comando que explicarei adiante:

01. Router(config)# hostname R1
02. R1(config)# username admin privilege 15 secret SENHA

03. R1(config)# ip domain-name labcisco.com.br

04. R1(config)# crypto key generate rsa   

05. R1(config)# ip ssh version 2

06. R1(config)# ip ssh time-out 30

07. R1(config)# ip ssh authentication retries 3

08. R1(config)# line vty 0 15

09. R1(config-line)# transport input SSH
10. R1(config-line)# login local

11. R1(config-line)# end

12. R1# show ip ssh

Para configuração do SSH é necessário que o roteador não esteja utilizando o hostname padrão Router, motivo pelo qual fazemos essa alteração na linha 1. Na linha 2 criamos um usuário local no nosso roteador com privilégio nível 15 (máximo). A linha 3 informa um nome de domínio que posteriormente será utilizado para gerar a chave do SSH. Na linha 4 é gerada a chave RSA para codificação/decodificação dos dados que deve ter pelo menos 1024 bits. Nas linhas de 5 a 7 apenas setamos alguns parâmetros comumente utilizados, como por exemplo habilitar o SSHv2 (e desabilitar o SSHv1), limitar o tempo da sessão e a quantidade de tentativas de conexão. 

Por fim, entramos no sub-modo de configuração das linhas vty (acesso remoto via rede) e configuramos o roteador para utilizar o SSH no transporte dos dados e autenticar com base nos usuários localmente adicionados no roteador (o que fizemos na primeira linha). Você pode utilizar o comando "show ip ssh" (linha 12) para verificar o funcionamento do SSH no roteador e para saber qual versão está utilizando.

Pronto!!! O SSHv2 já está ativado no seu roteador. Agora lembre-se de configurar no seu cliente terminal que o acesso remoto dar-se-á via SSH na porta 22/TCP; não mais via Telnet na porta 23/TCP como era feito antes. Há outras opções que podem ser exploradas em relação ao SSH como protocolo de acesso remoto. Caso vocês queiram se aprofundar, recomendo o link abaixo da própria Cisco que detalha o assunto:

http://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh/4145-ssh.html

Abraço.

Samuel.

Material de Certificação Cisco na LAN University

Olá Pessoal.

Nessa semana estive reunido com os alunos de certificação Cisco da LAN University, um importante centro de treinamentos em TI de Campinas. Na oportunidade do evento pude apresentar o escopo do livro para os alunos e discutir as principais tecnologias envolvidas nos laboratórios.

A boa notícia é que o livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" agora é parte integrante do material de estudo dos cursos de certificação Cisco oferecidos pela LAN University. Com essa parceria os alunos das próximas turmas dos cursos Cisco irão GANHAR um exemplar do livro para praticar os laboratórios.

Mais uma parceria de sucesso!!!

Abraço.

Samuel.

Time-Based ACLs

Olá Pessoal.

As ACLs que podemos implementar em roteadores Cisco são ferramentas de segurança bastante úteis no dia-a-dia de um profissional da área de redes. Nesse tocante fala-se muito nas listas padrões (standard) e estendidas (extended) que são comumente cobradas nos exames de certificação, no entanto é possível incorporar a elas o recurso de aplicá-las com base no horário, o que é pouco comentado e MUITO últil nas empresas.

A sintaxe e os principais conceitos das ACLs padrões e estendidas podem ser encontrados no "Lab09" do meu livro e por isso não estarei focando essa postagem nesses princípios. Ao contrário, meu objetivo nessa postagem é mostrar como o recurso "time-range" pode ser acoplado às ACLs tradicionais para te permitir aplicar suas regras com base no horário.

Bom, antes de partir para os comandos, é preciso entender o que queremos fazer. Estaremos utilizando o mesmo cenário do "Lab10" do livro, que traz um ambiente bastante simples em que temos uma LAN 172.22.0.0/16, cujo gateway é a interface f0/0 do roteador (172.22.11.1). Na rede existe uma máquina (172.22.11.101) que somente poderá acessar a Internet no horário do almoço (das 12h às 13h). Essa poderia ser, por exemplo, uma máquina da recepção de uma empresa.

A interface s0/0 do roteador está conectada na Internet e o equipamento já foi devidamente configurado para fazer o compartilhamento da conexão via NAT. Mais uma vez, os detalhes de como configurar NAT em roteadores Cisco podem ser encontrados no "Lab10" do livro.

Podemos setar o horário do roteador manualmente, mas esse método é pouco confiável. Aproveitaremos a oportunidade de escrever as ACLs com base em horário para verificar os procedimentos para configurar o horário do dispositivo através do Protocolo NTP (Network Time Protocol).

O NTP.br é um serviço público nacional disponibilizado pelo NIC.br (autoridade máxima da Internet do Brasil) que provê a sincronização do horário oficial brasileiro através de servidores gratuitos rodando o NTP. Nessa postagem, estaremos utilizando esse serviço para atualizar a hora, conforme pode ser observado no roteiro abaixo:

01. Router# conf t

02. Router(config)# ntp server 200.160.7.186

03. Router(config)# clock timezone BR -3 0 

04. Router(config)# clock summer-time BRV recurring 3 Sun Oct 0:00 3 Sun Feb 0:00

05. Router(config)# service timestamp debug datetime msec localtime show-timezone year

06. Router(config)# service timestamp log datetime msec localtime show-timezone year

No roteiro acima foi utilizado o servidor "a.st1.ntp.br" (do NTP.br) que responde pelo IP 200.160.7.186 (linha 2). O relógio dos equipamentos trabalha sincronizado com o UTC de cada região (o padrão é 0) e por isso precisamos da terceira linha para setar o UTC do Brasil (que é -3).

O NTP não trata da questão do horário de verão, ou seja, quando entramos ou saímos do horário de verão o relógio não é alterado. Por isso informamos a linha 4 para fazer os ajustes manuais referentes ao nosso horário de verão nacional. O horário de verão teve início no terceiro domingo de outubro (20/10/2012) e terminará no terceiro domingo de fevereiro (17/02/2013).

Nas linhas 5 e 6 informamos ao IOS que passe a anexar o horário sincronizado em todos os seus registros de log e debug, uma boa prática que pode facilitar muito na detecção de problemas a partir da leitura dos logs. Reparem que essas linhas são opcionais e não são necessárias para o funcionamento da configuração proposta, no entanto essa prática é realmente muito recomendada.

Agora que o horário do nosso roteador é confiável através da soncrinização via NTP, então podemos partir para a escrita das ACLs propriamente ditas. Antes de escrevermos as ACLs (nas linhas de 11 a 14), criamos um escopo de horário que será acoplado a elas (linhas 8 e 9), como pode ser observado no roteiro abaixo. Por fim, aplicamos a ACL na interface f0/0 do roteador.

07. Router# conf t

08. Router(config)# time-range HORA-ALMOCO

09. Router(config-time-range)# periodic weekdays 12:00 to 13:00

10. Router(config-time-range)# exit

11. Router(config)# ip access-list extended TIME-ACL

12. Router(config-ext-nacl)# permit tcp host 172.22.11.101 any time-range HORA-ALMOCO

13. Router(config-ext-nacl)# deny ip host 172.22.11.101 any

14. Router(config-ext-nacl)# permit ip 172.22.0.0 0.0.255.255 any

15. Router(config-ext-nacl)# exit

16. Router(config)# int f0/0

17. Router(config-if)# ip access-group TIME-ACL in

18. Router(config-if)# end

19. Router#    

Ou seja, é bem simples. Basta adicionarmos o parâmetro "time-range" ao final da ACL que o efeito de filtro por horário estará em ação. Claro que antes de utilizar esse parâmetro você deve lembrar de criar o escopo referente ao horário.

Para finalizar, seguem alguns comandos "show" para você verificar seus escopos "time-range", o horário do seu dispositivo e o funcionamento do NTP:

Router# show time-range 

Router# show clock

Router# show ntp associations

Router# show ntp status 

É isso! Espero que seja útil!!! Vou avaliar a possibilidade de aproveitar essa "postagem" para criar um cenário "configurável" nos simuladores e quem sabe já não teremos um novo laboratório na próxima edição do livro...

Abraço.

Samuel.