O uso do IPSec como elemento provedor de conectividade segura é mais do que padronizado pelo IETF ( é um conjunto de padrões amplamente aceito e implementado no mercado). Isso ocorre principalmente por dois motivos:

• O IPSec é um framework que traz respostas diretas para várias disciplinas de Segurança (criptografia, integridade, autenticação e gerenciamento de chaves criptográficas).
• Cada uma das tarefas previstas pelo IPSec é executada utilizando protocolos e algoritmos padronizados. Isso permite, por exemplo, a substituição de um algoritmo que tenha se tornado “fraco” sob o ponto de vista criptográfico, sem necessidade de se alterar a arquitetura.

Tudo isso era muito bom mas as redes evoluíram, se tornaram mais relevantes como plataforma de negócios e novas demandas de clientes foram surgindo… E isto acabou por inspirar a criação de novas ofertas de VPN baseadas em IPSec, algumas das quais são listadas a seguir:

• EasyVPN: espécie de conexão site-to-site dinâmica em que os elementos remotos (normalmente roteadores) se comportam como hardware clients. A solução é prática mas restrita ao modelo de rede conhecido como hub-and-spoke.
• Virtual Tunnel Interface (VTI) : resolve o incoveniente de não se ter uma interface lógica (roteável) associada aos túneis IPSec. Similar ao que se faz com GRE (Generic Routing Encapsulation) mas permitindo encapsulamento direto em IP.
• DMVPN: permitindo estabelecimento de túneis sob demanda entre os remotos (spokes). Isso é particularmente importante para redes que transportam tráfego real-time (voz, vídeo), pois permite uma melhor adequação aos requisitos de delay e jitter desses tipos de aplicações.

Mas mesmo com essas opções, havia espaço para inovação, não apenas no que diz respeito a funcionalidades mas também no aspecto de facilidade de configuração. Por isso foram criadas duas novas soluções:

• FLEX VPN: Condensa todas as opções de configuração baseadas em túneis site-to-site listadas anteriormente e ainda permite tratar conexões VPN de acesso remoto (tanto as que empregam o Anyconnect Client como as que usam o cliente nativo do Windows 7). Um aspecto notável do FLEX VPN é o uso do padrão IKEv2 (mais seguro que a implementação original, IKEv1) para negociação dos componentes de segurança a serem usados na sessão IPSec (Security Associations).
• GET VPN: VPNs sem túnel, destinadas a agregar os benefícios do IPSec na montagem de INTRANETS seguras. Baseado na RFC 3547 e muito útil para atender à regulamentações dos segmentos de indústria (PCI, SOX, HIPAA, etc).

A fim de prover mais detalhes sobre essas importantes implementações tecnológicas, produzi os seguintes artigos:

• Flex VPN: A new paradigm for IPSec deployment on Cisco Routers
• INTRANETS Seguras e Expansíveis com GET VPN
• GET VPN or Flex VPN…? Do I need both ?

Naturalmente espero que o material seja útil

Boa leitura!

Alexandre Moraes

Popularity: 1% [?]

Tema de hoje: “Cobertura Site Survey 802.11 – Como garantir a correta localização da antena, potência de sinal e cobertura, além de minimizar a interferência? com Ricardo Vallino da Cisco e Jim Davis do parceiro Fluke Networks.”

Participe, é de graça! Registre-se aqui.

Abraço

Marco.

Popularity: 1% [?]

Pessoal, obrigado pelas participações! Mais de 50, nada mal.

O desafio, como muitos tiveram a oportunidade de observar, apesar de aparentar ser fácil, não era. Achei-o interessante pois ele une uma série de conceitos importantes não apenas ao exame CCNA, mas a Redes como um todo. Antes de eu apresentar os ganhadores e postar a explicação das respostas, um “puxão de orelha”

O enunciado dizia claramente: “Instruções: Leia a questão ATENTAMENTE antes de respondê-la“. Ainda assim, muitos responderam com apenas uma alternativa, quando era pedido “(marque as alternativas corretas)“. Esta experiência vale também para o exame CCNA (e para qualquer outro da Cisco). Sempre leiam a questão com atenção, ou correrão o risco de jogar fora pontos preciosos. Fica a dica.

Sobre o desafio:

A questão apresentava um diagrama com 4  PCs distribuídos em 2 subredes, interconectadas por intermédio de um router.

Dados:

• IP Host A: 172.16.10.100 /16
• IP Host D: 172.16.20.200 /24

E é aí que mora a explicação de tudo o que acontece depois . Observe que acima coloquei em destaque o que os referidos PC entendem como sendo a porção de rede dos endereços configurados, dadas as máscaras aplicadas. Desta forma, o Host A simplesmente “pensa” que o Host D encontra-se na mesma rede (172.16.0.0 /16), e ao invés de buscar um default-gateway (router) na rede para alcançá-lo, ele vai usar o ARP para tentar descobrir seu MAC Address para fazer uma comunicação direta.

Ocorre que, por isso não ser verdade (o Host D está, na verdade, em uma rede distinta, e atrás de um router), o frame broadcast contendo o ARP alcançará a porta e0 do router e, por definição, não será propagado. O router, estando com o recurso “ip proxy-arp” ativado - o que é DEFAULT em todas as interfaces Ethernet, e sequer aparece quando damos o comando “show run” - , ao receber este frame vai verificar que ele conhece o IP destino (172.16.20.200) presente na solicitação ARP e vai responder esta solictação ao Host A como se ELE fosse o destinatário (Host D). Ou seja, ele vai enviar um ARP Reply ao Host A com seu MAC Address.

O Host A, então, pensará que sua pesquisa foi bem sucedida e instalará em sua tabela ARP o MAC Address da interface e0 do router associado ao endereço IP do Host D. Sempre que uma comunicação com este Host for feita, será então enviado o pacote ao router que, por sua vez, o encaminhará ao destino final - o Host D (o router está, portanto, fazendo o papel de proxy aqui). Observem que, neste caso, o Host A NÃO PRECISARIA TER UM DEFAULT-GATEWAY CONFIGURADO, já que ele está usando o ARP nesta comunicação.

No caminho contrário, temos a operação normal de rede, como deveria. Como o IP de destino encontra-se em outra rede (o Host D sabe disso pois o endereço IP do Host A está fora do alcance de sua máscara) o pacote é encaminhado ao default-gateway da rede (porta e1 do router) e o procedimento de roteamento ocorre normalmente. Portanto, o default-gateway precisa estar configurado no Host D (mas o proxy-arp poderia ser desabilitado aqui).

Respostas corretas, portanto: C, D, G 

Ganhadores dos livros (por ordem de resposta correta)

• Fernando Avelino (comment 04) - figurinha carimbada aqui no Blog
• George (comment 18)
• JoW (comment 24)

Parabéns para vocês! Entro em contato para acertarmos os detalhes.

Espero que tenham gostado.

Referência: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml

Marco.

Popularity: 1% [?]