Dhcp Guard - Hyper-V 2012 R2
Olá Pessoal
Como sabemos que se subirmos um DHCP, ou plugar um roteador caseiro em uma empresa, isso causará dores de cabeça para o administrador de redes, até descobrir onde que está o problema. E poderá levar horas.
Devido as máquinas na rede requisitar o IP a servidores DHCP, no caso da captura de um IP fora do escopo da rede fará com que usuários não conseguirão utilizar recursos da
rede, internet ou mesmo se logar na máquina por falta de encontrar o perfil móvel.
Para contornar esse tipo de problema roteadores como Cisco impede com que outro roteadores plugados na rede cause isso. Mas quando falamos de ambiente de teste de máquina virtual, também podemos ter esse problema. E neste caso a Microsoft adicionou o recurso avançado chamado DHCP GUARD no Hyper-V 2012.
Com a opção DHCP GUARD marcada podemos impedir com que a máquina virtual seja não autorizada a transmitir mensagens como servidor DHCP. Mas em que tipo de ambiente isso pode ocorrer? Empresas que utilizam-se de SSP (Self Service Portal) pelo System Center Virtual Machine Manager, que serve para os usuários criarem suas próprias máquinas virtuais para testes de produtos, banco de dados ou outros pode por qualquer motivo tentar subir um DHCP e causar problemas na empresa. Sabemos que para tudo que se cria para o bem, utiliza-se também para fazer o errado, então essas proteções são criadas justamente para impedir tais problemas na rede.
Agora vamos aos testes. Temos o seguinte ambiente:
Host Físico – Server 2012 R2 – Já configurado com AD e DNS – IP 192.168.1.10 – Máscara 255.255.255.0 – DNS 127.0.0.1
Na figura abaixo temos uma VM -> Server 2012 (NLB1) que irá buscar IP em um servidor DHCP que está dentro de uma VM -> Server 2012 (NLB2). No host físico ainda não está instalado DHCP.
A VM NLB1 e NLB2 tem 2 placas de rede, mas focaremos na placa Ethernet 2. Verificamos na imagem que pelo CMD a placa de rede não obteve IP e adicionou um IP APIPA, dado pelo próprio Sistema Operacional NLB1. Clique nas imagens para ver em tamanho maior.
http://andrenovello.files.wordpress.com/2013/09/12.jpg?w=640&h=360
Instalado o DHCP e configurado para a rede 192.168.5.0 na VM NLB2, verificamos que a VM NLB1 ficou com o ip 192.168.5.1 quando desativamos a placa de rede e ativamos, lembrando que não ativamos o DHCP GUARD ainda.
http://andrenovello.files.wordpress.com/2013/09/22.jpg?w=640&h=306
Um dos bons motivos do Windows Server 2008 R2 para 2012 e 2012 R2 é que agora a maioria das opções se tornam configuráveis mesmo com a máquina em funcionamento, e isso acontece também com o DHCP GUARD.
Para ativar o recurso entramos na configuração da VM desejada e clicamos na placa de rede, entrando nos recursos avançados e ticando a opção ENABLE DHCP GUARD. Lembrando que se o servidor tiver mais placas todas devem ser marcadas.
http://andrenovello.files.wordpress.com/2013/09/31.jpg?w=640&h=350
Abaixo na imagem agora está configurado o DHCP GUARD, no qual desativei a placa de rede da VM NLB1 e ativei novamente como se fossemos reiniciar a máquina ou ligar ela no dia seguinte, e verificamos que o IP atribuído novamente é o IP APIPA. No servidor DHCP tudo está marcado corretamente, serviço dhcp rodando, mas o dhcp guard agora está bloqueando todo envio de pacotes dhcp. Sim, o recuso funciona =).
http://andrenovello.files.wordpress.com/2013/09/41.jpg?w=640&h=334
Agora vamos instalar o DHCP no Host Físico e configurar com IP de pool de endereço de 192.168.1.20 a 192.168.1.25. Iremos reiniciar a máquina NLB1 e desativar o DHCP GUARD da VM NLB2. E para a conclusão do artigo podemos ver o que aconteceu com o Servidor NLB1, acabou atribuindo o IP do servidor de Testes da empresa ou VM de algum usuário, causando transtornos para os administradores. O login demorou um pouco para acontecer, em média de meu notebook logava de 3 a 5 segundos. Mas com 2 DHCP ativados na rede ele ficou um pouco pensativo…, levou 10 segundos para saber de quem atribuir o IP.
http://andrenovello.files.wordpress.com/2013/09/62.jpg?w=640&h=277
Por isso que para empresas que tem o controle por SSP (Self Service Portal) do SCVMM, o correto é criar template pronto para usuário e deixar marcado o DHCP GUARD, pois pode não ter o controle sobre a rede caso algum funcionário queira fazer alguma brincadeira na empresa por motivos reais ou não.
Nesta última imagem ativei o DHCP GUARD na VM NLB2 e agora o IP foi atribuído corretamente para o Servidor NLB1 a partir do Host Físico e logou em 3 segundos, sem atraso de um segundo DHCP.
http://andrenovello.files.wordpress.com/2013/09/7.jpg?w=640&h=313
Espero que tenham achado bem interessante este recurso, pois é de grande valia e os testes foram bem interessantes, pois aconteceu o esperado de reiniciarmos o servidor e ele capturar IP do DHCP falso na rede.
Obrigado